Subject: Re: IANA Considerations

From: Joe Touch <[email-masked]>
Date: Tue, 05 Jul 2005 17:57:10 -0700

Can anyone suggest where I could find the requirement for IANA
Considerations?

I found it on the website, but it's not listed in any RFC (just in an
expired ID, one that even mentions that empty IANA Considerations
sections may be dropped by the RFC Editor upon RFC publication).

Joe

Ned Freed wrote:
>>    Ned> Unfortunately so is the presence of an empty IANA
>>    Ned> considerations section - you cannot tell the difference
>>    Ned> between such a section that was arrived as as a result of
>>    Ned> careful review of the draft and one that was simply created
>>    Ned> as a form of boilerplate.
> 
> 
>>It's actually been my experience that the rate of null IANA
>>considerations sections that should have contained content appears to
>>be significantly lower than the set of missing IANA considerations
>>sections when one should have been included.  Based on my perceptions
>>I do think this requirement is triggering some level of review.
> 
> 
> Hardly a ringing endorsement... And this requirement is quite new. It would be
> unprecedented if it hadn't triggered some level of initial review in these very
> early days. But wait a couple of years for the new to wear off and people being
> people will start to handle it as more boilerplate.
> 
> 
>>Thus
>>as an individual I support the requirement.  I do not have rigorous
>>data to support my assertion.
> 
> 
> Useful data won't be available for several years at least. Which is why it so
> surprising - and ominous - that the problem has already arisen in at least one
> document.
> 
> 				Ned\

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

---

From: Ned Freed <[email-masked]>
Date: Tue, 05 Jul 2005 18:17:34 -0700 (PDT)

> Can anyone suggest where I could find the requirement for IANA

There is no requirement that such sections appear in published RFCs. This
debate has never been about what's required in RFCs, but rather what's required
in drafts submitted to the IESG.

> sections may be dropped by the RFC Editor upon RFC publication).

The requirement on the website is what we've been discussing.

				Ned

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2005 08:27:15 -0700

> in drafts submitted to the IESG.

Why are there additional, _unpublished_ requirements to IDs?

> The requirement on the website is what we've been discussing.

Why is the website inconsistent with the published requirements? I

t seems like the need for the IANA Considerations section should be
withheld until it is actually formally issued as a requirement.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 06 Jul 2005 17:15:35 +0200

> in drafts submitted to the IESG.

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. Which we need to do fairly
soon.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2005 08:29:07 -0700

> required to retain them, as we discuss RFC2434bis. Which we need to do

It seems like such considerations are, by definition, relevant only for
standards-track RFCs. It is not useful to require it for other documents.

Joe

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 06 Jul 2005 11:55:57 -0400

In message <[email-masked]>, Joe Touch writes:
>This is an OpenPGP/MIME signed message (RFC 2440 and 3156)

>standards-track RFCs. It is not useful to require it for other documents.
Not at all -- code points can be assigned by non-standards track RFCs.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Eliot Lear <[email-masked]>
Date: Wed, 06 Jul 2005 18:04:00 +0200

Joe,
> 
> It seems like such [IANA] considerations are, by definition, relevant only for

I think you're correct in general but this is not always the case.
Consider URI schemes.  I think they're often informational, and in
general I see no reason to be otherwise.

Eliot

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Jul 2005 09:23:37 -0700

On Jul 6, 2005, at 8:15 AM, 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. Which we 
> need to do fairly soon.

In my "new internet draft" template, I have some stock text, which I 
change in the event that I actually need to assign a number to 
something or create a registry. It reads:

<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of the IANA.</t>
<t>Note to RFC Editor: in the process assigning numbers and building 
IANA registries prior to publication, this section will have served its 
purpose.  It may therefore be removed upon publication as an RFC.</t>
</section>

Personally, I can't imagine why we need anything more complex or 
legal-in-form than that.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 6 Jul 2005 09:50:37 -0700

At 5:15 PM +0200 7/6/05, Brian E Carpenter wrote:
>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.

--Paul Hoffman, Director
--VPN Consortium

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Jul 2005 11:41:43 -0700

