On Sun, 16 Mar 2003, Pekka Savola wrote: > 2.10 IANA Considerations > [ ... ] > ==> so, IANA considerations is not needed if you're just requesting a few > values from existing namespaces? It would seem to make sense to have a > section anyway (at least in the I-D's if not necessarily RFC's). In some > namespaces, there are some subsets of a namespace (example: different option > values in IPv6 hop-by-hop/destination options header), so specifying the > requested values somewhere might be useful. > ==> same in 4.11 I believe that <draft-rfc-editor-rfc2223bis-04.txt> is just reiterating what is required by RFC 2434. The current policy for I-Ds is, however, much as you suggest; see http://www.ietf.org/ID-nits.html and specifically this part: * IANA considerations * Required if IANA has to create a new registry or modify rules for an existing registry. * Required if the document requires IANA to assign or update values in an IANA registry before RFC publication. Note that for the assignment of just an OID for a MIB or PIB Module, no IANA Considerations section is required; it is sufficient to request such via a MIB/SMI or PIB/SPPI comment line, aka: ::= { mib-2 xxx } -- xxx to be assigned by IANA * See RFC 2434, and also RFC 2780 in some cases. If this policy is to be captured in the "Instructions to Request for Comments (RFC) Authors" document [do we really need to have _that_ acronym expanded? :) ] it should be noted that the wording that goes in the RFC should not discuss a request for an assignment (as an I-D usually does) but an should instead discuss the actual assignment. This has been done in recently-published RFCs, but inappropriate language has slipped through in the past (see RFC 2493 for an example). //cmh