From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7221.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc7221.txt (limited to 'doc/rfc/rfc7221.txt') 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--... + + 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--... + + (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--... + + 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--... + + 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), + . + + [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, + . + + [Heli-Sub] + Rose, M., "On Helicopters and Submarines", ACM Queue - + Instant Messaging, Vol. 1, Issue 8, Page 10, + . + + [ID-Guidelines] + Housley, R., Ed., "Guidelines to Authors of Internet- + Drafts", December 2010, + . + + [ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs) + submitted for RFC publication", May 2009, + . + + [IDNITS] IETF, "IDNITS Tool", 2013, + . + + [Individual] + IESG, "Guidance on Area Director Sponsoring of Documents", + March 2007, . + + + +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, + . + + [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, + . + +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] + -- cgit v1.2.3