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
