Definition of IETF Working Group Document States
RFC 6174

Note: This ballot was opened for revision 10 and is now closed.

(Adrian Farrel) Yes

Comment (2010-08-26 for -)
No email
send info
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.

(Russ Housley) Yes

Alexey Melnikov Yes

Comment (2010-08-14 for -)
No email
send info
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.

(Stewart Bryant) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-08-23)
No email
send info
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.

(David Harrington) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2010-08-25)
No email
send info
(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.

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) No Objection

Comment (2010-08-11 for -)
No email
send info
#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.