RE: IANA considerations requirement in "AD Review of I-Ds" (http://www.ietf.org/ID-nits.html)

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Mike, I am checkingmore details with IANA and some other IESG members
before I will post a reply.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: donderdag 26 december 2002 22:49
> To: mreview@ops.ietf.org
> Subject: IANA considerations requirement in "AD Review of I-Ds"
> (http://www.ietf.org/ID-nits.html)
> 
> 
> Colleagues,
> 
> Section 1.3 of the ID-nits document dated 2 Nov 2002 and posted
> 7 Nov 2002 says this about IANA considerations:
> 
>   1.3 Sometimes-required sections
> 
>      * 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
>      * See RFC 2434, and also RFC 2780 in some cases.
> 
> I'm interested in discussing these rules specifically as they
> apply to MIB documents (note that RFC 2780 does not apply).
> 
> The first of these requirements -- for an I-D to have an IANA
> considerations section if the document creates a new registry
> or modifies the rules for an existing one -- is derived from
> the requirements imposed on the final published RFC, and is
> clearly documented in draft-rfc-editor-rfc2223bis-03.txt and
> RFC 2434.  Section 3.7 of the draft MIB review guidelines I
> posted to this list back in November covers that requirement
> as it applies to Internet Drafts that contain MIB documents,
> including stuff that is to be present in the I-D but is to be
> removed prior to publication.
> 
> The second requirement -- for an I-D to have an IANA considerations
> section if the document requires IANA to assign or update values
> in an IANA registry before RFC publication -- is, obviously, a
> requirement imposed specifically on I-Ds.  This requirement is
> NOT captured in Section 3.7 of the draft MIB review guidelines.
> Presumably it is intended to apply to top-level OID registration
> requests such as this one that appear in most new MIB modules:
> 
>    etherWisMIB MODULE-IDENTITY
> 
>        [ ... ]
> 
>        ::= { transmission XXX }
> -- RFC Ed.: replace XXX w/IANA-assigned number & remove this notice
> 
> In my not at all humble opinion, documenting a request such as this
> one in the IANA considerations section of an I-D is not a very good
> idea, at least not without further guidance to authors.  If we need
> to document such requests other than with notations like the one
> above, I think it would be better to put it into an appendix that is
> to be removed prior to RFC publication, as is now done for the
> initial versions of IANA-maintained MIB modules.  Here are my reasons.
> 
> Without providing further guidance to I-D authors, we are likely to
> see stuff like this appear in first-time MIB documents:
> 
> X.  IANA Considerations
> 
>    This document describes the etherWisMIB Management Information
>    Base (MIB) module for standardization under the transmission
>    branch registered with IANA.  An IANA-assigned number is
> -->requested for this MIB module under the transmission branch.
>    ^^^^^^^^^
> 
> It seems clear to me that STUFF LIKE THIS SHOULD NOT APPEAR IN THE
> PUBLISHED RFC, for once the RFC has been published, the request will
> have been fulfilled, and the "requested" language will then be
> inappropriate.  It would be especially inappropriate for this if
> this language were carried over into an I-D containing a subsequent
> revision of the MIB module, for it would then be an outright lie.
> 
> Now, the purpose of having the IANA considerations section in
> an RFC is, according to RFC 2434, to provide guidance for the
> administration of an IANA-maintained name space.  Neither
> RFC 2434 nor draft-rfc-editor-rfc2223bis-03.txt requires an IANA
> considerations section in an RFC just to document a request for
> an assignment that has already been granted -- that, after all,
> is what the IANA-maintained registry is for.  It would appear,
> then, that using the IANA considerations section in an I-D to
> document a pending request amounts to overloading of the IANA
> considerations section for a purpose beyond its original scope.
> 
> I have no quarrel with the IESG's requirement for I-Ds to clearly
> document requests to assign or update values in an IANA registry.
> However, it seems to me that the IANA considerations section is the
> wrong place to do it.  I think that the purpose would be better
> served by requiring that the I-D contain an appendix, to be removed
> upon publication as an RFC, that documents all requests for IANA to
> assign or update values in an IANA registry before RFC publication.
> That solves the problem of inappropriate language appearing in the
> RFC and possibly in I-Ds that contain updated version of the
> specification.  It is what we currently do for the initial contents
> of IANA-maintained MIB modules, and that practice seems to work
> quite well.
> 
> If the idea of using a separate appendix for registration requests
> does not appeal to the powers-that-be, then we at least need to
> make sure that what appears in the published RFC contains
> appropriate language.  To replace the bad example above I would
> suggest something along the following lines:
> 
> X.  IANA Considerations
> 
>    The ETHER-WIS MIB module defined in this document is registered
>    under an IANA-assigned node in the transmission OBJECT IDENTIFIER
>    subtree [RFC2578].  That node is defined as "etherWisMIB" in the
>    ETHER-WIS MODULE-IDENTITY invocation.  Subordinate assignments
>    under etherWisMIB will be managed by the IETF working group
>    responsible for maintaining the ETHER-WIS MIB module;  no further
>    IANA action is required.
> 
>       NOTE TO BE REMOVED UPON PUBLICATION:  prior to publishing
>       this draft as as an RFC, a sub-OID under the transmission
>       OBJECT IDENTIFIER subtree needs to be allocated for
>       etherWisMIB by IANA, and this sub-OID needs to be inserted
>       by the RFC Editor into the ETHER-WIS MODULE-IDENTITY value.
> 
> I really don't like the idea of putting relatively trivial stuff
> like this into IANA considerations sections because I think it
> only serves to dilute the important stuff that RFC 2434 invented
> them for.  But I guess that it's acceptable provided that the
> language that makes its way into the published RFC (in the example
> above, the first paragraph only) makes sense even if it apears in
> subsequent revisions of the specification.
> 
> Bert, as you might have guessed from the names in my examples,
> this is something I need to get resolved not just for the
> guidelines document but also for a pending I-D update, so I'm
> especially interested in hearing what you have to say.
> 
> Thanks,
> 
> Mike
> 
>