< draft-ietf-proto-wgdocument-states-09.txt   draft-ietf-proto-wgdocument-states-10.txt >
Proto E. Juskevicius Proto E. Juskevicius
Internet Draft TrekAhead Internet Draft TrekAhead
Intended status: Informational October 5, 2010 Intended status: Informational October 7, 2010
Expires: April 5, 2011 Expires: April 7, 2011
Definition of IETF Working Group Document States Definition of IETF Working Group Document States
draft-ietf-proto-wgdocument-states-09.txt draft-ietf-proto-wgdocument-states-10.txt
Abstract Abstract
The IETF Datatracker tool needs to be enhanced to make it possible The IETF Datatracker tool needs to be enhanced to make it possible
for Working Group (WG) Chairs to provide IETF participants with more for Working Group (WG) Chairs to provide IETF participants with more
information about the status and progression of WG documents than is information about the status and progression of WG documents than is
currently possible. currently possible.
This document defines new states and status annotation tags that This document defines new states and status annotation tags that
need to be added to the Datatracker to enable WG Chairs and their need to be added to the Datatracker to enable WG Chairs and their
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 5, 2011. This Internet-Draft will expire on April 7, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 35 skipping to change at page 2, line 35
4.2. Working Group I-D States.................................10 4.2. Working Group I-D States.................................10
4.2.1. Call For Adoption By WG Issued......................11 4.2.1. Call For Adoption By WG Issued......................11
4.2.2. Adopted by a WG.....................................12 4.2.2. Adopted by a WG.....................................12
4.2.3. Adopted for WG Info Only............................12 4.2.3. Adopted for WG Info Only............................12
4.2.4. WG Document.........................................12 4.2.4. WG Document.........................................12
4.2.5. Parked WG Document..................................13 4.2.5. Parked WG Document..................................13
4.2.6. Dead WG Document....................................13 4.2.6. Dead WG Document....................................13
4.2.7. In WG Last Call.....................................13 4.2.7. In WG Last Call.....................................13
4.2.8. Waiting for WG Chair Go-Ahead.......................14 4.2.8. Waiting for WG Chair Go-Ahead.......................14
4.2.9. WG Consensus: Waiting for Write-Up..................14 4.2.9. WG Consensus: Waiting for Write-Up..................14
4.2.10. Submitted to IESG for Publication..................14 4.2.10. Submitted to IESG for Publication..................15
4.3. Working Group I-D Status Annotation Tags.................15 4.3. Working Group I-D Status Annotation Tags.................15
4.3.1. Awaiting Expert Review/Resolution of Issues Raised..15 4.3.1. Awaiting Expert Review/Resolution of Issues Raised..15
4.3.2. Awaiting External Review/Resolution of Issues Raised15 4.3.2. Awaiting External Review/Resolution of Issues Raised15
4.3.3. Awaiting Merge with Other Document..................16 4.3.3. Awaiting Merge with Other Document..................16
4.3.4. Author or Editor Needed.............................16 4.3.4. Author or Editor Needed.............................16
4.3.5. Waiting for Referenced Document.....................16 4.3.5. Waiting for Referenced Document.....................16
4.3.6. Waiting for Referencing Document....................16 4.3.6. Waiting for Referencing Document....................17
4.3.7. Revised I-D Needed - Issue raised by WGLC...........17 4.3.7. Revised I-D Needed - Issue raised by WGLC...........17
4.3.8. Revised I-D Needed - Issue raised by AD.............17 4.3.8. Revised I-D Needed - Issue raised by AD.............17
4.3.9. Revised I-D Needed - Issue raised by IESG...........17 4.3.9. Revised I-D Needed - Issue raised by IESG...........17
4.3.10. Doc Shepherd Follow-Up Underway....................17 4.3.10. Doc Shepherd Follow-Up Underway....................17
4.3.11. Other - see Comment Log............................18 4.3.11. Other - see Comment Log............................18
5. Intended Maturity Level of WG Documents.......................18 5. Intended Maturity Level of WG Drafts..........................18
6. Security Considerations.......................................18 6. Security Considerations.......................................18
7. IANA Considerations...........................................18 7. IANA Considerations...........................................19
8. References....................................................18 8. References....................................................19
8.1. Normative References.....................................18 8.1. Normative References.....................................19
8.2. Informative References...................................19 8.2. Informative References...................................19
9. Acknowledgments...............................................19 9. Acknowledgments...............................................20
Appendix A: "IESG Document" States...............................21 Appendix A: "IESG Document" States...............................21
A.1. Definition of "IESG Document" States.....................21 A.1. Definition of "IESG Document" States.....................21
A.1.1. Publication Requested...............................21 A.1.1. Publication Requested...............................21
A.1.2. AD Evaluation.......................................21 A.1.2. AD Evaluation.......................................21
A.1.3. Expert Review.......................................21 A.1.3. Expert Review.......................................21
A.1.4. Last Call Requested.................................22 A.1.4. Last Call Requested.................................22
A.1.5. In Last Call........................................22 A.1.5. In Last Call........................................22
A.1.6. Waiting for Writeup.................................22 A.1.6. Waiting for Writeup.................................22
A.1.7. Waiting for AD Go-Ahead.............................22 A.1.7. Waiting for AD Go-Ahead.............................22
A.1.8. IESG Evaluation.....................................22 A.1.8. IESG Evaluation.....................................22
skipping to change at page 6, line 40 skipping to change at page 6, line 40
Chair. Without such a request, an individual I-D will co-exist Chair. Without such a request, an individual I-D will co-exist
with the newer WG I-D that replaces it until the individual I-D with the newer WG I-D that replaces it until the individual I-D
eventually expires. eventually expires.
The Datatracker's ability to track "Replaces" and "Replaced by" The Datatracker's ability to track "Replaces" and "Replaced by"
information may need to be extended in the future to handle more information may need to be extended in the future to handle more
complex cases such as the following: complex cases such as the following:
- Two or more I-Ds are merged into (i.e. "Replaced by") a single - Two or more I-Ds are merged into (i.e. "Replaced by") a single
I-D; in such cases the availability status of the (one) new I-D I-D; in such cases the availability status of the (one) new I-D
should indicate that that the draft "Replaces" two or more should indicate that the draft "Replaces" two or more older and
older and previously separate I-Ds; and previously separate I-Ds; and
- One I-D is split or divided into two or more new I-Ds; in this - One I-D is split or divided into two or more new I-Ds; in this
case the availability status should indicate that one (older) case the availability status should indicate that one (older)
I-D was "Replaced by" two or more newer I-Ds. I-D was "Replaced by" two or more newer I-Ds.
3.2. IESG Document States 3.2. IESG Document States
In addition to tracking the availability status of every I-D, the In addition to tracking the availability status of every I-D, the
Datatracker also maintains detailed information about the status and Datatracker also maintains detailed information about the status and
progression of I-Ds that have been sent to the IESG for evaluation progression of I-Ds that have been sent to the IESG for evaluation
skipping to change at page 7, line 35 skipping to change at page 7, line 35
Director has reviewed the I-D or that any official action has been Director has reviewed the I-D or that any official action has been
taken on the I-D other than to note that its publication has been taken on the I-D other than to note that its publication has been
requested. requested.
Many WG drafts enter the IESG state machine for the first time via Many WG drafts enter the IESG state machine for the first time via
the "Publication Requested" state. When an I-D advances through the "Publication Requested" state. When an I-D advances through
the IESG process, its IESG state will change to reflect its the IESG process, its IESG state will change to reflect its
progress. This said, the WG status of the I-D should not change progress. This said, the WG status of the I-D should not change
unless an AD or the IESG sends the I-D back to the WG for further unless an AD or the IESG sends the I-D back to the WG for further
development. The WG state of an I-D that is being progressed by development. The WG state of an I-D that is being progressed by
the IESG is "Sent to IESG for Publication", as defined in Section the IESG is "Submitted to IESG for Publication", as defined in
4.2.10. Section 4.2.10.
3.2.2. AD Evaluation 3.2.2. AD Evaluation
The "AD Evaluation" state describes an I-D that the responsible The "AD Evaluation" state describes an I-D that the responsible
Area Director has begun to review. The purpose of the AD's review Area Director has begun to review. The purpose of the AD's review
is to verify that the I-D is ready for advancement before an IETF is to verify that the I-D is ready for advancement before an IETF
Last Call is started or before the document is progressed to the Last Call is started or before the document is progressed to the
IESG as a whole. IESG as a whole.
After evaluating an I-D, the responsible AD may decide that the After evaluating an I-D, the responsible AD may decide that the
document needs to be revised before it can be progressed further. document needs to be revised before it can be progressed further.
The AD may send a working group I-D back to the WG that created it The AD may send a working group I-D back to the WG that created it
for revision. for revision.
When an AD sends an I-D back to a WG for revision, the Datatracker When an AD sends an I-D back to a WG for revision, the Datatracker
will report the IESG state and substate status of the document as will report the IESG state and substate status of the document as
"AD Evaluation: Revised I-D Needed". If the required revisions "AD Evaluation: Revised I-D Needed". If the required revisions
are extensive, a WG Chair may decide to change the WG state of the are extensive, a WG Chair may decide to change the WG state of the
I-D from "Sent to IESG for Publication" to another WG state (e.g. I-D from "Submitted to IESG for Publication" to another WG state
"Waiting for WG Chair Go-Ahead" or "WG Document") for as long as (e.g. "Waiting for WG Chair Go-Ahead" or "WG Document") for as
it takes the revised I-D to be developed. The IESG status of the long as it takes the revised I-D to be developed. The IESG status
I-D will continue to be "AD Evaluation: Revised I-D Needed" until of the I-D will continue to be "AD Evaluation: Revised I-D Needed"
the revised I-D becomes available. until the revised I-D becomes available.
3.2.3. IESG Evaluation 3.2.3. IESG Evaluation
The "IESG Evaluation" state describes an I-D that is being The "IESG Evaluation" state describes an I-D that is being
formally evaluated by the entire IESG. Every AD is able to air formally evaluated by the entire IESG. Every AD is able to air
any content or process issues he/she may have with the document. any content or process issues he/she may have with the document.
Issues that are blocking approval of the document are called Issues that are blocking approval of the document are called
"DISCUSS" comments. A "DISCUSS" with serious issues may cause a "DISCUSS" comments. A "DISCUSS" with serious issues may cause a
WG I-D to be returned to the WG for revision. WG I-D to be returned to the WG for revision.
If the IESG sends an I-D back to a WG for more development, the If the IESG sends an I-D back to a WG for more development, the
Datatracker will report the IESG state and substate of the I-D as Datatracker will report the IESG state and substate of the I-D as
"IESG Evaluation: Revised I-D Needed" until a revised version of "IESG Evaluation: Revised I-D Needed" until a revised version of
the I-D becomes available. During the time that the I-D is being the I-D becomes available. During the time that the I-D is being
revised, the WG Chair may decide to transition the I-D from the revised, the WG Chair may decide to transition the I-D from the
"Sent to IESG for Publication" state into one of the earlier WG "Submitted to IESG for Publication" state into one of the earlier
states (e.g. "Waiting for WG Chair Go-Ahead" or "WG Document"). WG states (e.g. "Waiting for WG Chair Go-Ahead" or "WG Document").
4. New States and Status Annotation Tags for WG I-Ds 4. New States and Status Annotation Tags for WG I-Ds
The status tracking states described in Section 3 are currently The status tracking states described in Section 3 are currently
implemented in the Datatracker, however their scope is not broad implemented in the Datatracker, however their scope is not broad
enough to provide good visibility into the WG status of any I-D. enough to provide good visibility into the WG status of any I-D.
This section describes new I-D states and I-D status annotation tags This section describes new I-D states and I-D status annotation tags
that need to be added to the Datatracker to make it possible for WG that need to be added to the Datatracker to make it possible for WG
Chairs and/or their delegates (e.g. WG Secretaries) to indicate the Chairs and/or their delegates (e.g. WG Secretaries) to indicate the
skipping to change at page 10, line 20 skipping to change at page 10, line 18
Note that Figure 1 does not show every possible state transition. Note that Figure 1 does not show every possible state transition.
WG Chairs may move an I-D from any WG state to any other WG state as WG Chairs may move an I-D from any WG state to any other WG state as
appropriate to describe the WG status of the document. The lack of appropriate to describe the WG status of the document. The lack of
an explicit path between two states does not mean that such a state an explicit path between two states does not mean that such a state
transition is precluded. transition is precluded.
The first WG I-D state is "Call For Adoption By WG Issued" and its The first WG I-D state is "Call For Adoption By WG Issued" and its
meaning and usage is defined in Section 4.2.1. meaning and usage is defined in Section 4.2.1.
One of several possible last states for a WG I-D is "Sent to IESG One of several possible last states for a WG I-D is "Submitted to
for Publication". This state is defined in Section 4.2.10. IESG for Publication". This state is defined in Section 4.2.10.
The Datatracker will be enhanced to automatically generate the The Datatracker will be enhanced to automatically generate the
following two state transitions for all WG drafts: following two state transitions for all WG drafts:
- A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00' - A version-00 I-D that conforms to the 'draft-ietf-wgname-topic-00'
file naming convention will be moved into the "WG Document" state file naming convention will be moved into the "WG Document" state
automatically by the Datatracker when the WG Chair approves the automatically by the Datatracker when the WG Chair approves the
posting of I-D; and posting of I-D; and
- A WG draft that is moved into the IESG state called "Publication - A WG draft that is moved into the IESG state called "Publication
skipping to change at page 11, line 9 skipping to change at page 11, line 5
4.2. Working Group I-D States 4.2. Working Group I-D States
The WG I-D states defined in this section are a superset of the I-D The WG I-D states defined in this section are a superset of the I-D
states currently used across all IETF WGs. states currently used across all IETF WGs.
All of the states described herein need to be added to the front-end All of the states described herein need to be added to the front-end
of IESG state machine [IESGIDSM] that has already been implemented of IESG state machine [IESGIDSM] that has already been implemented
in the IETF Datatracker. in the IETF Datatracker.
Note that IETF WG Chairs and their delegates will be given the WG Chairs and their delegates will be given the flexibility to use
flexibility to use all or just some of the WG I-D states they need whichever of the WG I-D states they feel to be appropriate to
to indicate the status and progression of the I-Ds associated with describe the WG status of the I-Ds associated with their WG.
their WG.
It is not suggested or implied that WG Chairs must use all of the I- It is not suggested or implied that Chairs must use all of the I-D
D states defined herein to describe the status and progression of states defined herein to describe the status and progression of all
all I-Ds associated with their WGs. I-Ds associated with their WGs; Chairs may use all of the WG I-D
states, or just some of the states.
Note that an I-D that is not associated with the IETF stream will be Note that an I-D that is not associated with a WG will be in a
in a "NULL" state with respect to the WG state machine in Figure 1. 'Null' state with respect to the WG state machine in Figure 1.
4.2.1. Call For Adoption By WG Issued 4.2.1. Call For Adoption By WG Issued
The "Call for Adoption by WG Issued" state should be used to The "Call for Adoption by WG Issued" state should be used to
indicate when an I-D is being considered for adoption by an IETF indicate when an I-D is being considered for adoption by an IETF
WG. An I-D that is in this state is actively being considered for WG. An I-D that is in this state is actively being considered for
adoption, and has not yet achieved consensus, preference or adoption, and has not yet achieved consensus, preference or
selection in the WG. selection in the WG.
This state may be used to describe an I-D that someone has asked a This state may be used to describe an I-D that someone has asked a
skipping to change at page 11, line 42 skipping to change at page 11, line 38
Chair asked an author to write specifically for consideration as a Chair asked an author to write specifically for consideration as a
candidate WG item [WGDTSPEC], and/or an I-D that is listed as a candidate WG item [WGDTSPEC], and/or an I-D that is listed as a
'candidate draft' in the WG's charter. 'candidate draft' in the WG's charter.
Under normal conditions, it should not be possible for an I-D to Under normal conditions, it should not be possible for an I-D to
be in the "Call For Adoption by WG Issued" state in more than one be in the "Call For Adoption by WG Issued" state in more than one
working group at the same time. This said, it is not uncommon for working group at the same time. This said, it is not uncommon for
authors to "shop" their I-Ds to more than one WG at a time, with authors to "shop" their I-Ds to more than one WG at a time, with
the hope of getting their documents adopted somewhere. the hope of getting their documents adopted somewhere.
After this state is added in the Datatracker, an I-D that is in After this state is implemented in the Datatracker, an I-D that is
the "Call for Adoption by WG Issued" state will not be able to be in the "Call for Adoption by WG Issued" state will not be able to
"shopped" to any other WG without the consent of the WG Chairs and be "shopped" to any other WG without the consent of the WG Chairs
the responsible ADs impacted by the shopping. and the responsible ADs impacted by the shopping.
Note that Figure 1 includes an arc leading out from this state to Note that Figure 1 includes an arc leading from this state to
outside the WG state machine. This illustrates that some I-Ds outside of the WG state machine. This illustrates that some I-Ds
that are considered do not get adopted as WG drafts. An I-D that that are considered do not get adopted as WG drafts. An I-D that
is not adopted as a WG draft will transition out the IETF stream is not adopted as a WG draft will transition out of the WG state
into a non-stream state. machine and revert back to having no stream-specific state;
however, the status change history log of the I-D will record that
the I-D was previously in the "Call for Adoption by WG Issued"
state.
4.2.2. Adopted by a WG 4.2.2. Adopted by a WG
The "Adopted by a WG" state describes an individual submission I-D The "Adopted by a WG" state describes an individual submission I-D
that an IETF WG has agreed to adopt as one of its WG drafts. that an IETF WG has agreed to adopt as one of its WG drafts.
WG Chairs who use this state will be able to clearly indicate when WG Chairs who use this state will be able to clearly indicate when
their WG adopted every I-D, and they will help to capture correct their WGs adopt individual I-Ds. This will facilitate the
"Replaced by" information in the Datatracker's database of status Datatracker's ability to correctly capture "Replaces" information
changes for every IETF stream I-D. for WG drafts and correct "Replaced by" information for individual
I-Ds that have been replaced by WG drafts.
This state is needed because the Datatracker uses the filename of This state is needed because the Datatracker uses the filename of
an I-D as a key to search its database for status information an I-D as a key to search its database for status information
about the I-D, and because the filename of a WG I-D is supposed to about the I-D, and because the filename of a WG I-D is supposed to
be different from the filename of an individual submission I-D. be different from the filename of an individual submission I-D.
The filename of an individual submission I-D will typically be The filename of an individual submission I-D will typically be
formatted as 'draft-author-wgname-topic-nn'. formatted as 'draft-author-wgname-topic-nn'.
The filename of a WG document is supposed to be formatted as The filename of a WG document is supposed to be formatted as
'draft-ietf-wgname-topic-nn'. 'draft-ietf-wgname-topic-nn'.
An individual I-D that is adopted by a WG may take weeks or months An individual I-D that is adopted by a WG may take weeks or months
to be resubmitted by the author as a new (version-00) WG draft. to be resubmitted by the author as a new (version-00) WG draft.
If the "Adopted by a WG" state is not used, the Datatracker has no If the "Adopted by a WG" state is not used, the Datatracker has no
way to determine that an I-D has been adopted until a new version- way to determine that an I-D has been adopted until a new version
00 of the I-D is submitted by the author to the WG and until the of the I-D is submitted to the WG by the author and until the I-D
I-D is approved for posting by a WG Chair. is approved for posting by a WG Chair.
4.2.3. Adopted for WG Info Only 4.2.3. Adopted for WG Info Only
The "Adopted for WG Info Only" state describes a document that The "Adopted for WG Info Only" state describes a document that
contains useful information for the WG that adopted it, however contains useful information for the WG that adopted it, however
the document is not intended to be published as an RFC. The WG the document is not intended to be published as an RFC. The WG
will not actively develop the contents of the I-D or progress it will not actively develop the contents of the I-D or progress it
for publication as an RFC. The only purpose of the I-D is to for publication as an RFC. The only purpose of the I-D is to
provide information for internal use by the WG. provide information for internal use by the WG.
skipping to change at page 13, line 7 skipping to change at page 13, line 11
A WG Chair may transition an I-D into the "WG Document" state at A WG Chair may transition an I-D into the "WG Document" state at
any time as long as the I-D is not being considered or developed any time as long as the I-D is not being considered or developed
in any other WG. in any other WG.
Alternatively, WG Chairs may rely upon new functionality to be Alternatively, WG Chairs may rely upon new functionality to be
added to the Datatracker to automatically move version-00 drafts added to the Datatracker to automatically move version-00 drafts
into the "WG Document" state as described in Section 4.1. into the "WG Document" state as described in Section 4.1.
Under normal conditions, it should not be possible for an I-D to Under normal conditions, it should not be possible for an I-D to
be in the "WG Document" state in more than one WG at a time. This be in the "WG Document" state in more than one WG at a time. This
said, I-Ds may be transferred from one WG to another. said, I-Ds may be transferred from one WG to another with the
consent of the WG Chairs and the responsible ADs.
4.2.5. Parked WG Document 4.2.5. Parked WG Document
A "Parked WG Document" is an I-D that has lost its author or A "Parked WG Document" is an I-D that has lost its author or
editor, is waiting for another document to be written or for a editor, is waiting for another document to be written or for a
review to be completed, or cannot be progressed by the working review to be completed, or cannot be progressed by the working
group for some other reason. group for some other reason.
Some of the annotation tags described in Section 4.3 may be used Some of the annotation tags described in Section 4.3 may be used
in conjunction with this state to indicate why an I-D has been in conjunction with this state to indicate why an I-D has been
parked, and/or what may need to happen for the I-D to be un- parked, and/or what may need to happen for the I-D to be un-
parked. parked.
Parking a WG draft will not prevent it from expiring, however this Parking a WG draft will not prevent it from expiring, however this
state can be used to indicate why the I-D has stopped progressing state can be used to indicate why the I-D has stopped progressing
in the WG. in the WG.
Note that a "Parked WG Document" may be transferred from one WG to A "Parked WG Document" that is not expired may be transferred from
another with the consent of the WG Chairs and the responsible ADs one WG to another with the consent of the WG Chairs and the
responsible ADs.
4.2.6. Dead WG Document 4.2.6. Dead WG Document
A "Dead WG Document" is an I-D that has been abandoned. Note that A "Dead WG Document" is an I-D that has been abandoned. Note that
'Dead' is not always a final state for a WG I-D. If consensus is 'Dead' is not always a final state for a WG I-D. If consensus is
subsequently achieved, a "Dead WG Document" may be resurrected. A subsequently achieved, a "Dead WG Document" may be resurrected. A
"Dead WG Document" that is not resurrected will eventually expire. "Dead WG Document" that is not resurrected will eventually expire.
Note that an I-D that is declared to be "Dead" in one WG may be Note that an I-D that is declared to be "Dead" in one WG and that
transferred to a non-dead state in another WG with the consent of is not expired may be transferred to a non-dead state in another
the WG Chairs and the responsible ADs. WG with the consent of the WG Chairs and the responsible ADs.
4.2.7. In WG Last Call 4.2.7. In WG Last Call
A document "In WG Last Call" is an I-D for which a WG Last Call A document "In WG Last Call" is an I-D for which a WG Last Call
(WGLC) has been issued, and is in progress. (WGLC) has been issued, and is in progress.
Note that conducting a WGLC is an optional part of the IETF WG Note that conducting a WGLC is an optional part of the IETF WG
process, per section 7.4 of RFC 2418 [RFC2418]. process, per section 7.4 of RFC 2418 [RFC2418].
If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last If a WG Chair decides to conduct a WGLC on an I-D, the "In WG Last
skipping to change at page 17, line 8 skipping to change at page 17, line 17
This tag means that completion of the I-D is on-hold because one This tag means that completion of the I-D is on-hold because one
or more other documents are dependent on it, and the WG Chair or more other documents are dependent on it, and the WG Chair
wants to submit all of the documents to the IESG (for publication) wants to submit all of the documents to the IESG (for publication)
simultaneously. This tag is the inverse of 4.3.7. simultaneously. This tag is the inverse of 4.3.7.
This tag should be removed after the dependency is cleared. This tag should be removed after the dependency is cleared.
4.3.7. Revised I-D Needed - Issue raised by WGLC 4.3.7. Revised I-D Needed - Issue raised by WGLC
This annotation may be used to flag an I-D that needs to be This annotation may be used to flag an I-D that needs to be
revised to address issues raised during a working group last revised to address issues raised during a working group last call.
call). This annotation may also be used to indicate when the I-D This annotation may also be used to indicate when the I-D is in
is in the process of being revised. the process of being revised.
This tag should be removed after a revised version of the I-D is This tag should be removed after a revised version of the I-D is
submitted to the WG. submitted to the WG.
4.3.8. Revised I-D Needed - Issue raised by AD 4.3.8. Revised I-D Needed - Issue raised by AD
This annotation means the responsible AD raised one or more issues This annotation means the responsible AD raised one or more issues
with the I-D during "AD Evaluation" and that the AD has sent the with the I-D during "AD Evaluation" and that the AD has sent the
document back to the working group for revision. This annotation document back to the working group for revision. This annotation
may also be used to indicate when the I-D is in the process of may also be used to indicate when the I-D is in the process of
skipping to change at page 18, line 12 skipping to change at page 18, line 22
Waiting for Write-up" state indicates the write-up has not yet Waiting for Write-up" state indicates the write-up has not yet
been started, or has been put on-hold for some reason. been started, or has been put on-hold for some reason.
4.3.11. Other - see Comment Log 4.3.11. Other - see Comment Log
This annotation tag is a catch-all to indicate that someone (e.g. This annotation tag is a catch-all to indicate that someone (e.g.
an author or editor of the document, the WG Chair, the Document an author or editor of the document, the WG Chair, the Document
Shepherd) has entered one or more comments about the current Shepherd) has entered one or more comments about the current
status of the I-D into the IETF Datatracker. status of the I-D into the IETF Datatracker.
5. Intended Maturity Level of WG Documents 5. Intended Maturity Level of WG Drafts
The IESG requires a WG I-D to have an "intended maturity level" The IESG requires a WG I-D to have an "intended maturity level"
associated with it (e.g. Informational, Proposed Standard, associated with it (e.g. Informational, Proposed Standard,
Experimental) before the I-D is submitted to the IESG for evaluation Experimental) before the I-D is submitted to the IESG for evaluation
and publication. This information is also often requested by IETF and publication. This information is also often requested by IETF
participants. participants.
I-D maturity levels were first defined in sections 4 and 5 of RFC I-D maturity levels were first defined in sections 4 and 5 of RFC
2026 [RFC2026]. The names of the maturity levels in use today are: 2026 [RFC2026]. The names of the maturity levels in use today are:
skipping to change at page 19, line 43 skipping to change at page 20, line 10
[PROTO] Levkowetz, H., and Mankin, A., "Requirements on I-D [PROTO] Levkowetz, H., and Mankin, A., "Requirements on I-D
Tracker Extensions for Working Group Chairs", Tracker Extensions for Working Group Chairs",
draft-ietf-proto-wgchair-tracker-ext-03.txt, draft-ietf-proto-wgchair-tracker-ext-03.txt,
February 8, 2007. February 8, 2007.
9. Acknowledgments 9. Acknowledgments
The author would like to thank Henrik Levkowetz and Allison Mankin The author would like to thank Henrik Levkowetz and Allison Mankin
for developing the original I-D [PROTO] that served as the starting for developing the original I-D [PROTO] that served as the starting
point for this document, and Alfred Hoenes for his many comments and point for this document, and Alfred Hoenes for his many comments and
suggestions and for identifying the need for the "Adopted by a WG" suggestions and for articulating the need for the "Adopted by a WG"
state. state.
The author would also like to thank Henrik Levkowetz, Russ Housley, The author would also like to thank Henrik Levkowetz, Russ Housley,
Paul Hoffman, John Klensin, Pasi Eronen, Robert Sparks, Spencer Paul Hoffman, John Klensin, Pasi Eronen, Robert Sparks, Spencer
Dawkins, Mary Barnes, Glenn Parsons, Marc Blanchet, Andy Malis and Dawkins, Mary Barnes, Glenn Parsons, Marc Blanchet, Andy Malis and
Joel Halpern for their comments and feedback along the way. Joel Halpern for their comments and feedback along the way.
Finally, the author also wishes to thank the IETF WG Chairs, ADs and Finally, the author also wishes to thank the IETF WG Chairs, ADs and
other people who contributed their insights and suggestions in real- other people who contributed their insights and suggestions in real-
time during the wgdtspec BOF at IETF 77, and Lars Eggert, Tim Polk, time during the wgdtspec BOF at IETF 77, and Lars Eggert, Tim Polk,
skipping to change at page 21, line 20 skipping to change at page 21, line 20
A.2 are copied from [IESGSTAT]. A.2 are copied from [IESGSTAT].
It must be noted that I-Ds sent to the IESG for publication (termed It must be noted that I-Ds sent to the IESG for publication (termed
"IESG Documents" in this Appendix) do not stay with the IESG until "IESG Documents" in this Appendix) do not stay with the IESG until
the day they are published as RFCs. After evaluation, the IESG may the day they are published as RFCs. After evaluation, the IESG may
declare that some I-Ds deserve a "Do Not Publish" label. Other I-Ds declare that some I-Ds deserve a "Do Not Publish" label. Other I-Ds
may become "Dead". Some I-Ds may get sent back to their originators may become "Dead". Some I-Ds may get sent back to their originators
(WGs or otherwise), and the rest may go into the RFC Editor queue. (WGs or otherwise), and the rest may go into the RFC Editor queue.
Note that documents which are not tracked by the IESG (e.g. I-Ds for Note that documents which are not tracked by the IESG (e.g. I-Ds for
which no request has been made of the IESG) are in a NULL state with which no request has been made of the IESG) are in a null state with
respect to the IESG state machine. The IESG state of an I-D that respect to the IESG state machine. The IESG state of an I-D that
has no value assigned to the IESG state variable in the has no value assigned to the IESG state variable in the
Datatracker's database is 'NULL'. Datatracker's database is 'NULL'.
A.1. Definition of "IESG Document" States A.1. Definition of "IESG Document" States
A.1.1. Publication Requested A.1.1. Publication Requested
A formal request has been made to advance/publish the document, A formal request has been made to advance/publish the document,
following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the
 End of changes. 28 change blocks. 
59 lines changed or deleted 65 lines changed or added

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