doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7221.txt b/doc/rfc/rfc7221.txt
new file mode 100644
index 0000000..00e7d7c
--- /dev/null
+++ b/doc/rfc/rfc7221.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Farrel
+Request for Comments: 7221                              Juniper Networks
+Category: Informational                                  D. Crocker, Ed.
+ISSN: 2070-1721                              Brandenburg InternetWorking
+                                                              April 2014
+
+
+           Handling of Internet-Drafts by IETF Working Groups
+
+Abstract
+
+   The productive output of an IETF working group is documents, as
+   mandated by the working group's charter.  When a working group is
+   ready to develop a particular document, the most common mechanism is
+   for it to "adopt" an existing document as a starting point.  The
+   document that a working group adopts and then develops further is
+   based on initial input at varying levels of maturity.  An initial
+   working group draft might be a document already in wide use, or it
+   might be a blank sheet, wholly created by the working group, or it
+   might represent any level of maturity in between.  This document
+   discusses how a working group typically handles the formal documents
+   that it targets for publication.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7221.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel & Crocker              Informational                     [Page 1]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   Copyright Notice
+
+   Copyright (c) 2014 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. What Is a WG Draft? ........................................3
+      1.2. Working Group Authority and Consensus ......................4
+      1.3. Questions Considered in This Document ......................5
+   2. Adoption Sequence ...............................................6
+      2.1. Common Steps ...............................................6
+      2.2. Criteria for Adoption ......................................6
+   3. Authors/Editors .................................................8
+   4. Document History and Stability ..................................8
+   5. Some Issues for Consideration ..................................10
+      5.1. Individual I-Ds under WG Care .............................10
+      5.2. WG Drafts Can Become Individual Drafts ....................11
+      5.3. Competing Drafts ..........................................11
+   6. Security Considerations ........................................13
+   7. Acknowledgements ...............................................13
+   8. Informative References .........................................13
+
+1.  Introduction
+
+   The productive output of an IETF working group (WG) is documents, as
+   mandated by the working group's charter.  Working groups develop
+   these documents based on initial input at varying levels of maturity.
+   An initial working group draft might be a document already in wide
+   use, or it might be a blank sheet, wholly created by the working
+   group, or it might represent any level of maturity in between.  This
+   document discusses how a working group typically handles the formal
+   documents that it targets for publication.  The discussion applies
+   only to the IETF and does not cover IRTF groups, where practices vary
+   widely.
+
+
+
+
+
+Farrel & Crocker              Informational                     [Page 2]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   Within the general constraints of formal IETF process and the
+   specific constraints of a working group's charter, there can be
+   considerable freedom in the adoption and development of drafts.  As
+   with most IETF activities, the ultimate arbiter of such choices is
+   working group agreement, within the constraints of its charter.  As
+   with most working group management, this agreement might be explicit
+   or implicit, depending upon the efficiencies that the group deems
+   appropriate.
+
+   NOTE:  This document is intentionally non-normative.  It is meant as
+      a guide to common practice, rather than as a formal definition of
+      what is permissible.
+
+1.1.  What Is a WG Draft?
+
+   Working group drafts are documents that are subject to IETF working
+   group revision control, with advancement for publication as an RFC
+   requiring rough consensus in the working group and then in the
+   broader IETF.  Creation or adoption of a draft by a working group --
+   as well as substantive changes to the document -- need to represent
+   working group rough consensus.
+
+   Documents under development in the IETF community are distributed as
+   Internet-Drafts (I-Ds) [RFC2026] [ID-Info].  Working groups use this
+   mechanism for producing their official output, per Section 7.2 of
+   [RFC2418] and Section 6.3 of [Tao].  The common convention for
+   identifying an I-D formally under the ownership of a working group is
+   by the inclusion of "ietf" in the second field of the I-D filename
+   and the working group name in the third field, per Section 7 of
+   [ID-Guidelines].  That is:
+
+                          draft-ietf-<wgname>-...
+
+   In contrast, individual submissions are drafts being created and
+   pursued outside of a working group, although a working group might
+   choose to adopt the draft later, as discussed below.  Anyone is free
+   to create an individual submission at any time.  Such documents are
+   typically distinguished through the use of the author/editor's last
+   name, in the style of:
+
+                           draft-<lastname>-...
+
+   (Also see Section 5.1 for an elaboration on this naming.)
+
+   Responsibility for direct revision of a working group I-D is assigned
+   to its editors and authors.  See Section 3 for discussion about their
+   selection and role.
+
+
+
+
+Farrel & Crocker              Informational                     [Page 3]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+1.2.  Working Group Authority and Consensus
+
+   A premise of the IETF is that, within a working group, it is the
+   working group itself that has final authority over the content of its
+   documents, within the constraints of the working group's charter.  No
+   individual has special authority for the content.  The Chairs assign
+   document authors/editors and can formulate design teams, but the
+   content of working group documents is always, ultimately, subject to
+   working group approval.  Approval is described in terms of the IETF's
+   "rough consensus" construct, which is the prime example of the IETF's
+   preference for pragmatics over niceties.  Unanimous agreement is
+   always desirable, but more approximate (rough) agreement will
+   suffice, as long as it is clear and strong.
+
+   Other than for selection of document authors/editors, as discussed in
+   Section 3, working group decision-making about document management is
+   subject to normal IETF rough consensus rules.  Useful descriptions of
+   this process for a working group are in Section 3.3 of [RFC2418] and
+   Section 4.2 of [Tao].  Discussion of the nature of rough consensus
+   can be found in [Consensus].
+
+   In terms of the IETF's formal rough consensus processes, the working
+   group explicitly develops, modifies, reviews, and approves document
+   content, according to overt rough consensus.  For difficult topics
+   and/or difficult working group dynamics, this laborious process
+   really is essential.  Its diligence validates progress at each step
+   along the way.  However, working groups often handle simpler matters
+   more simply, such as allowing a Chair to assert the likely agreement
+   and then merely call for objections.  Ultimately, the mode of working
+   group decision-making is determined by the comfort and engagement of
+   the working group with the way the decisions are being made.
+
+   At times, a document author/editor can appear to have considerable
+   authority over content, but this is (merely) for efficiency.  That
+   is, the Chairs can permit authors and editors to proceed with an
+   implied (default) working group agreement, as long as the working
+   group is comfortable with that mode.  Of course, the benefit in the
+   mode is efficiency, but its risk is failure to retain or verify
+   actual consensus among the working group participants.  When a
+   working group is operating in the mode of active, direct author/
+   editor content development, an easy validation method is simply to
+   have Chairs query the working group when a new document version
+   appears, asking for comments and concerns.
+
+
+
+
+
+
+
+
+Farrel & Crocker              Informational                     [Page 4]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   In general, when it is not completely obvious what the opinion of the
+   working group is, Working Group Chairs can poll the working group to
+   find out.  As with any other consensus question, the form in which it
+   is asked can make a difference.  In particular, a general 'yes/no'
+   question often is not as helpful as asking supporters and detractors
+   of a draft -- or of the decision under consideration -- to provide
+   their reasons, not merely their preferences.  In effect, this treats
+   the matter of consensus as an ongoing discussion.  Ideally, the
+   discussion can produce changes in the document or in participant
+   views, or both.
+
+1.3.  Questions Considered in This Document
+
+   The purpose of this document is to discuss the criteria and sequence
+   typically followed when adopting and developing a formal IETF working
+   group document.  Therefore, this document considers the following
+   questions that are particularly relevant to Working Group Chairs who
+   are charged with running the process:
+
+   *  How do Working Group Chairs decide which drafts to adopt and when?
+
+   *  Is it necessary to poll the working group explicitly, and what
+      does a working group poll look like?
+
+   *  How do Working Group Chairs make the decision?
+
+   *  What are the process steps the working group will choose to use,
+      for an I-D to become a WG I-D?
+
+   *  Are there any special cases?
+
+   *  Can a document be created as a WG I-D from scratch?
+
+   *  How can competing drafts be handled?
+
+   *  Can an individual I-D be under the care of a WG?
+
+   *  Can a WG I-D become an individual I-D?
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel & Crocker              Informational                     [Page 5]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+2.  Adoption Sequence
+
+2.1.  Common Steps
+
+   When there is interest in adopting a document as a new working group
+   document, the Chairs often:
+
+   1.  Remind current draft owners that they are transferring change
+       control for the document to the IETF.  (This is a particularly
+       significant point for a document covered by proprietary
+       interests, because it typically entails a negotiation between the
+       current owners and the IETF, including a formal agreement.)
+
+   2.  Check for known IPR that needs to be disclosed, using some
+       technique like those described in [RFC6702].
+
+   3.  Obtain working group rough consensus.
+
+   4.  Choose document editors.
+
+   5.  Instruct authors to post the WG I-D.
+
+   6.  Approve posting [Approval].
+
+   7.  Ensure that the non-working group version of the draft is marked
+       as being replaced by this working group version.
+
+   8.  Encourage everyone to enjoy the ensuing working group
+       discussion...
+
+2.2.  Criteria for Adoption
+
+   No formal specification for working group 'adoption' of a draft
+   exists; the current document is meant to provide a description of
+   common activities for this, but again note that it is not normative.
+
+   There are some basic considerations when deciding to adopt a draft:
+
+   *  Is there a charter milestone that explicitly calls for such a
+      document?
+
+   *  Is the topic of the I-D within scope for the working group?
+
+   *  Is the purpose of the draft sufficiently clear?
+
+   *  Does the document provide an acceptable platform for continued
+      effort by the working group?
+
+
+
+
+Farrel & Crocker              Informational                     [Page 6]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   *  What are the process or technical objections to adoption of the
+      draft?
+
+   *  Is the draft likely to be completed in a timely manner?
+
+   *  Does the intended status of the document seem reasonable to the
+      working group?
+
+   *  If not already in scope, is a simple modification to the charter
+      feasible and warranted?
+
+   *  Does the draft carry known intellectual property rights issues?
+
+   *  Is there strong working group support for working on the draft?
+
+   Adoption has some basic pragmatics:
+
+      Rough consensus:  Working group agreement to adopt is not required
+         to be unanimous [RFC2418].
+
+      Initial, not final:  The writing quality is not required to be
+         "ready for publication", although writing quality can be a
+         problem and does need explicit attention; although not
+         mandatory, it is good practice to check whether a new working
+         group draft passes [IDNITS].
+
+      Adoption, not approval:  The document is not required to already
+         contain a complete and/or sufficient solution, although of
+         course this can be helpful.  Equally, adoption by a working
+         group does not guarantee publication of the document as an RFC.
+
+      Group, not Chairs:  Concerning the draft, the position of the
+         Working Group Chairs has no special authority, except to assess
+         working group consensus.
+
+   REMINDER:  Once a working group adopts a draft, the document is owned
+      by the working group and can be changed however the working group
+      decides, within the bounds of IETF process and the working group
+      charter.  Absent explicit agreement, adopting a document does not
+      automatically mean that the working group has agreed to all of its
+      content.  So a working group (or its charter) might explicitly
+      dictate the basis for retaining, removing, or modifying some or
+      all of a draft's content, technical details, or the like.
+      However, in the absence of such constraints, it is worth having
+      the adoption process include a sub-process of gathering working
+      group concerns about the existing draft and flagging them
+      explicitly.
+
+
+
+
+Farrel & Crocker              Informational                     [Page 7]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+3.  Authors/Editors
+
+   Document authors/editors are chosen by the Working Group Chairs.
+   Document editors are described in Section 6.3 of [RFC2418].  Authors
+   and editors are described in [RFC-Auth-Ed].
+
+   NOTE:  In this document, the terms 'author' and 'editor' are meant
+      interchangeably.  Within the IETF, the distinction between an
+      'author' and an 'editor' is, at best, subjective.  A simplistic
+      rule of thumb is that editors tend to do the mechanics of
+      incorporating working group detail, whereas authors tend to create
+      the detail, subject to working group approval.  That is, one role
+      is more active with the content, and the other is more passive.
+      It is a responsibility of the Working Group Chairs to ensure that
+      document authors make modifications in accord with working group
+      rough consensus.  Authors/editors are solely chosen by the Chairs
+      -- although the views of the working group should be considered --
+      and are subject to replacement for a variety of reasons, as the
+      Chairs see fit.
+
+   For existing documents that are being adopted by a working group,
+   there is a special challenge in the selection of document editors.
+   Because the document has already had editors, the question "Are the
+   same people appropriate for continuing the task?" is asked.
+   Sometimes the answer is yes, but this is not automatic.  The process
+   within an IETF working group can be quite different from the process
+   that created previous versions.  This well might make it appropriate
+   to select one or more new editors, either as additions to the editor
+   team or as primary pen-holders (effectively reclassifying the
+   previous team as coauthors).
+
+   If the original editors are to continue in their role, the Chairs
+   might want to ensure that the editors understand IETF working group
+   process; it is likely to be quite different from the process that
+   developed earlier versions of the document.  If additional or new
+   editors are assigned, the transition can be discussed, including its
+   reasons; this is best done as soon as possible.
+
+4.  Document History and Stability
+
+   Working group charters sometimes specify an initial set of existing
+   documents to use as a basis of the working group's activities.  That
+   'basis' can vary considerably, from simple input to working group
+   discussion, all the way to an advanced draft adopted by the working
+   group and subject only to minimal changes.  The role of a document
+   should be explicitly stated in the charter.
+
+
+
+
+
+Farrel & Crocker              Informational                     [Page 8]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   Within the scope of its charter, a working group is free to create
+   new documents.  It is not required that all drafts start as the
+   effort of an individual.  Of course, the criteria for brand new
+   documents are likely to be the same as for those imported into the
+   working group, with the additional and obvious requirement that the
+   Working Group Chairs will need to appoint authors/editors before any
+   work can progress.  Note that, from time to time, a working group
+   will form a design team to produce the first version of a working
+   group draft.  Design teams are discussed in Section 6.5 of [RFC2418].
+
+   Work that is brought to the IETF has different levels of completeness
+   and maturity, and different timings for having achieved those levels.
+   When the IETF charters a group and includes existing material, the
+   charter can cast the role of that material in very different ways.
+   It can treat it as:
+
+   *  no more than a set of ideas, to be used or ignored;
+
+   *  a basic design, with all of the actual details still fluid;
+
+   *  a rough draft, subject to extensive revision;
+
+   *  a solid specification that merely needs review, refinement, and
+      maybe enhancement;
+
+   *  a deployed technology that is best served by trying to protect its
+      installed base, but with some tolerance for changes that affect
+      interoperability;
+
+   *  a deployed technology for which protecting the installed base is
+      essential, including retention of core interoperability.
+
+   These suggest a wide range of possible constraints on working group
+   effort.  Technology is brought to the IETF at different points of
+   maturity along its life cycle, and the nature of the technology can
+   have widely varying utility in developing an Internet standard.
+
+   When technology is brand new, with at most some prototypes done as
+   proofs of concept, then significant changes to the specification will
+   not necessarily add much to the development and deployment costs.
+   However, when the technology is already part of a mature and
+   extensive operational deployment, any changes that are incompatible
+   are likely to be problematic for that market and can hinder adoption
+   of the changes overall.  For example, immediately after the
+   development investment is made -- and especially when there has been
+   considerable initial deployment but there is still room for quite a
+   bit more -- the installed and potential base might not take kindly to
+   disruptive standards work that undermines their recent investment.
+
+
+
+Farrel & Crocker              Informational                     [Page 9]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   Conversely, even a deployed technology with a solid base might be
+   inappropriate to deploy at Internet scale, and while a document
+   specifying such a technology might serve as a good starting point on
+   which to base a new specification, undermining of the deployed base
+   might be completely appropriate.
+
+   In reflecting upon the basis for adopting an existing draft and the
+   way it will be used by the working group, it is important to consider
+   the document's place in its life cycle, the needs of any installed
+   base, and the applicability of the draft's technology, when deciding
+   on the constraints to impose on document development.  It will all
+   depend on the constraints of the charter and the analysis of the
+   working group.
+
+5.  Some Issues for Consideration
+
+5.1.  Individual I-Ds under WG Care
+
+   Sometimes, a working group facilitates a draft but does not own it or
+   formally adopt it.  These are "individual" drafts [Individual].
+
+   As noted in Section 1.1 and reinforced in [ID-Guidelines], the
+   convention for identifying an I-D formally under the ownership of a
+   working group is by following the naming convention:
+
+                          draft-ietf-<wgname>-...
+
+   By contrast, documents that are still under the control of their
+   authors are known as "individual" I-Ds.  When these documents are
+   intended for consideration by a specific working group, the
+   convention is that the document uses the naming convention as
+   follows, where the second element is the last name of one of the
+   principal authors.
+
+                       draft-<lastname>-<wgname>...
+
+   Having the working group name following the personal name allows
+   tools to associate these drafts with the working group, even though
+   the filename identifies them as the work of individuals.
+
+   The working group can choose to apply any of its normal, internal
+   working group process management mechanisms to an individual I-D.
+   However, matters of ownership, working group final approval, and the
+   like are all subject to negotiation amongst the document authors,
+   working group, and Area Directors.
+
+
+
+
+
+
+Farrel & Crocker              Informational                    [Page 10]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   This is a rare situation, and Working Group Chairs can be assured
+   that the Area Directors will want to understand why the document
+   could not be adopted and owned by the working group.
+
+5.2.  WG Drafts Can Become Individual Drafts
+
+   A working group is not obligated to retain documents it has adopted.
+   Sometimes working group efforts conclude that a draft is no longer
+   appropriate for working group effort.  If a working group drops a
+   draft, then anyone is permitted to pursue it as an Individual or
+   Independent Submission, subject to the document's existing copyright
+   constraints.
+
+5.3.  Competing Drafts
+
+   Engineering for interesting topics often produces competing,
+   interesting proposals.  The reasons can be technical aesthetics,
+   engineering trade-offs, architectural differences, company economics,
+   and the like.  Although it is far more comfortable to entertain only
+   one proposal, a working group is free to pursue more than one.  Often
+   this is necessary until a clear preference develops.  Sometimes,
+   multiple versions are formally published, absent consensus among the
+   alternatives.
+
+   It is appealing to ask authors of competing proposals to find a way
+   to merge their work.  Where it makes sense to do this, it can produce
+   a single, strong specification.  The detailed discussions to merge
+   are often better held in a design team than amidst the dynamics of an
+   open working group mailing list.  The working group has ultimate
+   authority over any decisions, but it is not required that it be
+   involved in all the discussions.
+
+   On the other hand, some differences cannot be resolved, and
+   attempting a merge can produce a weaker result.  An example of this
+   problem of conflicting design goals is discussed in [Heli-Sub],
+   noting:
+
+      "Helicopters are great, and so are submarines.  The problem is
+      that if you try to build one vehicle to perform two fundamentally
+      different jobs, you're going to get a vehicle that does neither
+      job well."
+
+
+
+
+
+
+
+
+
+
+Farrel & Crocker              Informational                    [Page 11]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   Various management efforts can facilitate the handling of competing
+   proposals.  Some examples include:
+
+   *  Developing a requirements document that is independent of specific
+      proposals; this can highlight features that are deemed essential
+      and distinguish them from features that are of secondary
+      importance, and can facilitate a discussion about features without
+      reference to specific proposals.
+
+   *  Developing a comparison table of the proposals; this can aid
+      understanding of their differences.
+
+   *  Discussing the relative importance and effects of having one
+      proposal, versus multiple; this can focus people's efforts at
+      compromise and encourage a willingness to choose a single
+      proposal.
+
+   The problem of competing drafts can be particularly painful when it
+   arises in either of two circumstances:
+
+   *  If a second proposal appears as a new draft, just as the Chairs
+      were ready to poll the working group on adoption of the draft
+      containing the first proposal, then the authors of the first
+      proposal could feel affronted.  It does not follow that the second
+      draft was written to be difficult or derail the first: it might
+      even include better ideas.  So it is best not to disregard it.
+      However, automatically asking the authors to merge their work will
+      not necessarily produce a more solid solution and will not
+      guarantee faster progress.  This situation will be a judgement
+      call in each case, and it might help to ask the working group for
+      their opinion: shall the working group adopt one document as a
+      starting point and fold in the ideas from the second under the
+      control of consensus, or shall the working group wait until the
+      authors of both documents have reached agreement?
+
+   *  If the working group has already adopted an I-D on a specific
+      topic, the posting of a new individual I-D on the same topic could
+      be seen as an attack on the working group processes or decisions.
+      However, posting an I-D is often a good way to put new ideas into
+      concrete form, for public consideration and discussion.  The
+      Working Group Chairs will want to encourage the working group to
+      consider the new proposal.  Shall it be adopted and entirely
+      replace the current working group draft?  Shall the new ideas be
+      incorporated into the work of the working group through the normal
+      editorial process?  Shall the working group adopt a second
+      competing solution?  Or shall the new draft be rejected and not
+      adopted by the working group?
+
+
+
+
+Farrel & Crocker              Informational                    [Page 12]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+6.  Security Considerations
+
+   Beyond the credibility of the IETF, this document raises no security
+   concerns.
+
+7.  Acknowledgements
+
+   This document was developed from an IETF tutorial given by A. Farrel
+   at an IETF Working Group Chairs lunch [Farrel-Chairs].  L. Anderson
+   contributed useful comments.
+
+8.  Informative References
+
+   [Approval] IETF, "IETF Internet-Draft Initial Version Approval
+              Tracker", (IETF Datatracker),
+              <https://datatracker.ietf.org/
+              cgi-bin/wg/wg_init_rev_approval.cgi>.
+
+   [Consensus]
+              Resnick, P., "On Consensus and Humming in the IETF", Work
+              in Progress, April 2014.
+
+   [Farrel-Chairs]
+              Farrel, A., "What is a Working Group ID (and when to adopt
+              one)", (IETF 78 WG chairs lunch Material), July 2010,
+              <http://wiki.tools.ietf.org/group/edu/wiki/IETF78#>.
+
+   [Heli-Sub]
+              Rose, M., "On Helicopters and Submarines", ACM Queue -
+              Instant Messaging, Vol. 1, Issue 8, Page 10,
+              <http://dl.acm.org/ft_gateway.cfm?id=966726>.
+
+   [ID-Guidelines]
+              Housley, R., Ed., "Guidelines to Authors of Internet-
+              Drafts", December 2010,
+              <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
+
+   [ID-Info]  Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs)
+              submitted for RFC publication", May 2009,
+              <https://www.ietf.org/id-info/checklist.html>.
+
+   [IDNITS]   IETF, "IDNITS Tool", 2013,
+              <https://tools.ietf.org/tools/idnits/>.
+
+   [Individual]
+              IESG, "Guidance on Area Director Sponsoring of Documents",
+              March 2007, <http://www.ietf.org/iesg/statement/
+              ad-sponsoring-docs.html>.
+
+
+
+Farrel & Crocker              Informational                    [Page 13]
+
+RFC 7221                 Handling of I-Ds by WGs              April 2014
+
+
+   [RFC-Auth-Ed]
+              RFC Editor, "RFC Editorial Guidelines and Procedures --
+              Author Overload", 2014,
+              <http://www.rfc-editor.org/policy.html#policy.authlist>.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process --
+              Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2418]  Bradner, S., "IETF Working Group Guidelines and
+              Procedures", BCP 25, RFC 2418, September 1998.
+
+   [RFC6702]  Polk, T. and P. Saint-Andre, "Promoting Compliance with
+              Intellectual Property Rights (IPR) Disclosure Rules",
+              RFC 6702, August 2012.
+
+   [Tao]      Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to
+              the Internet Engineering Task Force", 2012,
+              <http://www.ietf.org/tao.html>.
+
+Authors' Addresses
+
+   Adrian Farrel
+   Juniper Networks
+
+   EMail: adrian@olddog.co.uk
+
+
+   Dave Crocker (editor)
+   Brandenburg InternetWorking
+   675 Spruce Drive
+   Sunnyvale, CA  94086
+   USA
+
+   Phone: +1.408.246.8253
+   EMail: dcrocker@bbiw.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrel & Crocker              Informational                    [Page 14]
+