Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors
draft-juskevicius-datatracker-wgdocstate-reqts-08

[Ballot discuss]
1) Where this document is capturing requirements to facilitate WG tracking using
  processes that WG chairs are already exercising I think it's on track. I believe
  it and it's companion state document are going going further than that in
  with the definition of the Candidate WG document and Not Adopted by a WG states
  and the behavior required not just of the tool but of the chairs by this document.
  Attempting to define a new process and codify it into a tool at the same time seems
  risky. I would prefer to see the requirements around tracking a document before WG
  adoption split into a separate effort, both in determining requirements and implementing
  the tool. (It would be even better if there was experience with the suggested process -
  an interested chair and cooperative AD could do this now with the comments field in the
  existing tracker.) Our initial effort should be scoped to helping WG chairs and other
  stakeholders track what they already do.


2) R-003 can be read to mean that every IETF Stream document SHALL be tracked using this tool,
contradicting R-001. I suggest that the first part of the requirement be rephrased thus:

  When the WG status of an IETF Stream I-D is tracked, the Datatracker SHALL use the
  WG document states ...

3) Why is R-012 SHOULD and not MUST?


4) There are a couple of places (For instance R-021) where a design decision is being
made (probably the right decision, but I'm not sure this is the tool to make that
decision with)- there are people now with exising datatracker/tools logins whose login name
does not look like an email address. This decision will force delegation to them to be through
an email address _associated_ with the login. MANY people with datatracker logins have more than
one email address. Could we remove this bit of design? If not, can we acknowledge that
people may have more than one email identifier?

5) The delegation requirements in 4.2 seem to be written from the viewpoint of a chair
delegating authority for all of the documents in the working group. Why are they not
written so that delegation is done on a per-document basis (in the spirit of R-012)?

6) R-054 (also touched in Alexey's comments) imply that someone must logout to change
roles. If that was the intent, it should be made explicit.  I hope that was NOT the
intent and I think we need an additional requirement that a login that can serve
multiple roles be allowed to change roles on demand without logging out.

[Ballot comment]
5) 6.1. Candidate WG Document

  The Datatracker SHALL allow an IETF WG Chair or delegate to identify
  an I-D as a "Candidate WG Document" in her or his WG if the I-D has
  not yet been adopted by any IETF WG, is not expired and has not been
  withdrawn or replaced by another I-D. (R-054)  The Datatracker
  should not allow a document that is expired, withdrawn, replaced or
  already adopted by an IETF WG to be moved into the "Candidate WG
  Document" state.

I am slightly concerned about not allowing a replaced document to be used as a "Candidate WG Document". Sometimes documents get forked, or a document which was once replaced by another one might be abandonned by the WG. It should be possible to use such documents elsewhere.

[Ballot discuss]
Due to extensive changes to the document I was unable to fully confirm that some of my issues were addressed. If I missed some changes, please kindly point this out.

I am largely happy with this document. However there are a couple of issues I would like to discuss before recommending approval of this document:

5) 6.8. Revised I-D Needed (annotation tag)

  The Datatracker should be programmed to send an e-mail to the WG's
  Chairs and delegates after the number of weeks specified in R-087 to
  remind or 'nudge' the WG Chairs and delegates to follow-up on the
  revisions to the document, unless a revised document is submitted
  before the time elapses. (R-098)

Does posting of a new revision automatically clear the "Revised I-D Needed" annotation tag?

[Ballot comment]
1) 4.2. For IETF Working Group Chairs

  When an IETF WG Chair needs to input or update the WG status of an
  I-D in one of his or her WGs, the WG Chair SHALL be required to log-
  on to the Datatracker using a personal user-id and password (e.g.,
  an IETF tools password) in order to gain 'write' access. (R-015)

[...]

  - SHALL be able to designate one or more people to act as delegates
    to input and update the WG status of the I-Ds associated with their
    WGs; (R-020)  The identifier for each delegate should be the
    person's e-mail address; (R-021)

I think it would be a good idea to clearify the relationship between a user-id and an email address. Currently each user-id is an email address, but the text above seem to be implying that some kind of mapping might be possible.
This also affects other sections (e.g. 4.3).

