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

["Michelle S. Cotton" <cotton@icann.org>]

Mike, IESG,

I'm OK with removable Annex IANA Considerations sections.
The IANA just needs (even if it is removable before publication)
instructions or a request in the document for assignment for
a protocol parameter.  Let me know if you have any questions.

My 2 cents...  :)

Michelle S. Cotton
IANA Administrator

-----Original Message-----
From: iesg-admin@ietf.org [mailto:iesg-admin@ietf.org]On Behalf Of C. M.
Heard
Sent: Thursday, December 26, 2002 1:49 PM
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