I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-juskevicius-datatracker-wgdocstate-reqts-04
Reviewer: Avshalom Houri
Review Date: 2010-07-15 (one day late, sorry)
IETF LC End Date: 2010-07-14
IESG Telechat date: (if known) -

Summary: The document is almost ready as an informational RFCs. Please see minor issues and 
nits/editorial comments.

Major issues: None

Minor issues:

The requirements may be more readable (to my taste) if they will be specifies in the form of  
R-xyz - text of the requirement and not as <text>(R-xyz).

This way it will be much easier to track the requirements.

It may be better to specify the various rules in one place. It will help the readability of 
the document.

Lines 201-202
  - the Chairs of a WG that has almost finished its charter milestones
    may decide to do otherwise.

Not sure what is meant by "decide to do otherwise"

Line 153:

The term "WG I-D" is mentioned but not defined.

Lines 204-205
   The Datatracker SHALL NOT permit users other than a working group's
   Chairs (such as for instance other WG Chairs) to update information

Not sure what "(such as for instance other WG Chairs)" means? Does it
mean chairs of other working groups?


Section 4.3 For Delegates of IETF WG Chairs

I assume that delegates will be identified by their own rule and will not be able to delegate to others.

Line 288
   Every IETF participant must be allowed to view information about the

"Every IETF participant" should probably be everyone as everyone
should be able to access this.

Lines 875-876
   SHALL allow the "Intended Maturity Level" to be changed after first
   being set. (R-074)

first time being set?

Nits/editorial comments:

Line 144:
   adoption by a WG.  An I-D having a filename that contains the string
->    adoption by a WG.  An I-D having a filename that starts with the string


Line 161
   The phase "WG status of an I-D" is to be interpreted as referring to
->    The phrase "WG status of an I-D" is to be interpreted as referring to

Line 162
   the document state that an I-D is in as defined in Section 3.3 of
->    the document state that an I-D is in, as defined in Section 3.3 of

Line 172
   of the document states used to by the IESG to describe the status of
->    of the document states used by the IESG to describe the status of

Lines 175-176
   The requirements specified in this document use English phrases
   ending with "(R-nnn)", where "nnn" is a unique requirement number.

->    The requirements specified in this document are indicated by "(R-nnn)",
where "nnn" is a unique requirement number.

Lines 228-231
   The user-interface to be created to input WG I-D status information
   into the Datatracker SHOULD have a look and feel that is similar to
   the interface used by IETF ADs to identify the status of documents
   under formal evaluation by the IESG. (R-005)

Sentence too long. Need to be rephrased.

Line 462
   for every WG in his or her Area. (R-035)
->    for every WG in his or hers Area. (R-035)

Line 601
   delegates which role they are playing when the log in, in order to
->    delegates which role they are playing when they log in, in order to

Line 607
   It is not uncommon for an author to 'shop' a document to multiple
->    It is not uncommon for an author to 'sell' a document to multiple

Line 945
   calling in a week's time if a write-up is completed for the I-D by
->    calling in a week's time if a write-up is not completed for the I-D by

Line 976
   After an I-D is submitted to the IESG, it may be judged to need
->    After an I-D is submitted to the IESG, it may be judged to need a

Line 980
   A document that needs revision may be identified when the WG Chair,
->    A document that needs a revision may be identified when the WG Chair,