summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7221.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7221.txt')
-rw-r--r--doc/rfc/rfc7221.txt787
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]
+