Definition of IETF Working Group Document States
draft-ietf-proto-wgdocument-states-10
Note: This ballot was opened for revision 10 and is now closed.
Adrian Farrel Former IESG member
Yes
Yes
(2010-08-26)
Unknown
Many thanks for taking on this important work. Just a few Comments that you might consider as the I-D goes forward. I feel there is some confusion between "state" and "status" (for example, in the Abstract). This is handled in draft-juskevicius-datatracker-wgdocstate-reqts which says: The phase "WG status of an I-D" is to be interpreted as referring to the WG document state that an I-D is in, as defined in Section 3.3 of [WGDRAFTS]. This phrase does not refer to an I-D's availability status (e.g. "Expired", "Active") as described in Section 3.1 of [WGDRAFTS], or the IESG state used by IETF Area Directors (ADs) to describe the status of an I-D they may be evaluating. I feel it would be helpful to use the same language in both documents. --- Section 3.1.2 An "Active" I-D is a document that is not expired. In fact, an I-D that is an RFC, is not "Active". Ditto other states. --- Some inconsistency of "WG" and "IETF WG" that implies a difference of meaning that does not exst. --- Section 3.2 Not quite sure of the purpose of this section. It seems to me that "In Last Call"and "Waiting for AD Go-ahead" are also key states for interaction with the document authors. "AD is Watching" and "Dead" also seem to be pretty closely related to the authors. --- Figure 1 I know this is showing common transitions only, but I suspect you should show the arrow between "Candidate WG Document" and "Not Adopted be a WG" as double-headed.
Alexey Melnikov Former IESG member
Yes
Yes
(2010-08-14)
Unknown
I am in favor of publishing this document, as it would help to be transparent in WG processes.
I am agreeing with Sean's comments. Additionally, I have some comments of my own:
1) 3.3.3. WG Document
Every "WG Document" should have an "intended maturity level" (e.g.
Informational, Proposed Standard, Experimental) associated with it
as described in Section 3.6. This information is often requested
by IETF participants and it is now required by the IESG for every
I-D that is submitted to the IESG for publication.
I would like to point out that frequently the "intended maturity level" is decided quite late in the WG process. So I want to make sure that this information is not required early on.
2) 3.3.8. In WG Last Call
A document in this state should remain "In WG Last Call" until the
WG Chair moves it to another state. The WG Chair may configure
the Datatracker to send an e-mail after a specified period of time
to remind or 'nudge' the Chair to conclude the WGLC and to
determine the next state for the document.
Personally I prefer the way how IETF LCs work: IETF LC lasts for a specified period of time, after which the document automatically moves to "Waiting for AD Go-Ahead" state. I think the same should happen to documents in WGLCs.
3) 3.3.10. WG Consensus: Waiting for Write-Up
A document in the "WG Consensus: Waiting for Write-Up" state has
essentially completed its development within the working group,
and is nearly ready to be sent to the IESG for publication. The
last thing to be done is the preparation of a protocol write-up by
a document shepherd. The IESG requires that a document shepherd
write-up be completed before publication of the I-D is requested.
This might be an abuse of process, but I don't think write-up is always required when publication is requested. I sent several documents to IETF LC without a write-up, I think this should be allowed.
4) A.1.2. Publication Requested
A formal request has been made to advance/publish the document,
following the procedures in Section 7.5 of RFC 2418 [RFC2418]; the
request could be from a WG Chair, or from an individual. Note: the
Secretariat (iesg-secretary@ietf.org) is copied on these requests to
ensure that the request makes it into the Datatracker.
I don't think sending this to Secretariat is a requirement. All documents I've sponsored I entered into datatracker myself. So I suggest inserting the word "typically" before "copied".
A document
in this state has not (yet) been reviewed by an Area Director nor
has any official action been taken yet, other than to note that its
publication has been requested.
Russ Housley Former IESG member
Yes
Yes
()
Unknown
David Harrington Former IESG member
No Objection
No Objection
()
Unknown
Lars Eggert Former IESG member
(was Discuss)
No Objection
No Objection
(2010-08-23)
Unknown
Section 2., paragraph 1: > The phrase "working group document" is to be interpreted as being > synonymous with "working group I-D". The same is true for the > plural case of each phrase. You probably want to add that a "working group I-D" is an I-D that has gotten consensus for adoption as a work item by a WG (compared to individual ones, that have not or not yet). Section 3.1.3., paragraph 3: > - The filename of an individual I-D that is being considered for > adoption by an IETF WG will typically include the name of its > author (e.g. 'draft-author-wgname-topic-nn'). If the I-D is > adopted by a WG, its filename will change to 'draft-ietf- > wgname-topic-00', and the Datatracker will describe the older > individual I-D as having been "Replaced by" a newer WG I-D. It may be useful to add that "replacing" an ID in this form currently requires an explicit request by the WG chair. Without that request, the IDs will coexist and the individual one will eventually expire. Section 3.2., paragraph 0: > 3.2. IESG Document States The state definitions below are sightly different in wording than in [IESGSTAT] and in Appendix A. This is confusing. Section 3.2.3., paragraph 0: > 3.2.3. IESG Evaluation Suggest to swap the order of the two paragraphs. Section 3.3., paragraph 0: > 3.3. Working Group Document States It would be good to make this a new top-level section, because unlike Sections 3.1 and 3.2, which were replicated for information and not new, this *is* the new stuff. Section 3.3., paragraph 1: > This section describes new states to be added to the Datatracker to > make it possible for IETF WG Chairs and/or their delegates to > indicate the status of I-Ds associated with their working groups. What delegates? Secretaries? Section 3.3., paragraph 2: > WG Chairs will have the option to use some, all or none of these WG > document states to describe the status of some, all or none of the > I-Ds associated with their WGs. Don't we want to recommend that they should use them for all of their documents though? Section 3.3.1., paragraph 6: > Note that a document author may "shop" an I-D to multiple working > groups hoping to get the I-D adopted somewhere. In order to track > this, the Datatracker will be enhanced to enable an I-D to be in > the "Candidate WG Document" state in more than one WG at a time. This sounds like we want to encourage shopping. Shouldn't the focus here be on adding functions that alert us to cases where shopping happens? Section 3.3.3., paragraph 3: > Every "WG Document" should have an "intended maturity level" (e.g. > Informational, Proposed Standard, Experimental) associated with it > as described in Section 3.6. This information is often requested > by IETF participants and it is now required by the IESG for every > I-D that is submitted to the IESG for publication. Not relevant for the purposes of this document. Section 3.3.6., paragraph 0: > 3.3.6. Parked WG Document Not clear if we need this state. Also, what it exactly means is unclear - does "parking" prevent a document from becoming expired? Section 3.3.7., paragraph 0: > 3.3.7. Dead WG Document How is this different from a "WG Document" that is "Expired"? Section 3.4., paragraph 0: > 3.4. Working Group Document State Diagram This section/diagram should really come before the detailed state descriptions earlier in Section 3. Section 3.6., paragraph 0: > 3.6. Intended Maturity Level of WG Documents Sure, but this document is supposed to be on ID states.
Robert Sparks Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Sean Turner Former IESG member
No Objection
No Objection
(2010-08-11)
Unknown
#1) Sec 3.3.7 and Figure 1: If a document is dead to the WG, then can the author take it to another WG and begin the shopping process all over again? #2) Sec 3.5: Should we add "Awaiting Media-Type Review / Resolution of Issues Raised" or more generally "Awaiting Expert Review" for any I-D that affects an IANA registry? #3) Sec 3.6: Is it "Standard" or "Internet Standard"? The title of section 4.1.3 of 2026 is the later. 2026 also uses the phrase when describing STDXXX.
Stewart Bryant Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was Discuss)
No Objection
No Objection
(2010-08-25)
Unknown
(a) In 3.3.1
OLD
b) an I-D that the WG Chair asked an author to write;
NEW
b) an I-D that the WG Chair asked an author to write specifically
for consideration as a WG draft;
(b) I support Lars' discuss on section 3.3.5. Not Adopted by a WG
(c) Figure 1
There should be a line from WG LAST CALL to WG document. A chair may decide that Last Call failed, and
send the document back to the working for extensive discussions. As drawn, any document that goes into Last Call
has to go to the IESG before it can then be returned to the working group.