On Jul 6, 2005, at 11:20 AM, Ned Freed wrote:
> This is exactly what I predicted would happen - the IANA 
> considerations section has now become part of the boilerplate in at 
> least one I-D template. (Actually make that two - I put in in my own 
> equivalent template some time back.)
>
> This opens the door to the author forgetting to check and the various 
> reviewers assuming the prsence of the sections means a check was done.

I suppose. That said, if IANA considerations was *not* built into the 
boilerplate, it would have a high likelihood of being omitted.

This argument is a little like saying that the Security considerations 
is part of the boilerplate and therefore Security will not be 
considered even if the document says it was considered. Good grief. The 
purpose of the IANA section is to make IANA's job easier - if there is 
something to allocate, they have to read the relevant parts of the 
document anyway, but if there is nothing for them to consider, they can 
be told that up front. Given all the work we put into reviews, is it 
really likely that this will not be reviewed?

---

From: Ned Freed <[email-masked]>
Date: Wed, 06 Jul 2005 11:20:44 -0700 (PDT)

> purpose.  It may therefore be removed upon publication as an RFC.</t>

This is exactly what I predicted would happen - the IANA considerations section
has now become part of the boilerplate in at least one I-D template. (Actually
make that two - I put in in my own equivalent template some time back.)

> Personally, I can't imagine why we need anything more complex or

What's require is already way too much.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 06 Jul 2005 11:43:55 -0700 (PDT)

> boilerplate, it would have a high likelihood of being omitted.

Which would then be noted on checklist review, causing a fairly careful check
to be made to see if there really aren't any considerations to be listed in
such a section.

> considered even if the document says it was considered. Good grief.

On the contrary, the cases could not be more different. We believe that is the
rare and exceptional document that doesn't have security considerations to
discuss. As such, either the presence of a section saying "there are no
security considerations" is a big red flag that immediately triggers a careful
security review to make sure there really aren't any.

Documents without any IANA considerations, on the other hand, are qutie common
and perfectly legitimate.

> The

Not only is it likely, we have actual running code:
draft-ietf-lemonade-mms-mapping-04.txt, recently approved by the IESG (and now
the subject of an appeal) contains IANA considerations and an IANA
considerations section saying there aren't any. And this happened while this
requirement was new and people were still paying attention to some extent. What
do you think things will be like a couple of years from now when this whole
discussion has been forgotten?

I note in passing that all this has been said in previous messages. The only
thing new here is the fact that I-D templates are now being constructed
containing boilerplate IANA considerations sections, just as I predicted.

				Ned

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2005 13:16:00 -0700

> reviewers assuming the prsence of the sections means a check was done.

The goal of putting it in the template is to encourage it be addressed,
rather than forgotten altogether.

However, I'm not at all in favor of requirements to IDs that are added
ad-hoc; until this actually makes it into an RFC as a formal
requirement, it won't be in the word template I manage.

Joe

---

From: Ned Freed <[email-masked]>
Date: Wed, 06 Jul 2005 13:24:50 -0700 (PDT)

> rather than forgotten altogether.

I am well aware of what the goal is, and have been from the beginning of
this discussion.

There has never been disagreement as to the goal, only as to the best means to
achieve it. I have asserted that requiring IANA considerations sections in
drafts submitted for publication is at best useless and potentially quite
harmful, and that the best way to insure coverage of IANA issues is to have an
explicit check for such things as part of our review process.

I also predicted that two things would happen: (1) A draft containing IANA
considerations and an empty IANA considertions section would be approved and
(2) That this section would take on the status of boilerplate in some draft
templates. Both predictions have now come to pass. 

				Ned

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2005 13:41:28 -0700

> templates. Both predictions have now come to pass. 

Boilerplate doesn't necessarily include the default text per se; the
template I manage has no default, but allows choice of predefined text
where available. The default text is selected only by deliberate choice.

Joe

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 7 Jul 2005 23:24:27 -0700 (PDT)

On Thu, 7 Jul 2005, Brian E Carpenter wrote:
> RFC 2434 doesn't discuss null IANA sections at all.

