Re: IANA Considerations

["C. M. Heard" <[e-mail]>]

On Mon, 11 Jul 2005, Paul Hoffman wrote:
> At 8:15 PM +0200 7/11/05, Brian E Carpenter wrote:
> > Paul Hoffman wrote:
> > > At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote:
> > > 
> > > > RFC 2434 doesn't discuss null IANA sections at all. RFC2434bis
> > > > does discuss them, and we will need to form consensus about
> > > > whether the RFC Editor is required to retain them, as we
> > > > discuss RFC2434bis.
> > > 
> > > I don't see any discussion of the RFC Editor retaining null IANA
> > > sections in RFC2434bis, which is good. It is a completely silly
> > > idea. An RFC should contain useful, long-lasting information. The
> > > fact that a particular document didn't require IANA action is not
> > > useful unless it is surprising, and if it is surprising, the
> > > section should not be null.
> > 
> > I respectfully disagree. I think that someone implementing or
> > deploying a given specification may well wonder whether any
> > IANA-assigned values are relevant, and the absence of a null
> > section in an RFC doesn't help with that.
> 
> But neither does a section that says "there are no new values
> registered". The presence of a null section only says "this
> document didn't cause any new registrations by its publication".
> A section that says "here are the IANA registries that are
> relevant to this document" would be useful to that implementer.
> We have never tried that, and I suspect it would take a lot of
> energy and thinking to do so.

When this issue came up in the context of review guidelines for MIB
documents, the MIB Doctors attempted to craft recommendations that
would achieve precisely this.  The results are in Section 3.5 of
<draft-ietf-ops-mib-review-guidelines-04.txt>, which is now in the
RFC Editor's queue awaiting publication as a BCP.  Maybe this can
serve as a "running code" template of what to do in other cases.

On Tue, 12 Jul 2005, Thomas Narten wrote:
> All implementation-necessary constants should be in the RFC.
> That is a given. But they typically already will be even if the
> IANA considerations is effectively:
> 
>      This document makes no new IANA registrations.
> 
> (i.e., when publishing an revised/updated Proposed Standard)
> 
> I'm somewhat torn on how much to leave in the final RFC,
> especially if a statement (like the above) seems to contain
> little information.

For the record, I am strongly opposed to such statements remaining
in published RFCs, and it will be noted that the text in Section
3.5.3 of <draft-ietf-ops-mib-review-guidelines-04.txt> specifically
recomments that such statements be included in drafts as editor's
notes that are to be removed upon publication.  However, the
guidelines also recommend that text describing the IANA-registered
values used (with the names of the registries where they reside)
remain in the final published document.

Continuing to quote from Thomas Narten's message of Tue, 12 Jul 2005:
> But from experience, I'll point out that anyone that has ever
> tried to reconstruct the history for a particular registry by
> looking at RFCs knows this can be extremely challenging.
> Including explicit notes that say seemingly little can speed up
> this process.
> 
> Unfortunately, even with good IANA web pages, its sometimes
> necessary to go back through the RFC trail to figure out what is
> really going on.

One question of this nature did arise in the first practical
application of the recommendations in Section 3.5.3 of
<draft-ietf-ops-mib-review-guidelines-04.txt>, viz.:

% The IANA has reviewed the following Internet-Draft which is in
% Last Call:  <draft-ietf-adslmib-gshdslbis-10.txt>, and has the
% following with regards to the publication of this document:
% 
% We understand this document to not request any NEW IANA Action.
% Should the reference for transmission number 48 for
% hdsl2ShdslMIB be changed to become this document or should the
% reference remain [RFC3276]?

After some discussion the policy that the MIB Doctors recommended
that the original reference be retained (i.e., no change to current
practice).  The reasoning was that this is less work for the IANA
than making an update, and if the registries consistently point to
the the document responsible for the _initial_ assignment, one can
always work through the chain of RFC updates if there is a need to
reconstruct the history (this assumes of course that the RFCs state
what parameters they use and in which registries they can be found).

Mike Heard


_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf