Subject: [Gen-art] Gen-ART review of draft-ogud-iana-protocol-maintenance-words-03.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 30 Mar 2010 12:27:30 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

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

Document: draft-ogud-iana-protocol-maintenance-words-03.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 30-March-2010
IETF LC End Date: 14-April-2010
IESG Telechat date: 22-April-2010

Summary: This draft is on the right track but has open issues, described 
in the review.

Major issues: To my surprise, this document is aiming to the Standards 
Track, while I believe this document falls more into the Best Current 
Practice. Has this issue been discussed in the community? I believe this 
document does not specify any protocol, but a process to be carried out 
by IETF specifications. Therefore, I think it falls into the BCP track.

According to RFC 2026,

    Finally, the BCP series may be used to document the operation of the
    IETF itself.  For example, this document defines the IETF Standards
    Process and is published as a BCP.

Because of this, I cannot say that the document is ready for publication 
as a standards track RFC.

Minor issues:

Nits/editorial comments:

- At the beginning of SEction 3, I would like a new statement that 
indicates if these requirement words are mutually exclusive or not. I 
think they are, but it should be clarified.

- Also, on this Section 3, perhaps the authors could include a table or 
some sort of state diagram indicating the regular flow path of a 
protocol, i.e., the expected transitions in the value of the requirements 
for a protocol. For example, I do not expect a protocol to move from 
OBSOLETE to ENCOURAGED. But it will be common to see protocols moving 
from ENCOURAGED to MANDATORY. This will help to visualize the expected 
lifetime of a requirement.

- Idnits reveals that the term "MAY NOT" is not really an RFC 2119 
reserved word and should not be used.

- [RFC4835] is included in the normative references. I think there is no 
justification to be on the normative side, and should me moved to the 
informative references section.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain