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