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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf