rfc7221.txt   draft-carpenter-gendispatch-rfc7221bis-02.txt 
Internet Engineering Task Force (IETF) A. Farrel Network Working Group A. Farrel
Request for Comments: 7221 Juniper Networks Internet-Draft Old Dog Consulting
Category: Informational D. Crocker, Ed. Obsoletes: 7221 (if approved) D. Crocker
ISSN: 2070-1721 Brandenburg InternetWorking Intended status: Informational Brandenburg InternetWorking
April 2014 Expires: 24 September 2025 B. E. Carpenter
Univ. of Auckland
F. Gont
SI6 Networks
M. Richardson
Sandelman Software Works
23 March 2025
Handling of Internet-Drafts by IETF Working Groups Handling and Adoption of Internet-Drafts by IETF Working Groups
draft-carpenter-gendispatch-rfc7221bis-02
Abstract Abstract
The productive output of an IETF working group is documents, as The productive output of an IETF working group is documents, as
mandated by the working group's charter. When a working group is mandated by the working group's charter. When a working group is
ready to develop a particular document, the most common mechanism is ready to develop a particular document, the most common mechanism is
for it to "adopt" an existing document as a starting point. The for it to "adopt" an existing document as a starting point. The
document that a working group adopts and then develops further is document that a working group adopts and then develops further is
based on initial input at varying levels of maturity. An initial based on initial input at varying levels of maturity. An initial
working group draft might be a document already in wide use, or it 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 be a blank sheet, wholly created by the working group, or it
might represent any level of maturity in between. This document might represent any level of maturity in between. This document
discusses how a working group typically handles the formal documents discusses how a working group typically handles the formal documents
that it targets for publication. that it targets for publication.
Status of This Memo Status of This Memo
This document is not an Internet Standards Track specification; it is This Internet-Draft is submitted in full conformance with the
published for informational purposes. provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Not all documents Drafts is at https://datatracker.ietf.org/drafts/current/.
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, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
http://www.rfc-editor.org/info/rfc7221. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice This Internet-Draft will expire on 24 September 2025.
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents (https://trustee.ietf.org/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Revised BSD License text as
include Simplified BSD License text as described in Section 4.e of described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Revised BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ....................................................2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. What Is a WG Draft? ........................................3 1.1. What Is a WG Draft? . . . . . . . . . . . . . . . . . . . 3
1.2. Working Group Authority and Consensus ......................4 1.2. Working Group Authority and Consensus . . . . . . . . . . 4
1.3. Questions Considered in This Document ......................5 1.3. Questions Considered in This Document . . . . . . . . . . 5
2. Adoption Sequence ...............................................6 2. Adoption Sequence . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Common Steps ...............................................6 2.1. Consequences of WG Adoption of an Internet-Draft . . . . 6
2.2. Criteria for Adoption ......................................6 2.2. Relationship to Formal IETF Rules . . . . . . . . . . . . 6
3. Authors/Editors .................................................8 2.3. Common Steps . . . . . . . . . . . . . . . . . . . . . . 6
4. Document History and Stability ..................................8 2.4. Criteria for Adoption . . . . . . . . . . . . . . . . . . 8
5. Some Issues for Consideration ..................................10 3. Authors/Editors . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Individual I-Ds under WG Care .............................10 4. Document History and Stability . . . . . . . . . . . . . . . 10
5.2. WG Drafts Can Become Individual Drafts ....................11 5. Some Issues for Consideration . . . . . . . . . . . . . . . . 11
5.3. Competing Drafts ..........................................11 5.1. Individual I-Ds under WG Care . . . . . . . . . . . . . . 11
6. Security Considerations ........................................13 5.2. Withdrawal of an Adopted Internet-Draft . . . . . . . . . 12
7. Acknowledgements ...............................................13 5.3. Competing Drafts . . . . . . . . . . . . . . . . . . . . 13
8. Informative References .........................................13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The productive output of an IETF working group (WG) is documents, as The productive output of an IETF working group (WG) is documents, as
mandated by the working group's charter. Working groups develop mandated by the working group's charter. Working groups develop
these documents based on initial input at varying levels of maturity. these documents based on initial input at varying levels of maturity.
An initial working group draft might be a document already in wide 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 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 group, or it might represent any level of maturity in between. This
document discusses how a working group typically handles the formal document discusses how a working group typically handles the formal
skipping to change at page 3, line 14 skipping to change at page 3, line 16
Within the general constraints of formal IETF process and the Within the general constraints of formal IETF process and the
specific constraints of a working group's charter, there can be specific constraints of a working group's charter, there can be
considerable freedom in the adoption and development of drafts. As considerable freedom in the adoption and development of drafts. As
with most IETF activities, the ultimate arbiter of such choices is with most IETF activities, the ultimate arbiter of such choices is
working group agreement, within the constraints of its charter. As working group agreement, within the constraints of its charter. As
with most working group management, this agreement might be explicit with most working group management, this agreement might be explicit
or implicit, depending upon the efficiencies that the group deems or implicit, depending upon the efficiencies that the group deems
appropriate. appropriate.
NOTE: This document is intentionally non-normative. It is meant as NOTE: This document is intentionally non-normative. It is meant as a
a guide to common practice, rather than as a formal definition of guide to common practice, rather than as a formal definition of what
what is permissible. is permissible.
1.1. What Is a WG Draft? 1.1. What Is a WG Draft?
Working group drafts are documents that are subject to IETF working Working group drafts are documents that are subject to IETF working
group revision control, with advancement for publication as an RFC group revision control, with advancement for publication as an RFC
requiring rough consensus in the working group and then in the requiring rough consensus in the working group and then in the
broader IETF. Creation or adoption of a draft by a working group -- broader IETF. Creation or adoption of a draft by a working group ---
as well as substantive changes to the document -- need to represent as well as substantive changes to the document --- need to represent
working group rough consensus. working group rough consensus.
Documents under development in the IETF community are distributed as Documents under development in the IETF community are distributed as
Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this Internet-Drafts (I-Ds) [RFC2026] [ID-Info]. Working groups use this
mechanism for producing their official output, per Section 7.2 of mechanism for producing their official output, per Section 7.2 of
[RFC2418] and Section 6.3 of [Tao]. The common convention for [RFC2418] and Section 6.3 of [Tao]. The common convention for
identifying an I-D formally under the ownership of a working group is 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 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 and the working group name in the third field, per Section 7 of
[ID-Guidelines]. That is: [ID-Guidelines]. That is:
draft-ietf-<wgname>-... draft-ietf-<wgname>-...
In contrast, individual submissions are drafts being created and In contrast, individual submissions are drafts being created and
pursued outside of a working group, although a working group might pursued outside of a working group, although a working group might
choose to adopt the draft later, as discussed below. Anyone is free choose to adopt the draft later, as discussed below. Anyone is free
to create an individual submission at any time. Such documents are to create an individual submission at any time. Such documents are
typically distinguished through the use of the author/editor's last typically distinguished through the use of the author/editor's last
name, in the style of: name, in the style of:
draft-<lastname>-... draft-<lastname>-...
(Also see Section 5.1 for an elaboration on this naming.) (Also see Section 5.1 for an elaboration on this naming.)
Responsibility for direct revision of a working group I-D is assigned Responsibility for direct revision of a working group I-D is assigned
to its editors and authors. See Section 3 for discussion about their to its editors and authors. See Section 3 for discussion about their
selection and role. selection and role.
1.2. Working Group Authority and Consensus 1.2. Working Group Authority and Consensus
A premise of the IETF is that, within a working group, it is the 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 working group itself that has final authority over the content of its
documents, within the constraints of the working group's charter. No documents, within the constraints of the working group's charter. No
individual has special authority for the content. The Chairs assign individual has special authority for the content. The Chairs assign
skipping to change at page 4, line 24 skipping to change at page 4, line 27
"rough consensus" construct, which is the prime example of the IETF's "rough consensus" construct, which is the prime example of the IETF's
preference for pragmatics over niceties. Unanimous agreement is preference for pragmatics over niceties. Unanimous agreement is
always desirable, but more approximate (rough) agreement will always desirable, but more approximate (rough) agreement will
suffice, as long as it is clear and strong. suffice, as long as it is clear and strong.
Other than for selection of document authors/editors, as discussed in Other than for selection of document authors/editors, as discussed in
Section 3, working group decision-making about document management is Section 3, working group decision-making about document management is
subject to normal IETF rough consensus rules. Useful descriptions of subject to normal IETF rough consensus rules. Useful descriptions of
this process for a working group are in Section 3.3 of [RFC2418] and 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 Section 4.2 of [Tao]. Discussion of the nature of rough consensus
can be found in [Consensus]. can be found in [RFC7282].
In terms of the IETF's formal rough consensus processes, the working In terms of the IETF's formal rough consensus processes, the working
group explicitly develops, modifies, reviews, and approves document group explicitly develops, modifies, reviews, and approves document
content, according to overt rough consensus. For difficult topics content, according to overt rough consensus. For difficult topics
and/or difficult working group dynamics, this laborious process and/or difficult working group dynamics, this laborious process
really is essential. Its diligence validates progress at each step really is essential. Its diligence validates progress at each step
along the way. However, working groups often handle simpler matters along the way. However, working groups often handle simpler matters
more simply, such as allowing a Chair to assert the likely agreement more simply, such as allowing a Chair to assert the likely agreement
and then merely call for objections. Ultimately, the mode of working and then merely call for objections. Ultimately, the mode of working
group decision-making is determined by the comfort and engagement of group decision-making is determined by the comfort and engagement of
skipping to change at page 5, line 10 skipping to change at page 5, line 10
working group is operating in the mode of active, direct author/ working group is operating in the mode of active, direct author/
editor content development, an easy validation method is simply to editor content development, an easy validation method is simply to
have Chairs query the working group when a new document version have Chairs query the working group when a new document version
appears, asking for comments and concerns. appears, asking for comments and concerns.
In general, when it is not completely obvious what the opinion of the 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 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 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' is asked can make a difference. In particular, a general 'yes/no'
question often is not as helpful as asking supporters and detractors question often is not as helpful as asking supporters and detractors
of a draft -- or of the decision under consideration -- to provide of a draft --- or of the decision under consideration --- to provide
their reasons, not merely their preferences. In effect, this treats their reasons, not merely their preferences. In effect, this treats
the matter of consensus as an ongoing discussion. Ideally, the the matter of consensus as an ongoing discussion. Ideally, the
discussion can produce changes in the document or in participant discussion can produce changes in the document or in participant
views, or both. views, or both.
1.3. Questions Considered in This Document 1.3. Questions Considered in This Document
The purpose of this document is to discuss the criteria and sequence The purpose of this document is to discuss the criteria and sequence
typically followed when adopting and developing a formal IETF working typically followed when adopting and developing a formal IETF working
group document. Therefore, this document considers the following group document. Therefore, this document considers the following
skipping to change at page 6, line 6 skipping to change at page 6, line 4
* Can a document be created as a WG I-D from scratch? * Can a document be created as a WG I-D from scratch?
* How can competing drafts be handled? * How can competing drafts be handled?
* Can an individual I-D be under the care of a WG? * Can an individual I-D be under the care of a WG?
* Can a WG I-D become an individual I-D? * Can a WG I-D become an individual I-D?
2. Adoption Sequence 2. Adoption Sequence
2.1. Consequences of WG Adoption of an Internet-Draft
2.1. Common Steps After a draft has been formally adopted by a WG, its original authors
no longer have formal change control of the text. In addition to the
normal consequence of posting a draft, i.e., that it becomes an IETF
Contribution under [RFC5378], all future substantive changes to the
draft require WG consensus and are no longer at the authors' sole
discretion.
As a practical matter, the original authors usually continue to edit
the document and make routine editorial decisions, but substantive
changes must be referred to the WG and require WG rough consensus,
consistently with [RFC2418]. It is also possible that new authors or
editors will join the draft, or that previous authors may withdraw.
Adoption represents a commitment that the WG will spend time and
effort on the draft, but it does not guarantee that the draft will
reach WG consensus and be submitted to the IESG for publication as an
RFC.
2.2. Relationship to Formal IETF Rules
A WG Adoption Call of an I-D is not a required step of the IETF
standards process. The WG chairs decide what documents belong in the
WG, and can create new documents by fiat. A simple situation would
be if a WG decides that an existing document should be split into two
pieces: there is no reason to adopt each piece, that is needless
bureaucracy. Similarly, if there is WG consensus to merge two drafts
into one, a complete adoption procedure may be pointless. However, a
WG that decides to create a design team to solve a problem has not
agreed to adopt the result automatically. The design team's output
has the same status as any other draft, even if it has a high chance
of being adopted.
It is legitimate for a draft to be submitted to the IESG as described
in [RFC2026] without a formal adoption by a WG. Clearly this should
only happen when the WG Chairs are already satisfied that there is
strong consensus to do so.
2.3. Common Steps
Any participant may request the adoption of a draft, after there has
been a period of technical discussion of the draft in the relevant
WG.
WG Chairs have discretion about when to issue a call for adoption,
but they should do so regardless of their own opinions, when the WG
discussion shows that there is clear interest in the draft in
question.
When there is interest in adopting a document as a new working group When there is interest in adopting a document as a new working group
document, the Chairs often: document, the Chairs (or a WG Secretary, if there is one) typically:
1. Remind current draft owners that they are transferring change 1. Remind current draft authors that they are transferring change
control for the document to the IETF. (This is a particularly control for the document to the IETF. (This is a particularly
significant point for a document covered by proprietary significant point for a document covered by proprietary
interests, because it typically entails a negotiation between the interests, because it typically entails a negotiation between the
current owners and the IETF, including a formal agreement.) current owners and the IETF, including a formal agreement.)
2. Check for known IPR that needs to be disclosed, using some 2. Check for known IPR that needs to be disclosed under [RFC8179],
technique like those described in [RFC6702]. using some technique like those described in [RFC6702]. This
might be combined with the following action.
3. Obtain working group rough consensus. 3. Obtain working group rough consensus. Typically the Chairs or WG
Secretary will send a call for adoption of a draft to the WG
mailing list with at least two weeks time to respond.
4. Choose document editors. * After this period, a WG Chair should, in a timely fashion,
consider the comments and discussion in order to judge whether
there is rough consensus to adopt the draft, and whether there
is enough interest in the work that its completion is likely.
The result should be announced to the WG.
5. Instruct authors to post the WG I-D. 4. Choose document editors. As noted above, these might or might
not be the existing authors.
5. Request authors to post the WG I-D according to the naming
convention described above.
6. Approve posting [Approval]. 6. Approve posting [Approval].
7. Ensure that the non-working group version of the draft is marked 7. Ensure that the non-working group version of the draft is marked
as being replaced by this working group version. as being replaced by this working group version.
8. Encourage everyone to enjoy the ensuing working group 8. Encourage everyone to enjoy the ensuing working group
discussion... discussion...
2.2. Criteria for Adoption 2.4. Criteria for Adoption
No formal specification for working group 'adoption' of a draft No formal specification for working group 'adoption' of a draft
exists; the current document is meant to provide a description of exists; the current document is meant to provide a description of
common activities for this, but again note that it is not normative. common activities for this, but again note that it is not normative.
Participants responding to a WG call for adoption should consider
these points.
There are some basic considerations when deciding to adopt a draft: There are some basic considerations when deciding to adopt a draft:
* Is there a charter milestone that explicitly calls for such a * Is there a charter milestone that explicitly calls for such a
document? document?
* Is the topic of the I-D within scope for the working group? * Is the topic of the I-D within scope for the working group?
* If not already in scope, is a simple modification to the charter
feasible and warranted?
* Is the purpose of the draft sufficiently clear? * Is the purpose of the draft sufficiently clear?
* Is the proposal useful?
* Does the document provide an acceptable platform for continued * Does the document provide an acceptable platform for continued
effort by the working group? effort by the working group? In particular, is the quality of
writing sufficient to serve as the basis further work?
* What are the process or technical objections to adoption of the * What are the process or technical objections to adoption of the
draft? draft?
* Is the draft likely to be completed in a timely manner? * Is the draft likely to be completed in a timely manner?
* Does the intended status of the document seem reasonable to the * Does the intended status of the document seem reasonable to the
working group? 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? * Does the draft carry known intellectual property rights issues?
If so, are the IPR disclosures acceptable?
* Is the work in conflict with work elsewhere in the IETF?
* Is there strong working group support for working on the draft? * Is there strong working group support for working on the draft?
An informal summary of these questions is: Is this a problem the WG
wants to solve in a way approximately as described in the draft?
Adoption has some basic pragmatics: Adoption has some basic pragmatics:
Rough consensus: Working group agreement to adopt is not required Rough consensus: Working group agreement to adopt is not required to
to be unanimous [RFC2418]. be unanimous [RFC2418].
Initial, not final: The writing quality is not required to be Initial, not final: The writing quality is not required to be "ready
"ready for publication", although writing quality can be a for publication", although writing quality can be a problem and
problem and does need explicit attention; although not does need explicit attention; although not mandatory, it is good
mandatory, it is good practice to check whether a new working practice to check whether a new working group draft passes
group draft passes [IDNITS]. [IDNITS].
Adoption, not approval: The document is not required to already Adoption, not approval: The document is not required to already
contain a complete and/or sufficient solution, although of contain a complete and/or sufficient solution, although of course
course this can be helpful. Equally, adoption by a working this can be helpful. Equally, adoption by a working group does
group does not guarantee publication of the document as an RFC. not guarantee publication of the document as an RFC.
Group, not Chairs: Concerning the draft, the position of the Group, not Chairs: Concerning the draft, the position of the Working
Working Group Chairs has no special authority, except to assess Group Chairs has no special authority, except to assess working
working group consensus. group consensus.
REMINDER: Once a working group adopts a draft, the document is owned REMINDER: Once a working group adopts a draft, the document is owned
by the working group and can be changed however the working group by the working group and can be changed however the working group
decides, within the bounds of IETF process and the working group decides, within the bounds of IETF process and the working group
charter. Absent explicit agreement, adopting a document does not charter. Absent explicit agreement, adopting a document does not
automatically mean that the working group has agreed to all of its automatically mean that the working group has agreed to all of its
content. So a working group (or its charter) might explicitly content. So a working group (or its charter) might explicitly
dictate the basis for retaining, removing, or modifying some or dictate the basis for retaining, removing, or modifying some or
all of a draft's content, technical details, or the like. all of a draft's content, technical details, or the like.
However, in the absence of such constraints, it is worth having However, in the absence of such constraints, it is worth having
skipping to change at page 8, line 21 skipping to change at page 9, line 49
NOTE: In this document, the terms 'author' and 'editor' are meant NOTE: In this document, the terms 'author' and 'editor' are meant
interchangeably. Within the IETF, the distinction between an interchangeably. Within the IETF, the distinction between an
'author' and an 'editor' is, at best, subjective. A simplistic 'author' and an 'editor' is, at best, subjective. A simplistic
rule of thumb is that editors tend to do the mechanics of rule of thumb is that editors tend to do the mechanics of
incorporating working group detail, whereas authors tend to create incorporating working group detail, whereas authors tend to create
the detail, subject to working group approval. That is, one role the detail, subject to working group approval. That is, one role
is more active with the content, and the other is more passive. is more active with the content, and the other is more passive.
It is a responsibility of the Working Group Chairs to ensure that It is a responsibility of the Working Group Chairs to ensure that
document authors make modifications in accord with working group document authors make modifications in accord with working group
rough consensus. Authors/editors are solely chosen by the Chairs rough consensus. Authors/editors are solely chosen by the Chairs
-- although the views of the working group should be considered -- --- although the views of the working group should be considered
and are subject to replacement for a variety of reasons, as the --- and are subject to replacement for a variety of reasons, as
Chairs see fit. the Chairs see fit.
For existing documents that are being adopted by a working group, For existing documents that are being adopted by a working group,
there is a special challenge in the selection of document editors. there is a special challenge in the selection of document editors.
Because the document has already had editors, the question "Are the Because the document has already had editors, the question "Are the
same people appropriate for continuing the task?" is asked. same people appropriate for continuing the task?" is asked.
Sometimes the answer is yes, but this is not automatic. The process Sometimes the answer is yes, but this is not automatic. The process
within an IETF working group can be quite different from the process within an IETF working group can be quite different from the process
that created previous versions. This well might make it appropriate that created previous versions. This well might make it appropriate
to select one or more new editors, either as additions to the editor to select one or more new editors, either as additions to the editor
team or as primary pen-holders (effectively reclassifying the team or as primary pen-holders (effectively reclassifying the
skipping to change at page 9, line 49 skipping to change at page 11, line 26
maturity along its life cycle, and the nature of the technology can maturity along its life cycle, and the nature of the technology can
have widely varying utility in developing an Internet standard. have widely varying utility in developing an Internet standard.
When technology is brand new, with at most some prototypes done as When technology is brand new, with at most some prototypes done as
proofs of concept, then significant changes to the specification will proofs of concept, then significant changes to the specification will
not necessarily add much to the development and deployment costs. not necessarily add much to the development and deployment costs.
However, when the technology is already part of a mature and However, when the technology is already part of a mature and
extensive operational deployment, any changes that are incompatible extensive operational deployment, any changes that are incompatible
are likely to be problematic for that market and can hinder adoption are likely to be problematic for that market and can hinder adoption
of the changes overall. For example, immediately after the of the changes overall. For example, immediately after the
development investment is made -- and especially when there has been development investment is made --- and especially when there has been
considerable initial deployment but there is still room for quite a considerable initial deployment but there is still room for quite a
bit more -- the installed and potential base might not take kindly to bit more --- the installed and potential base might not take kindly
disruptive standards work that undermines their recent investment. to disruptive standards work that undermines their recent investment.
Conversely, even a deployed technology with a solid base might be Conversely, even a deployed technology with a solid base might be
inappropriate to deploy at Internet scale, and while a document inappropriate to deploy at Internet scale, and while a document
specifying such a technology might serve as a good starting point on specifying such a technology might serve as a good starting point on
which to base a new specification, undermining of the deployed base which to base a new specification, undermining of the deployed base
might be completely appropriate. might be completely appropriate.
In reflecting upon the basis for adopting an existing draft and the 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 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 the document's place in its life cycle, the needs of any installed
skipping to change at page 10, line 30 skipping to change at page 12, line 9
5.1. Individual I-Ds under WG Care 5.1. Individual I-Ds under WG Care
Sometimes, a working group facilitates a draft but does not own it or Sometimes, a working group facilitates a draft but does not own it or
formally adopt it. These are "individual" drafts [Individual]. formally adopt it. These are "individual" drafts [Individual].
As noted in Section 1.1 and reinforced in [ID-Guidelines], the As noted in Section 1.1 and reinforced in [ID-Guidelines], the
convention for identifying an I-D formally under the ownership of a convention for identifying an I-D formally under the ownership of a
working group is by following the naming convention: working group is by following the naming convention:
draft-ietf-<wgname>-... draft-ietf-<wgname>-...
By contrast, documents that are still under the control of their By contrast, documents that are still under the control of their
authors are known as "individual" I-Ds. When these documents are authors are known as "individual" I-Ds. When these documents are
intended for consideration by a specific working group, the intended for consideration by a specific working group, the
convention is that the document uses the naming convention as convention is that the document uses the naming convention as
follows, where the second element is the last name of one of the follows, where the second element is the last name of one of the
principal authors. principal authors.
draft-<lastname>-<wgname>... draft-<lastname>-<wgname>...
Having the working group name following the personal name allows Having the working group name following the personal name allows
tools to associate these drafts with the working group, even though tools to associate these drafts with the working group, even though
the filename identifies them as the work of individuals. the filename identifies them as the work of individuals.
The working group can choose to apply any of its normal, internal The working group can choose to apply any of its normal, internal
working group process management mechanisms to an individual I-D. working group process management mechanisms to an individual I-D.
However, matters of ownership, working group final approval, and the However, matters of ownership, working group final approval, and the
like are all subject to negotiation amongst the document authors, like are all subject to negotiation amongst the document authors,
working group, and Area Directors. working group, and Area Directors.
This is a rare situation, and Working Group Chairs can be assured This is a rare situation, and Working Group Chairs can be assured
that the Area Directors will want to understand why the document that the Area Directors will want to understand why the document
could not be adopted and owned by the working group. could not be adopted and owned by the working group.
5.2. WG Drafts Can Become Individual Drafts 5.2. Withdrawal of an Adopted Internet-Draft
A working group is not obligated to retain documents it has adopted. It sometimes happens that an adopted draft does not reach WG
Sometimes working group efforts conclude that a draft is no longer consensus to be submitted to the IESG for publication as an RFC due
appropriate for working group effort. If a working group drops a to lack of interest, lack of effort, or lack of agreement. In such a
draft, then anyone is permitted to pursue it as an Individual or case, it may be desirable for the WG to formally withdraw the WG
Independent Submission, subject to the document's existing copyright draft, such that it is explicitly removed from the WG's agenda. If a
constraints. working group drops a draft, then anyone (most likely the original
authors) can pursue it as an Individual or Independent Submission,
subject to the document's existing copyright constraints.
The withdrawal of a WG document should be the result of an explicit
decision by the relevant WG, and the Chairs should consider the
following recommendations.
* Upon evidence that progress on a WG draft has been stalled for a
considerable period of time, a WG chair should evaluate the
reasons of the apparent lack of progress. Such reasons may may
include lack of interest, lack of effort, or lack of consensus.
* When progress on a document has been stalled for a considerable
period of time, a WG chair, in consultation with the WG draft
authors and editors, should attempt to resume progress by taking
appropriate actions that will normally depend on the nature of the
lack of progress. For example, a WG draft that has been stalled
due to apparent lack of interest may benefit from a call for a
number of volunters to produce detailed reviews of the WG draft.
Similarly, a WG draft that has been stalled due to lack of effort
by its authors/editors may benefit from the incorporation of new
WG draft editors or the replacement of some of the existing ones.
* If after succesive failed attempts to make progress on a WG draft
its completion remains unlikely, the WG Chairs may, at their own
discretion, conclude that it is time for the WG to consider the
formal withdrawal of the WG draft.
* In such case, a WG Chair or WG Secretary would send a formal WG
consensus call for withdrawal of the WG draft to the WG mailing
list with at least two weeks time to respond, explaining the
events that have triggered the aforementioned consensus call.
* After this period, a WG Chair should, in a timely fashion,
consider the comments and discussion in order to judge whether
there is any concrete evidence that completion of the work may now
be feasible, or whether completion of the work remains unlikely.
* If further progress on the document remains unlikely, the WG Chair
will announce the result of the consensus call and the formal
withdrawal of the WG document. This will result in the document
being removed from the WG's agenda and returned to the authors'
control.
5.3. Competing Drafts 5.3. Competing Drafts
Engineering for interesting topics often produces competing, Engineering for interesting topics often produces competing,
interesting proposals. The reasons can be technical aesthetics, interesting proposals. The reasons can be technical aesthetics,
engineering trade-offs, architectural differences, company economics, engineering trade-offs, architectural differences, company economics,
and the like. Although it is far more comfortable to entertain only 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 one proposal, a working group is free to pursue more than one. Often
this is necessary until a clear preference develops. Sometimes, this is necessary until a clear preference develops. Sometimes,
multiple versions are formally published, absent consensus among the multiple versions are formally published, absent consensus among the
skipping to change at page 11, line 42 skipping to change at page 14, line 18
are often better held in a design team than amidst the dynamics of an are often better held in a design team than amidst the dynamics of an
open working group mailing list. The working group has ultimate open working group mailing list. The working group has ultimate
authority over any decisions, but it is not required that it be authority over any decisions, but it is not required that it be
involved in all the discussions. involved in all the discussions.
On the other hand, some differences cannot be resolved, and On the other hand, some differences cannot be resolved, and
attempting a merge can produce a weaker result. An example of this attempting a merge can produce a weaker result. An example of this
problem of conflicting design goals is discussed in [Heli-Sub], problem of conflicting design goals is discussed in [Heli-Sub],
noting: noting:
"Helicopters are great, and so are submarines. The problem is "Helicopters are great, and so are submarines. The problem is
that if you try to build one vehicle to perform two fundamentally that if you try to build one vehicle to perform two fundamentally
different jobs, you're going to get a vehicle that does neither different jobs, you're going to get a vehicle that does neither
job well." job well."
Various management efforts can facilitate the handling of competing Various management efforts can facilitate the handling of competing
proposals. Some examples include: proposals. Some examples include:
* Developing a requirements document that is independent of specific * Developing a requirements document that is independent of specific
proposals; this can highlight features that are deemed essential proposals; this can highlight features that are deemed essential
and distinguish them from features that are of secondary and distinguish them from features that are of secondary
importance, and can facilitate a discussion about features without importance, and can facilitate a discussion about features without
reference to specific proposals. reference to specific proposals.
skipping to change at page 13, line 12 skipping to change at page 15, line 29
competing solution? Or shall the new draft be rejected and not competing solution? Or shall the new draft be rejected and not
adopted by the working group? adopted by the working group?
6. Security Considerations 6. Security Considerations
Beyond the credibility of the IETF, this document raises no security Beyond the credibility of the IETF, this document raises no security
concerns. concerns.
7. Acknowledgements 7. Acknowledgements
This document was developed from an IETF tutorial given by A. Farrel This document was developed from an IETF tutorial given by A. Farrel
at an IETF Working Group Chairs lunch [Farrel-Chairs]. L. Anderson at an IETF Working Group Chairs lunch [Farrel-Chairs]. L. Anderson
contributed useful comments. contributed useful comments. It was updated in September 2020 to add
more detail on the adoption process.
8. Informative References 8. References
[Approval] IETF, "IETF Internet-Draft Initial Version Approval 8.1. Normative References
Tracker", (IETF Datatracker),
<https://datatracker.ietf.org/
cgi-bin/wg/wg_init_rev_approval.cgi>.
[Consensus] [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
Resnick, P., "On Consensus and Humming in the IETF", Work 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
in Progress, April 2014. <https://www.rfc-editor.org/rfc/rfc2026>.
[RFC2418] Bradner, S., "IETF Working Group Guidelines and
Procedures", BCP 25, RFC 2418, DOI 10.17487/RFC2418,
September 1998, <https://www.rfc-editor.org/rfc/rfc2418>.
[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., "Rights
Contributors Provide to the IETF Trust", BCP 78, RFC 5378,
DOI 10.17487/RFC5378, November 2008,
<https://www.rfc-editor.org/rfc/rfc5378>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179,
DOI 10.17487/RFC8179, May 2017,
<https://www.rfc-editor.org/rfc/rfc8179>.
8.2. Informative References
[Approval] IETF, "IETF Internet-Draft Initial Version Approval
Tracker", n.d., <https://datatracker.ietf.org/cgi-bin/wg/
wg_init_rev_approval.cgi>.
[Farrel-Chairs] [Farrel-Chairs]
Farrel, A., "What is a Working Group ID (and when to adopt IETF, "What is a Working Group ID (and when to adopt one)
one)", (IETF 78 WG chairs lunch Material), July 2010, (IETF 78 WG chairs lunch Material)", July 2010,
<http://wiki.tools.ietf.org/group/edu/wiki/IETF78#>. <http://wiki.tools.ietf.org/group/edu/wiki/IETF78>.
[Heli-Sub] [Heli-Sub] Rose, M., "On Helicopters and Submarines (ACM Queue -
Rose, M., "On Helicopters and Submarines", ACM Queue - Instant Messaging, Vol. 1, Issue 8, Page 10)", November
Instant Messaging, Vol. 1, Issue 8, Page 10, 2003, <http://dl.acm.org/ft_gateway.cfm?id=966726>.
<http://dl.acm.org/ft_gateway.cfm?id=966726>.
[ID-Guidelines] [ID-Guidelines]
Housley, R., Ed., "Guidelines to Authors of Internet- Housley(Ed.), R., "Guidelines to Authors of Internet-
Drafts", December 2010, Drafts", December 2010,
<http://www.ietf.org/ietf-ftp/1id-guidelines.txt>. <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>.
[ID-Info] Wijnen, B., Ed., "Checklist for Internet-Drafts (IDs) [ID-Info] Wijnen(Ed.), B., "Checklist for Internet-Drafts (IDs)
submitted for RFC publication", May 2009, submitted for RFC publication", May 2009,
<https://www.ietf.org/id-info/checklist.html>. <https://www.ietf.org/id-info/checklist.html>.
[IDNITS] IETF, "IDNITS Tool", 2013, [IDNITS] IETF, "IDNITS Tool", 2013,
<https://tools.ietf.org/tools/idnits/>. <https://tools.ietf.org/tools/idnits/>.
[Individual] [Individual]
IESG, "Guidance on Area Director Sponsoring of Documents", IESG, "Guidance on Area Director Sponsoring of Documents",
March 2007, <http://www.ietf.org/iesg/statement/ March 2007, <http://www.ietf.org/iesg/statement/ad-
ad-sponsoring-docs.html>. sponsoring-docs.html>.
[RFC-Auth-Ed] [RFC-Auth-Ed]
RFC Editor, "RFC Editorial Guidelines and Procedures -- RFC Editor, "RFC Editorial Guidelines and Procedures --
Author Overload", 2014, Author Overload", 2014,
<http://www.rfc-editor.org/policy.html#policy.authlist>. <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 [RFC6702] Polk, T. and P. Saint-Andre, "Promoting Compliance with
Intellectual Property Rights (IPR) Disclosure Rules", Intellectual Property Rights (IPR) Disclosure Rules",
RFC 6702, August 2012. RFC 6702, DOI 10.17487/RFC6702, August 2012,
<https://www.rfc-editor.org/rfc/rfc6702>.
[Tao] Hoffman, P., Ed., "The Tao of IETF - A Novice's Guide to [RFC7282] Resnick, P., "On Consensus and Humming in the IETF",
RFC 7282, DOI 10.17487/RFC7282, June 2014,
<https://www.rfc-editor.org/rfc/rfc7282>.
[Tao] Hoffman(Ed.), P., "The Tao of IETF - A Novice's Guide to
the Internet Engineering Task Force", 2012, the Internet Engineering Task Force", 2012,
<http://www.ietf.org/tao.html>. <http://www.ietf.org/tao.html>.
Authors' Addresses Authors' Addresses
Adrian Farrel Adrian Farrel
Juniper Networks Old Dog Consulting
Email: adrian@olddog.co.uk
EMail: adrian@olddog.co.uk
Dave Crocker (editor) Dave Crocker
Brandenburg InternetWorking Brandenburg InternetWorking
675 Spruce Drive Email: dcrocker@bbiw.net
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253 Brian E. Carpenter
EMail: dcrocker@bbiw.net The University of Auckland
School of Computer Science
PB 92019
Auckland 1142
New Zealand
Email: brian.e.carpenter@gmail.com
Fernando Gont
SI6 Networks
Evaristo Carriego 2644
1706 Haedo
Provincia de Buenos Aires
Argentina
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Michael Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
URI: https://www.sandelman.ca/mcr/
 End of changes. 60 change blocks. 
136 lines changed or deleted 272 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/