Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors
RFC 6175

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

(Adrian Farrel) (was Discuss) Yes

Comment (2010-10-30 for -)
No email
send info
Thank you for an exceptional job addressing all my Discuss points.

(Russ Housley) Yes

(Stewart Bryant) No Objection

(Ralph Droms) No Objection

Comment (2010-08-25 for -)
No email
send info
I have a couple of minor comments.

Is "WG I-D" a synonym for "I-D associated with an IETF WG"?

I don't understand this requirement:
   WG document status tracking SHOULD be implemented per-document, not
   per-WG. (R-012)
What would "per-WG WG document status tracking be?

(Lars Eggert) (was Discuss) No Objection

Comment (2010-08-23)
No email
send info
Section 3., paragraph 1:
>    The Datatracker SHALL be enhanced to provide IETF WG Chairs and the
>    people they designate to act as their delegates with the flexibility
>    to input and update the WG status of some, all, or none of the I-Ds
>    associated with their WGs using the WG document states and status
>    annotation tags defined in [WGDRAFTS]. (R-001)

  Can we s/the people they designate to act as their
  delegates/secretaries/? AFAIK there are no other delegates allowed by
  the process. (Also elsewhere in the doc.)

Section 3., paragraph 2:
>    The following two examples clarify Requirement R-001:
>   - the Chairs (and their delegates) of a newly chartered IETF WG may
>     choose to input the WG status of all of the I-Ds associated with
>     their WG to provide maximum transparency to the IETF community and
>     to manage the progression of the I-Ds;
>   - the Chairs (and delegates) of a mature WG (e.g. a WG that is
>     nearing the completion of its charter milestones) may decide not to
>     manually input the status of their WG I-Ds into the Datatracker.

  These examples don't clarify much. What they do is instead to make it
  sound OK for chairs of old WGs to not bother with these new functions,
  which I don't think is the message we want to send.

Section 3., paragraph 8:
  The look and feel for R-005 and R-006 is somewhat important, but it is
  also maybe more important that the style sheets and javascript UI code
  be shared, so that when the IESG tracker is updated, the WG tracker
  benefits and vice versa.

Section 7, paragraph 1:
>    The Datatracker SHOULD date and timestamp every update to the WG
>    status of an IETF Stream I-D and use that information when it needs
>    to display the WG status change history of that I-D. (R-007)

  I think this needs to be a MUST, for transparency.

Section 7, paragraph 2:
>      The WG
>    status change history for each I-D SHOULD also identify the person
>    or entity that updated the WG status of the I-D (e.g. one of the
>    WG's Chairs, a delegate, an AD, the System, the IETF Secretariat)
>    and describe the change in the WG status of the I-D (e.g. "WG State
>    changed from 'a' to 'b'", "Document Annotation Tag 'x' Set (or
>    Reset)", "Document Availability status changed from 'j' to 'k'").
>    (R-008)

  I think this needs to be a MUST, for transparency.

Section 7, paragraph 4:
>    WG document status tracking SHOULD be implemented using a new WG
>    state machine that is separate from Datatracker's existing IESG
>    document status tracking state machine. (R-010)

  This is an implementation detail we don't care about, as long as the
  externally visible behavior is such.

Section 7, paragraph 6:
>    WG document status tracking SHOULD be implemented per-document, not
>    per-WG. (R-012)

  This is clearly a MUST. Otherwise, we don't *have* document tracking.

Section 4.4., paragraph 2:
>    The requirements in this Section describe the access privileges to
>    be granted to a WG Document Shepherd who is not a WG Chair or a
>    delegate of a WG Chair with the privileges described in Section 4.3.

  There are no such shepherds. See above.

Section 6., paragraph 0:
> 6. Special requirements for some WG I-D states and conditions

  Many of the issues I raised for draft-ietf-proto-wgdocument-states-08
  apply here, too. If they result in any changes to that document, this
  document will need to be carefully brought in line.

Section 6.2., paragraph 3:
>    adopted by another IETG WG. (R-073)  If a WG Chair or delegate moves

  Nit: s/IETG/IETF/

Section 7., paragraph 3:
>    associated with an IETG WG:

  Nit: s/IETG/IETF/

(Alexey Melnikov) (was Discuss) No Objection

(Tim Polk) (was Discuss) No Objection

Comment (2010-08-26)
No email
send info
[WGDRAFTS] does not define withdrawn.

I share Lars' concerns regarding 4.2, paragraph 7, 9 , and 11.  I am not sure I agree with his analysis, but
this text deserves some discussion!

(Robert Sparks) (was Discuss) No Objection

Comment (2010-08-24)
No email
send info
Early in the conventions section: There are instances of individual drafts being adopted 
by working groups that don't get renamed -ietf-.

R-020 - is it worth calling out in the requirement that one of the delegates may also have
other roles (like being the chair of another WG, or being an AD of another area). It might
also help the implementer of these requirements if you made a forward reference to R-033 
here. (btw - R033 is showing some edititis - it's referring to itself as if it were somewhere

I have concerns with the process being proposed around the pre-WG adoption states and the
mechanics associated with them. I'm capturing a couple of them here as a comment, but in
general I think the proposal needs additional discussion before codifying it into a tool.
   - Many working groups consider all documents that fall within their scope candidates 
     for adoption. Is the goal here to focus attention on documents a chair plans to
     issue a call for adoption on? If so, a chair can do that with email, and I don't
     see the benefit tracking this state brings. I _can_ see this introducing pressure
     on chairs to "bless" documents ahead of time, and becoming a breeding ground for
     process confusion (similar to the must-bar-bof-twice misconception that has been
     recently raised)
   - What is the point of the "Not adopted by a WG state"? If it was to help push back
     against proposal replay attacks? If so, I think just having a way to capture that
     a group was asked to adopt a document and declined would be just as powerful and
     would be far less complex to implement. (The tool could present the chair with
     a button that put a chunk of well-known, searchable, text into a comment for example).

(Sean Turner) (was Discuss) No Objection

Comment (2010-08-11)
No email
send info
#1) R -019 r/(e.g., IANA status, RFC-Editor status, IESG status;/(e.g., IANA status, RFC-Editor status, IESG status);

#2) R-020/025 Should the should be SHOULD: The identifier for each delegate should

#3) R-022 r/for the different/the different

#4) R-033: each IETF AD SHALL have the privileges specified
   in Requirement R-033 for every WG in his or her Area (R-033)

I'm having trouble parsing this one.  Is it meant to be recursive?

#5) Page 12: The "a" is extra perhaps: for adoption in a their IETF WG without

#6) R-073/094: Should the shall be SHALL?

#7) Sec 6.3 last para: r/draft-IETF-/draft-ietf-

#8) Sec 6.5: Should we add a default value for the length of the WG LC?