Document: draft-ogud-iana-protocol-maintenance-words-03.txt Reviewer: Miguel Garcia 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.