Hi Miguel. Thanks for your comments.
Miguel Garcia <[EMAIL PROTECTED]> writes: > Thomas, Harald: > 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-narten-iana-considerations-rfc2434bis-07.txt > Reviewer: Miguel Garcia <[EMAIL PROTECTED]> > Review Date: 2007-08-11 > IETF LC End Date: 2007-08-17 > Summary: The document is almost Ready for publication as a BCP. > Comments: > 1) My general comment is related to the relation of this draft to RFC > 4858 (Document Shepherding from WGLC to publication). Especially, > Section 4 of RFC 4585 says: > At the time of this publication, RFC 2434 is under revision > [RFC2434bis], and the updates are and will be of value to the > Document Shepherd. Note that the Document Shepherd MUST determine > (by individual review and consultation with others) what is the most > recent and the most applicable IANA information and guidance for his > or her document, be it the overall guidance, or external documents in > his or her area, or in other areas. An example of an external > document is [RFC4020]. > So, I was expecting that the draft, which is the mentioned revision of > RFC 2434, mentions the role of the Document Shepherd with respect IANA > considerations and IANA experts. At the moment, it is left to the > reader's interpretation. My suggestion is to clarify the role of the > Document Shephard and the IANA process. I can't think if anything right off about document shepherding that should go into 2434bis. I think that the text you cite above (and the rest of that section) talk about the role of the shepherd, their responsibilities, and interactions between the shepherd and IANA. However, 2434bis really is targetted toward the document author, and what they need to do to make their IANA intentions clear. 2434bis does not at all deal with operational aspects of document processing (e.g., what the IESG does with IANA comments, or what a shepherd does, etc.) So, my take is that no changes are needed in 2434bis. Indeed, it's really unclear what would be appropriate to say, or what you would expect to see. If you disagree, could you be more specific about what you think is needed? I.e., what text should change, and where? > 2) Although the document uses normative term (e.g., MUST), and > includes a reference to RFC 2119, it is not done accurately. First, > the RFC 2119 boilerplate is out of date (and id-nits > complains). Then, the boilerplate is typically written in a separate > section titled 'Terminology', rather than buried at the end of the > Introduction section. Last, RFC 2119 must be a normative reference. I have made some changes to the text, but I did not move it to a separate section. > 3) Small contradiction in Section 11, IANA Considerations. While the > document indicates that "this document is all about IANA > considerations", it fails to comply with its own Section 6.1 to say > whether the document itself mandates actions to IANA. I would suggest to > add or replace the existing sentence with: > This document has no IANA actions. :-) > 4) id-nits reveals some other very minor nits: > - missing expiration date in the draft > - no 'intended status' > - A number of obsolete references, although I think they some of them > might be intentional, because they are examples of existing IANA registries. > - draft-carpenter-protocol-extensions in now RFC 4775 Fixed (mostly). In some cases, the idnits warnings can't really be addressed. And they are just warnings. Thomas _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
