Re: IANA Considerations [Re: New ID-Checklist to replace ID-nits (fwd)]

[David Meyer <dmm at 1-4-5.net>]

On Fri, Jun 04, 2004 at 10:24:22AM +0300, Pekka Savola wrote:
>> On Fri, 21 May 2004, Harald Tveit Alvestrand wrote:
>> > I assume most of you saw this message on ietf-announce.
>> > But since it's especially important to the WG chairs, I'm forwarding it to 
>> > you directly.
>> 
>> Another comment: IMHO it seems ludicurous that all the I-D's should 
>> include an IANA Considerations section, even if the document requests 
>> nothing of IANA.

	Why (especially on the scale of what's ludicurious [sic]
	these days)? Personally, I like the negative
	information. And what's the big deal anyway? Its all but
	automatically generated if there is no IANA requirement
	(at least it is for me).

	BTW, requiring an IANA considerations section also allows
	us to check as to whether the authors missed something
	that might help both the IESG and the IANA out with their
	(clearly daunting) task. 

>> Suggestion to fix this: change the policy so that if the document 
>> requires any action from the IANA, IANA Considerations section MUST be 
>> present.  Otherwise, no action of IANA is assumed.  (Previously, IANA 
>> Considerations has only been required if IANA has been required to 
>> create a new registry, assigning numbers could be done without the 
>> IANA Considerations section as well.)

	This suggestion would seem  counter to the IETF open
	review (transparency) philosophy; that is, how do you
	know that you don't need IANA considerations if you don't
	vett that assumption with your community of interest?
	Well, how do you vett your conclusions? You make them
	explicit in your document. 

	Finally, if you the reduction in the burden on the IESG
	and IANA vs. what it takes to do this, I don't see how
	not including this makes the process more efficient. For
	example, my now-ancient-technology-nroff-ID-template
	contains the following text:

.LP
.MH 1 "IANA Considerations"
.LP
.in 3

This document creates no new requirements on IANA namespaces [RFC2434]. 

...

.LP
.MH 2 "Informative References"
.LP
.in 3

.nf

...

[RFC2434]       Narten, T., and H. Alvestrand, "Guidelines for
                Writing an IANA Considerations Section in RFCs",
                BCP 26, RFC 2434, October 1998.

...
.fi


	Done. 

	In any event, I disagree with the suggestion that we
	change the policy for the reasons cited above. Maybe
	there are other more compelling reasons (to change the
	policy), but I haven't seen anything discussed on this
	thread would cause me to think we should change this.

	Dave