2) 4.3. For Delegates of IETF WG Chairs

  The Datatracker SHOULD alert the WG Chairs, the IETF Secretariat,
  and the newly designated delegate via e-mail if a person who is
  newly designated to be a delegate of a WG Chair does not have a
  personal user-id and password to log-on to the Datatracker. (R-029)

What about showing this information to the WG chair when he/she adds a delegate in the datatracker's web interface?

3) 5.1. WG Document States

  The Datatracker SHALL allow WG Chairs and their delegates to select
  the next state for an I-D from one of the 'most likely' next states
  described in Requirement R-035, or from any of the other WG document
  states (per Requirement R-017) if needed. (R-039)

Why not just say that any state transitions are allowed.
If the intent of the wording is to show that there should be an easy way to select one of the 'most likely' states, then that should be stated explicitly.

5) 6.1. Candidate WG Document

  The Datatracker SHALL allow an IETF WG Chair or delegate to identify
  an I-D as a "Candidate WG Document" in her or his WG if the I-D has
  not yet been adopted by any IETF WG, is not expired and has not been
  withdrawn or replaced by another I-D. (R-054)  The Datatracker
  should not allow a document that is expired, withdrawn, replaced or
  already adopted by an IETF WG to be moved into the "Candidate WG
  Document" state.

I am slightly concerned about not allowing a replaced document to be used as a "Candidate WG Document". Sometimes documents get forked, or a document which was once replaced by another one might be abandonned by the WG. It should be possible to use such documents elsewhere.

6) 6.1. Candidate WG Document

  When Requirements R-056 and R-057 are met, the Datatracker SHALL
  display the WG status of the I-D as follows: "Candidate WG Document
  in (name of IETF WG)". (R-058)

I hope you didn't mean that the status should be presented exactly in the form shown above.

8) 6.4. WG Document

  The Datatracker SHALL allow WG Chairs and their delegates to move an
  I-D into the "WG Document" state from a different document state as
  defined in Section 3.3 of [WGDRAFTS] if the I-D has not expired,
  been withdrawn or replaced by another I-D. (R-079)

Just to double check: this would allow to adopt a draft as a WG document, without renaming it?
I think that would be useful.

[Ballot discuss]
Due to extensive changes to the document I was unable to fully confirm that some of my issues were addressed. If I missed some changes, please kindly point this out.

I am largely happy with this document. However there are a couple of issues I would like to discuss before recommending approval of this document:

5) 6.8. Revised I-D Needed (annotation tag)

  The Datatracker should be programmed to send an e-mail to the WG's
  Chairs and delegates after the number of weeks specified in R-087 to
  remind or 'nudge' the WG Chairs and delegates to follow-up on the
  revisions to the document, unless a revised document is submitted
  before the time elapses. (R-098)

Does posting of a new revision automatically clear the "Revised I-D Needed" annotation tag?

6) 8. WG document status change reporting requirements

  Everyone with 'write' access to WG document status information
  SHOULD be able to obtain a summary display of all status changes
  made to the WG documents they are responsible for, from the present
  time backwards, split by pages, after successfully logging-on to the
  Datatracker. (R-101)

Is there any reason why this information is only accessible to people with "write" access? One great advantage of the existing datatracker is that information about a document is visible to everyone (including all history), although there is a way to mark certain things as "private" (not visible to others).

[Ballot discuss]
(Consistent with Robert's issue #1)

The processing described in the Candidate WG Document state adds a lot of formality that are not currently
practiced by most IETF working groups, and don't seem to be supported by 2026.  Is a datatracker requirements
draft the place to institute new process requirements?

[Ballot comment]
[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!

[Ballot comment]
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?

[Ballot comment]
10. Could you mention WG Secretaries explicitly somewhere. Perhaps
as an example when you mention delegates the first time?

---

11. Minor inconsistency that "WG chair" and "IETF WG chair" are both
used.

---

12. Section 2

  - I-Ds that are being considered for adoption by one or more WGs.

Maybe an unnecessary nit, but "are being considered" is passive voice
and I know a number of document authors who do nothing but consider
their I-Ds for adoption by a WG. Would you mind changing to...

  - I-Ds that are being considered under the guidance of a WG chair for
    adoption by one or more WGs.

---

13. Section 2

  An I-D having a filename that includes the author's name and a WG
  acronym but not the string "-ietf-" may be a candidate for adoption
  by a WG and is also to be interpreted as being an "I-D associated
  with an IETF WG" for the purposes of this document.

Sorry to be a pedantic lawyer, but... :-)

"is also to be interpreted" should be scoped to within the two bullets
at the top of the section, I think. So perhaps...

  An I-D having a filename that includes the author's name and a WG
  acronym but not the string "-ietf-" may be a candidate for adoption
  by a WG and, if so, is also to be interpreted as being an "I-D
  associated with an IETF WG" for the purposes of this document.

---

14. Requirement 10

I don't feel it is correct to place requirements on the implementation
that do not affect:
- the blackbox behavior
- the cost
- the maintainability

It is possible that you feel that this requirement falls into the third
category, but it seems a bit out of scope to me.

Alternatively, it may be that you simply meant that the implementation
should use the state machines documented in [WGDRAFTS]  to determine
the valid state transitions.

---

15. Requirement 40

Very pedantic. Sorry!

  The Datatracker SHALL allow WG Chairs and their delegates to set and
  reset all of the WG I-D status annotation tags defined in Section
  3.5 of [WGDRAFTS] for every I-D associated with their WGs. (R-040)

s/all of the/each of the/

(The subtly being that you have implied that they can set/reset "all at
once" - a button that often exists on GUIs, but not what you mean.)

---

16. Requirement 86

Pretty petty, but...

  The WG Chair (or delegate) who moves an I-D into the "In WG Last
  Call" state SHALL be required to specify the number of weeks that
  the document may remain in this state.

Why is the granularity required to be in weeks?
Can we have a "date and time for end of last call"?
Very often I have started a WG last call on a Friday and wanted to let
it run two weeks and until first thing Monday morning.

[Ballot discuss]
Thank you for undertaking this work which I see as very important for
the stability of the IETF as it continues to be under a lot of
pressure caused by increasing workloads and decreasing resources.

I will move to a "Yes" ballot after we have addressed my small issues,
below. I also have one point for discussion with the rest of the IESG.

(A large number of issues reflects the importance of the work and the
readability of the work; it does not indicate any quality issues.)

===

Discuss-Discuss (i.e. author need take no action)

It seems to me that some of the sections of this document are
constraining on the way that the WG chairs operate their WGs. For
example, in section 6.1

  The "Candidate WG Document" state may be used to describe:

  - an I-D that someone has asked to be considered by a WG, if the WG
    Chair has agreed with the request;

  - an I-D that the WG Chair asked an author to write; or

  - an I-D listed as a 'candidate draft' in the WG charter.

And similarly, in section 6.1

  The first WG Chair (or delegate) to move an I-D into the "Candidate
  WG Document" state SHALL be required to specify the maximum length
  of time that the I-D may remain in this state. (R-056)  The maximum
  length of time that an I-D may remain in the "Candidate WG Document"
  state SHOULD be specified as a number of weeks. (R-057)

Don't we want to be careful to not create WG operational process as a
side effect of this document? Shouldn't this document be limited to
the behavior of the tool?  Noting, in particular, that
draft-ietf-proto-wgdocument-states is Informational and not a BCP.

For example, in the second case, this would change to "SHALL be able to"

===

Discuss

1. Requirement 2

  (e.g. other WG Chairs)

This is ambiguous. It could be taken to mean chairs of other WGs.
Suggest you use
  (e.g. another chair of the WG)

---

2. Requirement 3

  The WG status of every IETF Stream I-D SHALL be tracked using the WG
  document states, WG document status annotation tags, and intended
  document maturity levels specified in [WGDRAFTS]. (R-003)

Appears to read like a requirement on the IETF or the WG chairs, not a
requirement on the Datatracker.

Do you mean:
  It SHALL be possible to track the WG status of...

---

3. Requirements 7 and 8

Requirement 8 is a MUST. We cannot have documents changing state without
accountability.

I feel that requirement 7 is very close to a MUST because it is very
important to be able to see how long a document has been "stuck" in a
state.

Pretty sure that R-042 is a MUST at the same time.

---

4. A really useful feature of the datatracker is that a Comment can be
inserted at any time to add context. This could be when there is a
state change (or, indeed, when there isn't a state change when one
might reasonably be expected).

I think this should be called out explicitly as a feature and all of
- WG chairs
- delegates
- shepherds
MUST be able to add comments which MUST be date stamped and tracked
against the user.

(This sort of shows up partially in R-037.)

---

5. Requirement 18

  - SHALL NOT be allowed to create ad hoc WG document states or state
    names; (R-018)

It is not explained what an "ad hoc WG document state or state name" is.
- ad hoc WG?
- ad hoc document in a WG?
- ad hoc state?

I suspect that the text would read as well by deleting "ad hoc".

---

6. Requirements 37 and 38

  After displaying the information required by R-036, the Datatracker
  SHALL prompt the WG Chair or delegate to select a next state for the
  I-D and to enter some text to explain the state change for the I-D's
  status change history. (R-037)  The Datatracker SHOULD always prompt
  the person who updates or changes the WG state of an I-D to input
  some text for the I-D's status change history. (R-038)

37 seems to say SHALL {prompt next state, prompt text}
38 says SHOULD {prompt text}

So 37 and 38 overlap / conflict

---

7. Section 5.3

This section appears to say that the write-up is a single entity that
can be eddited, and some form of change log. I'm not oppsed to this,
but i want to check that you are aware that this is different from the
current system where any changes to the write-up are represented by a
complete upload of a new copy of the write-up.

---

8. Timer pops

(This may be a joint issue with draft-ietf-proto-wgdocument-states

There is inconsistency in how timer pops are handled.
For example, when in CANDIDATE WG DOCUMENT and the timer expires, the
state changes automatically; but when in IN WG LAST CALL and the timer
expires, the state does not change.

Inconsistency is not good!
In fact, states that have a timer should have a "follow-up state" so
that it is clear what the state is and what the next action actually
is.

---

9. Section 7

  Requirement R-001 provides each IETF WG Chair with the freedom to
  decide to use all or just some of the WG document states defined in
  [WGDRAFTS] to indicate the status and progression of documents in
  his or her working group.

This is not how I read R-001! It reads...

  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)

I.e., the requirement talks about the optionality applying to the
drafts (one at a time). It does not talk about the optionality of
some of the states. What is more, a number of the other requirements
show some rules about state transitions that appear to indicate a
lack of optionality.

Section 7 goes on to say:

  The same requirement also allows each
  IETF WG Chair to decide to *not* log-on to the Datatracker to
  manually input or update the status of drafts in her/his WG.

This could be read two ways. One reading implies that the states
can be changed in some way other than by logging on.

[Ballot discuss]
Updated to remove #3, but I retained the numbering.

Great document.  Just a couple of things I'd like to clear up:

#1) R-008: Why isn't the time-stamp and identification of the person who made the change a MUST?  On a tangential note, maybe we should be tracking exactly who it is who did the submission.  This information might be useful.

#2) R-20: Should we limit the number of delegations allowed per-WG?  Can we pick an upper bound of say 3 people per WG that aren't WG chairs?

#3) Resolved.

#4) R-035: When would the datatracker not show the state etc after logging on?

[Ballot comment]
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
else.

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).

[Ballot discuss]
1) Where this document is capturing requirements to facilitate WG tracking using
  processes that WG chairs are already exercising I think it's on track. I believe
  it and it's companion state document are going going further than that in
  with the definition of the Candidate WG document and Not Adopted by a WG states
  and the behavior required not just of the tool but of the chairs by this document.
  Attempting to define a new process and codify it into a tool at the same time seems
  risky. I would prefer to see the requirements around tracking a document before WG
  adoption split into a separate effort, both in determining requirements and implementing
  the tool. (It would be even better if there was experience with the suggested process -
  an interested chair and cooperative AD could do this now with the comments field in the
  existing tracker.) Our initial effort should be scoped to helping WG chairs and other
  stakeholders track what they already do.