Right.  The requirement for null IANA Considerations sections first
appeared in the May 2004 version of http://www.ietf.org/ID-Checklist.html,
without prior notice to the community.

> 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. Which we need to do fairly soon.

In what venue will this discussion take place?  While I can
understand the value (to the IANA) of a null IANA Considerations
section in an Internet Draft, I'm strongly opposed to having them
appear in published documents.

Mike Heard

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jul 2005 20:15:02 +0200

I'm hesitant to relaunch this thread, but there are a number of points
that incite me to comment. Since there's been a fair amount of
repetition, may I ask people only to chime in with new thoughts?

Paul Hoffman wrote:
>> discuss
> 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.

C. M. Heard wrote:
...
 > In what venue will this discussion take place?

I think it has to be this list, absent a relevant WG.

Joe Touch wrote:
...
[re a mandatory section in all drafts]
 > requirement, it won't be in the word template I manage.

I don't agree that all operational requirements need to be in process
RFCs as formal requirements. We need to give the IESG of the day some
freedom to adapt requirements to current conditions. I felt that the
requirement for IANA Considerations was a fine idea when it was
introduced, and certainly nothing that needed to be BCPized.

Ned Freed wrote:
...
 > templates. Both predictions have now come to pass.

If true, (1) means that a mistake was made by several successive layers
of review. (2) is beside the point. But...

Bruce Lilly wrote:
...
 > You can make it three: mine says:
 >
 >    This memo adds no new IANA considerations.  The presence of this
 >    template text indicates that the author/editor has not actually
 >    reviewed IANA considerations.

Yes. Great idea. I updated my own XML template similarly.

Ned Freed wrote:
...
 >>As I expect you know, the IANA checks all documents at Last Call time,
 >>and the RFC Editor checks them before publication, for missing missed
 >>IANA actions.  However, redundancy does not seem to me to be a bad
 >>idea.
 >
 >
 > Of course I know this. But the tendency will be for the text to be believed
 > and for the review to be less thorough.

Ditto if it becomes known that the *next* reviewer's check list includes
"check for overlooked IANA issues: Y/N"

 > You're fighting human nature here, and you're gonna lose.

Always. The question is, what's the least bad compromise?

    Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 11 Jul 2005 12:08:00 -0700

On Jul 11, 2005, at 11:15 AM, Brian E Carpenter wrote:
> 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.

Personally, I never wonder whether there are any IANA-defined values in 
a specification. I do wonder from time to time what numbers are 
appropriate for various uses ("gee, this is the IP protocol, and I want 
to say that the interior header is TCP. How does one say that?"), and 
when I want to get a new number I wonder how to go about getting one. 
Once it is assigned, I'm afraid I don't much care who assigned it or by 
what process.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 Jul 2005 18:58:54 -0700

At 8:15 PM +0200 7/11/05, Brian E Carpenter wrote:
>>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.
>

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.

--Paul Hoffman, Director
--VPN Consortium

---

From: Thomas Narten <[email-masked]>
Date: Tue, 12 Jul 2005 11:28:02 +0200

> are relevant, and the absence of a null section in an RFC doesn't help

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.

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.

And, at the end of the day, RFCs are our archival history. So that is
the logical place to be archiving such things. (We don't currently
have any other way.)

Thomas

---

From: "C. M. Heard" <[email-masked]>
Date: Tue, 12 Jul 2005 08:01:21 -0700 (PDT)

On Mon, 11 Jul 2005, Paul Hoffman 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.
> > > 
> > IANA-assigned values are relevant, and the absence of a null
> > section in an RFC doesn't help with that.
> 
> 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:
> 
> 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

---

From: Joe Touch <[email-masked]>
Date: Wed, 13 Jul 2005 09:11:15 -0700

...
> introduced, and certainly nothing that needed to be BCPized.

Well, all other requirements for IDs and RFCs are described as formal
requirements in RFC 2223.

Your assertion goes to the whole issue of process, and how much leeway
the IESG is given to develop - and then enforce - process changes
without input from the IETF.

I don't accept kings, even those on the IESG.

Joe