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

From: Pekka Savola <[email-masked]>
Date: Fri, 4 Jun 2004 10:24:22 +0300 (EEST)

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.

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.)

> ---------- Forwarded Message ----------
> Date: 20. mai 2004 09:34 -0400
> From: The IESG <[email-masked]>
> To: IETF-Announce
> Subject: New ID-Checklist to replace ID-nits
> 
>     As you probably all know, we have used the ID-nits for a few
>     years to help you all to prepare your Internet-Drafts such that
>     they will process faster through the AD-review, IETF Last Call
>     and IESG approval process.
> 
>     The name was somewhat wrong in that it is more a serious checklist
>     than merely "nits" (however, there are some nits too).
>     The IESG, RFC-Editor and IANA have evaluated the checklist, and
>     a new (improved) ID-Checklist is now available at
> 
>             http://www.ietf.org/ID-Checklist.html
> 
>     Please help us all by actually CHECKING your Internet-Draft BEFORE
>     you pass it on to your AD and the IESG via a "request to publish".
>     It will help to make the process go faster and reduce the workload
>     on all of us if your document has been checked and complies with
>     the guidance/rules in the ID-Checklist.
> 
>     Thanks, the IESG
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce
> 
> 
> 
> ---------- End Forwarded Message ----------
> 
> 
> 
> 
> 

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 04 Jun 2004 09:37:27 +0100

> IANA Considerations section as well.)

You can argue that once a document has been published a NULL IANA
section is a waste of space. I suppose you could also make the
same case for the frequently NULL Security section. However to
omit such statements up front converts the protocol from positive
ack to negative ack with all the undesirable uncertainties.

If we really feel the need to save the bytes then I suggest that
it remains in place with a note that it is to be  deleted by the
(RFC) editor in the last processing pass.

Personally I would leave the NULL IANA statement in place as
a check so that everyone knows the exact status at all time.

- Stewart

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 04 Jun 2004 14:05:42 +0200

"This section intentionally left blank."

Stewart Bryant wrote:
>>> But since it's especially important to the WG chairs, I'm forwarding 
>>> it to you directly.
>>
>>
>>

---

From: David Meyer <[email-masked]>
Date: Fri, 4 Jun 2004 08:15:26 -0700

>> include an IANA Considerations section, even if the document requests 

	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. 

>> 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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 4 Jun 2004 08:38:47 -0700

>                 BCP 26, RFC 2434, October 1998.

We don't need the gratuitous reference added to every document. Just 
saying "This document creates no new requirements on IANA namespaces" 
or even "This document has no impact on any IANA namespace" is 
sufficient to get people who read the earlier drafts to say "yup" or 
"wait, what about that TBD in section 3.4?".

--Paul Hoffman, Director
--VPN Consortium

---

From: David Meyer <[email-masked]>
Date: Fri, 4 Jun 2004 09:32:24 -0700

>> "wait, what about that TBD in section 3.4?".

	Also reasonable. However, I try to be precise and support
	whatever I say with citations when I can. I have never
	really felt that citing authorative references were
	"gratuitous", but I (think I) understand your objection.

	Dave