2) R-003 can be read to mean that every IETF Stream document SHALL be tracked using this tool,
contradicting R-001. I suggest that the first part of the requirement be rephrased thus:

  When the WG status of an IETF Stream I-D is tracked, the Datatracker SHALL use the
  WG document states ...

3) Why is R-012 SHOULD and not MUST?


4) There are a couple of places (For instance R-021) where a design decision is being
made (probably the right decision, but I'm not sure this is the tool to make that
decision with)- there are people now with exising datatracker/tools logins whose login name
does not look like an email address. This decision will force delegation to them to be through
an email address _associated_ with the login. MANY people with datatracker logins have more than
one email address. Could we remove this bit of design? If not, can we acknowledge that
people may have more than one email identifier?

5) The delegation requirements in 4.2 seem to be written from the viewpoint of a chair
delegating authority for all of the documents in the working group. Why are they not
written so that delegation is done on a per-document basis (in the spirit of R-012)?

6) R-054 (also touched in Alexey's comments) imply that someone must logout to change
roles. If that was the intent, it should be made explicit.  I hope that was NOT the
intent and I think we need an additional requirement that a login that can serve
multiple roles be allowed to change roles on demand without logging out.

[Ballot comment]
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/

[Ballot discuss]
Section 4.2., paragraph 1:
>    When an IETF WG Chair needs to input or update the WG status of an
>    I-D in one of his or her WGs, the WG Chair SHALL be required to log-
>    on to the Datatracker using a personal user-id and password (e.g.,
>    an IETF tools password) in order to gain 'write' access. (R-015)

  DISCUSS: This is redundant with R-014.


Section 4.2., paragraph 3:
>  - SHALL be given full 'read' and 'write' privileges to input and
>    update WG status information for all of the I-Ds associated with
>    their WGs, one WG at a time; (R-016)

  DISCUSS: This is redundant with R-014 and R-015, and it's unclear what
  the "one WG at a time" bit means.


Section 4.2., paragraph 7:
>  - SHALL be able to designate one or more people to act as delegates
>    to input and update the WG status of the I-Ds associated with their
>    WGs; (R-020)  The identifier for each delegate should be the
>    person's e-mail address; (R-021)
>  - SHALL be able to designate different people to act as delegates for
>    them in different WGs when the WG Chairs are also responsible for
>    the different IETF WGs; (R-022)

  DISCUSS: This sounds like the delegates are personal delegates of the
  chair; in reality they are WG secretaries.


Section 4.2., paragraph 9:
>  - SHALL be able to assign people to be Document Shepherds for one or
>    more WG I-Ds if this role will not be performed by a WG Chair or a
>    designated delegate; (R-024)  The identifier for each Document
>    Shepherd should be the person's e-mail address. (R-025)

  DISCUSS: The shepherd must always be a chair or secretary, this cannot
  be delegated to others. (If all chairs and secretaries are
  disqualified from being shepherds, this role falls back to the AD.)


Section 4.2., paragraph 11:
>  - SHALL be able to review and change the people assigned to be
>    Document Shepherds in their WGs, one WG at a time. (R-027)

  DISCUSS: No. See above.


Section 4.3., paragraph 0:
> 4.3. For Delegates of IETF WG Chairs

  DISCUSS: The "delegates" stuff is too complex and not in light with
  how WG secretaries work. For the purposes of the tracker, secretaries
  for a WG are just like chairs except they cannot appoint and remove
  secretaries.


Section 4.4., paragraph 0:
> 4.4. For IETF WG Document Shepherds

  DISCUSS: The document is confused about what shepherds are. According
  to RFC4858, shepherds are chairs, and if the chairs are conflicted,
  they are secretaries, otherwise this role falls back to the AD. The
  shepherding role cannot be otherwise delegated.


Section 6.1., paragraph 0:
> 6.1. Candidate WG Document

  DISCUSS: This entire process for handling documents that may be
  candidates in multiple WGs is super complex and mostly useless,
  because such cases almost never exist, esp. not concurrently. Plus, it
  invents a new process with deadlines, timers and notifications where
  we currently have none, and I don't think that's the purpose of this
  document.

[Ballot comment]
1) 4.2. For IETF Working Group Chairs

  When an IETF WG Chair needs to input or update the WG status of an
  I-D in one of his or her WGs, the WG Chair SHALL be required to log-
  on to the Datatracker using a personal user-id and password (e.g.,
  an IETF tools password) in order to gain 'write' access. (R-015)

[...]

  - SHALL be able to designate one or more people to act as delegates
    to input and update the WG status of the I-Ds associated with their
    WGs; (R-020)  The identifier for each delegate should be the
    person's e-mail address; (R-021)

I think it would be a good idea to clearify the relationship between a user-id and an email address. Currently each user-id is an email address, but the text above seem to be implying that some kind of mapping might be possible.
This also affects other sections (e.g. 4.3).

2) 4.3. For Delegates of IETF WG Chairs

  The Datatracker SHOULD alert the WG Chairs, the IETF Secretariat,
  and the newly designated delegate via e-mail if a person who is
  newly designated to be a delegate of a WG Chair does not have a
  personal user-id and password to log-on to the Datatracker. (R-029)

What about showing this information to the WG chair when he/she adds a delegate in the datatracker's web interface?

3) 5.1. WG Document States

  The Datatracker SHALL allow WG Chairs and their delegates to select
  the next state for an I-D from one of the 'most likely' next states
  described in Requirement R-035, or from any of the other WG document
  states (per Requirement R-017) if needed. (R-039)

Why not just say that any state transitions are allowed.
If the intent of the wording is to show that there should be an easy way to select one of the 'most likely' states, then that should be stated explicitly.

4) 5.3. WG Document Protocol Write-ups

  IETF WG Chairs and delegates may designate themselves to act as the
  Document Shepherds for some or all of the I-Ds in their own WGs.  In
  the WGs where this happens, the Datatracker SHOULD ask the WG Chairs
  and delegates which role they are playing when the log in, in order
  to display the most appropriate user-interface for that role.
  (R-053)

Speaking as an individual, I would dislike an interface that is forcing me to act in a particular role without allowing me to change the role. In particular I am hoping that once a role is selected, it can be changed without the need to logout and login again.

5) 6.1. Candidate WG Document

  The Datatracker SHALL allow an IETF WG Chair or delegate to identify
  an I-D as a "Candidate WG Document" in her or his WG if the I-D has
  not yet been adopted by any IETF WG, is not expired and has not been
  withdrawn or replaced by another I-D. (R-054)  The Datatracker
  should not allow a document that is expired, withdrawn, replaced or
  already adopted by an IETF WG to be moved into the "Candidate WG
  Document" state.

I am slightly concerned about not allowing a replaced document to be used as a "Candidate WG Document". Sometimes documents get forked, or a document which was once replaced by another one might be abandonned by the WG. It should be possible to use such documents elsewhere.

6) 6.1. Candidate WG Document

  When Requirements R-056 and R-057 are met, the Datatracker SHALL
  display the WG status of the I-D as follows: "Candidate WG Document
  in (name of IETF WG)". (R-058)

I hope you didn't mean that the status should be presented exactly in the form shown above.

7) 6.3. Not Adopted by a WG

  Notwithstanding the aforementioned, a different IETF WG may decide

I think the same WG should also be allowed to adopt the document later on.
I suggest dropping the word "different" above.

  to adopt an I-D after it has entered the "Not Adopted by a WG"
  state.  The Datatracker SHALL allow a WG Chair or delegate to move
  an I-D that is in the "Not Adopted by a WG" state into the "Adopted
  by a WG" state if the I-D has not expired, been withdrawn, or been
  replaced by another I-D. (R-075)

8) 6.4. WG Document

  The Datatracker SHALL allow WG Chairs and their delegates to move an
  I-D into the "WG Document" state from a different document state as
  defined in Section 3.3 of [WGDRAFTS] if the I-D has not expired,
  been withdrawn or replaced by another I-D. (R-079)

Just to double check: this would allow to adopt a draft as a WG document, without renaming it?
I think that would be useful.

[Ballot discuss]
I am largely happy with this document. However there are a couple of issues I would like to discuss before recommending approval of this document:

1) 3. General requirements

  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)  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)

Why only SHOULDs (twice)?

2) 6.1. Candidate WG Document

  The Datatracker SHALL also remove the name of the IETF WG from its
  WG status display (of other WGs (per Requirement R-061) in which the
  I-D is still being considered for adoption), and remove the Chairs
  (and delegates) of the WG from the distribution list for the e-mails
  that may be generated per Requirements R-063, and R-065 to R-069
  inclusive. (R-072)

Should this also result in an email to Chairs/delegates of other WGs?

3) 6.5. In WG Last Call

  It is possible that a WGLC may lead directly back into another WGLC
  for the same document.  For example, an I-D that completed a WGLC as
  an "Informational" document may need another WGLC if a decision is
  taken to convert the I-D into a standards track document.  The
  Datatracker SHOULD allow this to occur. (R-090)

I believe this must be a MUST level requirement. Not allowing multiple WGLCs would
be a serious deficiency in the tool.

4) DISCUSS DISCUSS:

6.8. Revised I-D Needed (annotation tag)

  A document that needs revision may be identified when the WG Chair,
  delegate, or the Responsible AD logs-on to the Datatracker to append
  one of the "Issue Raised - Revision Needed" annotation tags to the
  status of the document.  The Datatracker SHALL require the person
  who attaches one of these annotation tags to a document to indicate
  the number of weeks that it should take for the revised document to
  be produced (R-096).  The Datatracker should also prompt the user to
  consider changing the WG state of the I-D from "Submitted to IESG
  for Publication" to something else (e.g., Parked WG Document, WG
  Document, Waiting for WG Chair Go-Ahead). (R-097)

As an AD I would hate to be forced to use another interface to make a document as needing a new revision once the document is in IESG processing.
Can this be clarified?

5) 6.8. Revised I-D Needed (annotation tag)

  The Datatracker should be programmed to send an e-mail to the WG's
  Chairs and delegates after the number of weeks specified in R-087 to
  remind or 'nudge' the WG Chairs and delegates to follow-up on the
  revisions to the document, unless a revised document is submitted
  before the time elapses. (R-098)

Does posting of a new revision automatically clear the "Revised I-D Needed" annotation tag?

6) 8. WG document status change reporting requirements

  Everyone with 'write' access to WG document status information
  SHOULD be able to obtain a summary display of all status changes
  made to the WG documents they are responsible for, from the present
  time backwards, split by pages, after successfully logging-on to the
  Datatracker. (R-101)

Is there any reason why this information is only accessible to people with "write" access? One great advantage of the existing datatracker is that information about a document is visible to everyone (including all history), although there is a way to mark certain things as "private" (not visible to others).

[Ballot comment]
#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?

[Ballot comment]
#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?

#9) R-094: Should the

[Ballot discuss]
Great document.  Just a couple of things I'd like to clear up:

#1) R-008: Why isn't the time-stamp and identification of the person who made the change a MUST?  On a tangential note, maybe we should be tracking exactly who it is who did the submission.  This information might be useful.

#2) R-20: Should we limit the number of delegations allowed per-WG?  Can we pick an upper bound of say 3 people per WG that aren't WG chairs?

#3) Sec 4.6: Under what circumstances will the secretariat not verify that that the person requesting the permissions is a WG Chair or an AD or has been delegated the authority to update WG document status information by one of the WG's Chairs or a Responsible AD?

#4) R-035: When would the datatracker not show the state etc after logging on?

[Ballot comment]
#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)

Is this recursive?

[Ballot discuss]
R-008: Why isn't the time-stamp and identification of the person who made the change a MUST?  On a tangential note, maybe we should be tracking exactly who it is who did the submission.  This information might be useful.

R-20: Should we limit the number of delegations allowed per-WG?  Can we pick an upper bound of say 3 people per WG that aren't WG chairs?

Sec 4.6: Under what circumstances will the secretariat not verify that that the person requesting the permissions is a WG Chair or an AD or has been delegated the authority to update WG document status information by one of the WG's Chairs or a Responsible AD?

R-035: When would the datatracker not show the state etc after logging on?