Subject: IANA Considerations

From: Bruce Lilly <[email-masked]>
Date: Wed, 8 Jun 2005 13:59:19 -0400

> Re: Last Call: 'Email Submission Between Independent Networks' to BCP
>  Date: 2005-06-08 10:50
>  From: Ned Freed <[email-masked]>

> > .. RFC2119, when used, must be a normative reference.  Likewise,
> > you'll need to add a "null" IANA considerations section.
> 
> Agreed on the RFC 2119 reference. However, I do not believe there is any
> requirement for "null" IANA considerations sections. (A scan of recently
> published standards track RFCs turned up several that don't have such a section
> - 4022, 4015, etc.) Aren't we paddding out our documents with enough useless
> boilerplate already without adding yet another useless section to the mix?

The IETF Internet-Drafts page notes that "All Internet-Drafts that are
submitted to the IESG for consideration as RFCs must conform to the
requirements specified in the I-D Checklist".  The current version of
the ID-Checklist clearly states:

The following are REQUIRED sections in all Internet-Drafts: 
[...]
IANA Considerations 
A 
Must specify if IANA has to create a new registry or modify rules for
an existing registry. 
B 
Must specify if the document requires IANA to assign or update values
in an IANA registry before RFC publication. 
C 
See "Guidelines for Writing an IANA Considerations Section in RFCs"
[RFC2434] and in some cases also "IANA Allocation Guidelines For Values
In the Internet Protocol and Related Headers" [RFC2780]. In some case
"Assigning Experimental and Testing Numbers Considered Useful" [RFC3692]
may help as well. 
D 
If there is no action for IANA, the section should say that, e.g.,
including something like "This document has no actions for IANA." 

And the RFC-Editor's "instructions to RFC Authors" (draft successor to
RFC 2223, on hold) notes:
      Current policy (not documented in [IANA98]) is to include an IANA
      Considerations section always, even if it is "null", i.e., even if
      there are no IANA considerations.  This is helpful to IANA.
      However, the RFC Editor may remove any null IANA considerations
      sections before publication.

I believe the requirements exist to ensure that draft authors give due
consideration to IANA Considerations and that IANA can readily determine
if some action is or is not required.  Evidently (and unfortunately) the
IETF Secretariat apparently doesn't enforce that part of the ID-Checklist
rules.

As the RFC Editor removes null sections, you won't find them in published
RFCs.  But Internet-Drafts are REQUIRED to have them.

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 08 Jun 2005 14:23:49 -0400

On Wednesday, June 08, 2005 01:59:19 PM -0400 Bruce Lilly 
<[email-masked]> wrote:

> Evidently (and unfortunately) the

Aside from making sure the proper boilerplate is included in documents it 
publishes (which it pretty much has to do for legal reasons), the IETF 
secretariat generally does not check submitted I-D's for conformance with 
standards for submissions.  To do otherwise would not only be expensive and 
slow down the I-D submission process considerably; it would also interfere 
with the IETF process.  Internet-Drafts are works-in-progress; it is not 
necessary or even desirable that every I-D be in a form suitable for 
submission to the IESG before being added to the repository.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Bruce Lilly <[email-masked]>
Date: Wed, 8 Jun 2005 14:34:08 -0400

>  Date: 2005-06-07 16:37
>  From: Dave Crocker <[email-masked]>

> >  1) What the implications of treating out-of-network mail injection as
> >  submission are.
> 
> Unfortunately, you are asking an entirely open-ended question and I do not know 
> what "implications" you are looking for.  

One disturbing implication is that message submission permits modification
of a message without the knowledge or consent of the connecting client.
Of course a relay operator can whisper "this is a gateway" and do the same
sort of modifications with the same lack of client knowledge or consent.
 
> I DO know what happens when there is unauthenticated relaying that originates 
> from outside one's network.  What happens is that you get blacklisted.  It is, 
> after all, what the term "open relay" refers to and what is so popular with mass 
> spammers.

Dave, I think you know the difference, but since this is a general list, an
"open relay" is one that forwards messages which neither originate from nor
are destined for its administrative domain.  Simply authenticating relaying
("yes, it's from outside and destined for outside") doesn't close an open
relay. [and I have carefully avoided defining "originate from" or
"administrative domain"]
  
> > In particular, what would be the difference
> >  between treating this as submission and treating it as relaying
> >  with a requirement for authentication/authorization?
> 
> The major difference is accountability.  When a message is treated as a 
> submission, then the submission agent (MSA) is able to take a reasonable degree 
> of responsibility for the (new) message.  For simple relaying, such 
> accountability is essentially impossible.

There is really only a "new" message it the content is substantially
modified.  Of course both MSAs and MTAs (acting as gateways) are
permitted to modify content, but neither is required to do so.

> Simply put, the open Internet's email infrastructure is under attack.  The 
> postal mail global infrastructure, and all of the large-scale services that do 
> global transfers, are subject to a high degree of accountability for their 
> activities and they have a significant degree of control they impose at their 
> boundaries.  By contrast, Internet mail is entirely open, with no trusted core.  

I (hypothetically) write "Dave Crocker" in the return address space on
an envelope, address it, and pop it into a mailbox.  Exactly how is there
either "a high degree of accountability" or "a significant degree of control"
on the part of the post office?
 
> The (unfortunately predictable) development of abuses of this service are 
> requiring development of practises that tighten things up.  The challenge is to 
> do this in a way that does not create some sort of centralized control.  

Or a multitude of "railroad barons" each with incompatible standards and
refusing to cooperate with others (in which case centralized control would
be preferable and desirable in the community interest).

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Jun 2005 11:30:02 -0700 (PDT)

> the ID-Checklist clearly states:

That's most unfortunate. What do we need to do to get this silly and
counterproductive requirement removed?

> if some action is or is not required.

The problem is that requiring such a section creates no such assurance. I've
seen any number of documents with IANA considerations that initially failed to
list all the considerations. And given past experience with "security
considerations: none" sections, there is no reason to believe that requiring
such a section will actually result in IANA considerations being properly
called out. In fact I'd say there's a good chance it will cause obscure
considerations to be missed.

Like it or not, boilerplate is not now and never will be a useful subsitute for
careful review. And as the pile of useless crap we require gets ever-larger it
gets harder, not easier, to get that review.

> IETF Secretariat apparently doesn't enforce that part of the ID-Checklist

On the contrary, it is fortunate they are not enforcing it.

> RFCs.  But Internet-Drafts are REQUIRED to have them.

Making it one more disincentive for contributors. This really needs to stop.

				Ned

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 8 Jun 2005 14:42:34 -0400

On Jun 8, 2005, at 14:23, Jeffrey Hutzelman wrote:
> Aside from making sure the proper boilerplate is included in documents 
> it publishes (which it pretty much has to do for legal reasons), the 
> IETF secretariat generally does not check submitted I-D's for 
> conformance with standards for submissions.  To do otherwise would not 
> only be expensive and slow down the I-D submission process 
> considerably; it would also interfere with the IETF process.

True... but something like "has an IANA Considerations section" is easy 
to check, and easy for the author to implement, even if it's just 
starting with an I-D template that says "to be determined" or "author 
should fill this in" or "author promises to take the RFC Editor out for 
a pancake breakfast if this text is submitted for publication as an 
RFC".

>   Internet-Drafts are works-in-progress; it is not necessary or even 
> desirable that every I-D be in a form suitable for submission to the 
> IESG before being added to the repository.

Also true.  But there is a different requirements list for I-Ds than 
for RFCs.  If something shouldn't be required for I-D submission, then 
it shouldn't be on that list.  Evidently someone thought that IANA 
Considerations should be in every I-D submission.  Now, perhaps the 
requirements list should be changed.  I'm inclined to say not, in this 
case; the "null" IANA Considerations section (as opposed to not having 
one, or the pancake-breakfast template above) does imply that the 
author has actually thought about it and concluded that IANA doesn't 
need to do anything.

Ken

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jun 2005 11:06:52 +0200

Ned Freed wrote:
...
> counterproductive requirement removed?

Enough context has been removed that I don't know quite what you're
objecting to, but the intent of the I-D checklist is to avoid
the IESG having to kick back documents for trivia, so you can
argue about what should or shouldn't be in the checklist, but
you surely can't argue against it being used for its intended
purpose.

>>if some action is or is not required.

There is another purpose IMHO: ensure that future readers (implementers
and deployers of the technology) know whether they need to deal with
any IANA registration issues. For this reason, I have a strongly held
opinion that null IANA Considerations sections should *not* be removed.

> list all the considerations.

Yes indeed, and I see a lot of IESG DISCUSSes on exactly this point.

> And given past experience with "security

I think experience shows otherwise: the fact that reviewers, including the
IESG, are paying increasing attention to this section is in fact catching
omissions.

> careful review.

I agree

> And as the pile of useless crap we require gets ever-larger it

I disagree. Actually, the mandatory presence of this section *triggers*
review (see above comment).

>>IETF Secretariat apparently doesn't enforce that part of the ID-Checklist

The ID-Nits tool checks it and the future automated submission tool will
check a lot more than the Secretariat can do manually.

    Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 09 Jun 2005 09:27:00 +0200

Dear Bruce,
you know what? I think it would be great to write a IANA obligations RFC. 
It would say that the IANA MUST maintain a list of all the obligations RFC 
authors should respect when writting the IANA considerations, and to 
document whatever additional information IANA may need (for example if a 
DoS might result from a possible misuse of what they ask and the proposed 
solutions).
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Jun 2005 15:38:05 +0200

Please see RFC 2434 = BCP 26

    Brian

JFC (Jefsey) Morfin wrote:
> Dear Bruce,
> you know what? I think it would be great to write a IANA obligations 
> RFC. It would say that the IANA MUST maintain a list of all the 
> obligations RFC authors should respect when writting the IANA 
> considerations, and to document whatever additional information IANA may 
> need (for example if a DoS might result from a possible misuse of what 
> they ask and the proposed solutions).
> jfc
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Jun 2005 10:22:54 -0400

Brian,

We agree about the desirability of making sure than some things
are explicitly documented and explicitly part of what gets
reviewed.  But I continue to believe, as I have believed for
years, that adding more and more mandatory material to RFCs or
I-Ds is not the best solution to that particular problem.  

Perhaps, in line with the PROTO effort (and maybe the ISD
discussion), it is time to revisit the other approach: rather
than cluttering up I-Ds with materials that can be filled out
pro-forma and that the RFC Editor may then remove (or not),
migrate at least some of these procedural requirements
associated with protocol specifications from the I-D to a
"submission checklist" that a WG or individual would provide to
the IESG as part of the request for Last Call and approval
action.   That document could contain, e.g., an explicit
statement as to whether the WG had examined IANA issues and
decided that there were none, rather than just providing pro
forma text or boilerplate, as well as draft protocol action
statements, etc.   The IESG gets more information, in clearer
form, and we don't end up with a choice between information
getting lost and more clutter in RFCs.

Of course, if one were doing ISDs, that text and anything else
that relates to the process and context for approving a
standard, rather than information key to the protocol
specification itself, could, when the spec was approved, be
reasonably be transposed into the ISD.

    john

--On Thursday, 09 June, 2005 11:06 +0200 Brian E Carpenter
<[email-masked]> wrote:

> Ned Freed wrote:
> ...
>>> The IETF Internet-Drafts page notes that "All
>>> Internet-Drafts that are submitted to the IESG for
>>> consideration as RFCs must conform to the requirements
>>> specified in the I-D Checklist".  The current version of the
>>> ID-Checklist clearly states:
>> 
>> 
>> That's most unfortunate. What do we need to do to get this
>> silly and counterproductive requirement removed?
> 
>>> I believe the requirements exist to ensure that draft
>>> authors give due consideration to IANA Considerations and
>>> that IANA can readily determine if some action is or is not
>>> required.
> 
>> The problem is that requiring such a section creates no such
>> assurance. I've seen any number of documents with IANA
>> considerations that initially failed to list all the
>> considerations.
> 
>> considerations: none" sections, there is no reason to believe
>> that requiring such a section will actually result in IANA
>> considerations being properly called out. In fact I'd say
>> there's a good chance it will cause obscure considerations to
>> be missed.
> 
>> Like it or not, boilerplate is not now and never will be a
>> useful subsitute for careful review.
> 
> I agree
> 
>>> IETF Secretariat apparently doesn't enforce that part of the
>>> ID-Checklist rules.
>

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 09 Jun 2005 11:47:19 -0400

>From where I sat, the problem was trying to ensure that a WG thought 
about an issue.  Neither mandatory material nor checkoff boxes 
accomplish that, but I think the former is often more useful because 
material in an I-D is visible to the entire WG.  

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 09 Jun 2005 18:54:01 +0200

>Please see RFC 2434 = BCP 26

Dear Brian,
I was probably not clear enough. Bruce quoted RFCs, and others points 
postdate RFC 2434. Current http://www.iana.org site is not the best 
documentation site I saw. It said two things:

1. a IANA related obligations registry. Where obligations to IANA, authors, 
users, etc. would be registered and easily displayed.
2. in the IANA considerations to explicit the way IANA overload will be 
fought. This last point (with XML registries) is a point under 
consideration and of concern for those having to fund the IANA as ccTLDs. 
It might lead to make alternatives being considered earlier than advisable 
for good transition. For example a daily interruption of IANA registries 
for an hour or random drops calling for a recall of the requested page, a 
timer, a copyrigh response first, etc. could be ways to prevent 
applications designers to call on IANA XML files everytime they need one of 
their data.

jfc

>>It would say that the IANA MUST maintain a list of all the obligations 
>>RFC authors should respect when writting the IANA considerations, and to

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 9 Jun 2005 13:32:55 -0400

> > the ID-Checklist clearly states:

[IANA Considerations section is REQUIRED]

> counterproductive requirement removed?

(pessimist hat on)
Nothing. Just ignore it; everybody does. The rule, such as it is, isn't
enforced.
(pessimist hat off)
I think "counterproductive" is at best quite a stretch.
 
> The problem is that requiring such a section creates no such assurance.

Of course.  But it does encourage thought (both by authors/editors and
reviewers).  Surely you're not suggesting that authors, editors, and
reviewers should ignore IANA considerations.

The problem (N.B. pessimist hat is off) is that we now have the worst
of all possible situations:
 o The rule exists in some random documents buried on some web
   sites, and the documents have no status as RFC or BCP; as far as
   I can tell there are no immediate plans to change that (one of the
   documents is an Internet-Draft which is now nearly 11 months old)
 o BCP 14 language is used with a normative reference to BCP 14,
   implying that this is a matter taken seriously; the document
   using that language comes from the IESG, but as noted above has no
   standing as BCP
 o Although it is expressed as REQUIRED, and:
   i. it is referenced either directly or indirectly from several places
   ii. there exist tools (e.g. idnits) which quickly and accurately
       determines if the requirement is met
   the rule is not enforced (or is at best selectively enforced)
These things are at odds (e.g. there is little point in a requirement,
expressed in strong terms (but in somewhat obscure documents with no
official standing) which is ignored), yet are self-reinforcing (if the
rule isn't enforced, it's hardly surprising that authors and editors
ignore it, nor is it surprising that some IETFers seem to be unaware
of requirements in documents that have no standing and are hidden in
obscure places).

If the IESG really doesn't care, it could indicate so consistently
by:
1. reissuing the guidelines without BCP 14 language and burying the
   document deeper on the IETF web site; keep the document unofficial,
   make random changes at random times, and remove all version indications
   (or further obscure those indications by making the gray text on the
   gray background in the current HTML-only document even lower contrast
   and smaller size, and/or use an uglier markup language)
2. keep the 2223bis draft in limbo for a few more years and/or ask the
   RFC Editor to elide the part about a null IANA Considerations
   section

[obviously, some of the comments immediately above are tongue-in-cheek]

Conversely, if the IESG does regard the matter as important, it could:
1. direct the IETF Secretariat to enforce the rule (given the fact that
   idnits already checks for it, as well as checking for IPR boilerplate
   issues -- which the Secretariat does enforce with an iron fist -- I
   don't buy the argument that checking would impose an inordinate cost.
   In fact I suspect that the incremental cost would be smaller than that
   of any instrumentation that might be applied to measure that cost)
2. publish the guidelines as BCP and move forward on the 2223bis draft

---

From: Ned Freed <[email-masked]>
Date: Thu, 09 Jun 2005 12:02:16 -0700 (PDT)

> material in an I-D is visible to the entire WG.

I disagree completely and think you have this exactly backwards. Mandatory
material would only help if people actually think about what goes in it - which
they don't. Rather, they think about it as "another something we have to do to
get past the IESG" and deal with it by spending as little time on it as
possible.

Even worse, the presence of a section that says "these are all the IANA
considerations" or "there are no IANA considerations here" is likely to cause
reviewers to assume that someone has already checked for IANA actions. This
will lead to more omissions, not less.

And in fact there has already been at least one example of this happening. The
document draft-ietf-lemonade-mms-mapping-04.txt is now in the RFC Editor's
queue. It's IANA considerations section says "no IANA actions". Alas, the
document defines any number of new header fields that need to be placed in the
appropriate header regsitry.

That IANA considerations section sure helped a lot, didn't it?

Like it or not, careful reviews and review checklists, while quited flawed in
their own right, are the best tool we have. When I was on the IESG I had my own
private review checklist; it was the only thing I found that worked.

				Ned

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 09 Jun 2005 15:22:33 -0400

>get past the IESG" and deal with it by spending as little time on it as

Sure -- I saw a lot of that when I was on the IESG.  Too often, I would 
say "in your Security Considerations section, you need to think about 
X, Y, and Z" -- and I'd get back a new document saying "think about X, 
Y, and Z".

>That IANA considerations section sure helped a lot, didn't it?

You can lead a horse to water....

I agree -- there are no panaceas here.  It's a question of what will 
help the most, not what will solve the problem.
>private review checklist; it was the only thing I found that worked.

Such reviews are certainly necessary.  The question is this: what 
policy is most likely to reduce the incidence of such things?  We'll 
never eliminate it.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jun 2005 11:30:18 +0200

Ned Freed wrote:
...
> appropriate header regsitry.

And did you send us that as a Last Call comment, with specifics?

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jun 2005 11:36:26 +0200

OK, we can take these comments as inout for the revision of 2434.

     Brian

JFC (Jefsey) Morfin wrote:
> 1. a IANA related obligations registry. Where obligations to IANA, 
> authors, users, etc. would be registered and easily displayed.
> consideration and of concern for those having to fund the IANA as 
> ccTLDs. It might lead to make alternatives being considered earlier than 
> advisable for good transition. For example a daily interruption of IANA 
> registries for an hour or random drops calling for a recall of the 
> requested page, a timer, a copyrigh response first, etc. could be ways 
> to prevent applications designers to call on IANA XML files everytime 
> they need one of their data.
> 
> jfc
> 
>>    Brian
>>
>>
>>> considerations, and to document whatever additional information IANA 
>>> may need (for example if a DoS might result from a possible misuse of 
>>> what they ask and the proposed solutions).
>>> jfc
>>>> ID-Checklist

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Jun 2005 11:46:03 +0200

It's a matter of taste whether http://www.ietf.org/ID-Checklist.html
is obscure or not, but it is quite explicit and cites RFC 2434
which is BCP 26.

BCP 26 says, among other things:

    All future RFCs that either explicitly or implicitly rely on the IANA
    to register or otherwise manage assignments MUST provide guidelines
    for managing the name space.

The IESG operates on this basis. It's true that it isn't enforced at
I-D submission time; but it is enforced in IESG review.

        Brian

---

From: Bill Fenner <[email-masked]>
Date: Fri, 10 Jun 2005 07:25:10 -0400

On 6/9/05, Bruce Lilly <[email-masked]> wrote:
> 1. direct the IETF Secretariat to enforce the rule

Bruce,

  ID-Checklist is only for I-Ds that are submitted to the IESG for
publication.  It's not the cost of checking that is a problem, rather,
it's useful to allow earlier drafts of I-Ds to not be fully fleshed
out (thus they're .. well .. drafts?)

  Bill

---

From: Thomas Narten <[email-masked]>
Date: Fri, 10 Jun 2005 07:35:20 -0400

Ned Freed <[email-masked]> writes:

> Like it or not, careful reviews and review checklists, while quited
> flawed in their own right, are the best tool we have. When I was on
> the IESG I had my own private review checklist; it was the only
> thing I found that worked.

I agree careful reviews are necessary. What I find surprising is your
logic, which seems to say:

  IANA considerations sections in IDs are not sufficient, therefore
  they are useless (or worse).

Is that really what you are advocating? What exactly is it that you
think should be done (in addition to careful reviews) that would help
reduce the odds that the careful review find issues with the IANA
instructions (or lack thereof)?

Note that having IC sections is all about improving the odds that they
contain the Right Thing before the document is approved by the
IESG. In my mind that means:

1) IANA reviews an (essentially) final version, to be sure what it
   says is consistent with their understanding of what needs to be
   carried out. But, IANA does this review during Last Call. Thus, the
   IC section really needs to be complete _before_ the full IETF
   review.

2) Well, the Shepherding AD can do the "careful review" during the AD
   review phase, but there is already plenty of pressure to skimp on
   the AD review in order to send a document the WG says is finished
   to IETF LC ASAP. I.e., to get the IETF LC started and "fix any
   issues that come up later". Plus, in my experience, plenty of IC
   issues are caught by ADs other than the shepherding AD. So relying
   on them to catch all such issues is far from ideal.

3) Voila, have a checklist item that alerts WGs to things they should
   take steps to make sure their documents have already addressed
   prior to advancing a document out of the WG.

Thomas

---

From: Ned Freed <[email-masked]>
Date: Fri, 10 Jun 2005 08:50:40 -0700 (PDT)

>   they are useless (or worse).

I have never said or even implied that.

> Is that really what you are advocating?

Of course not.

> What exactly is it that you

Simple: The requirement that an  IANA considerations section be included in RFC
not containing any IANA actions needs to be dropped. I have been extremely
clear ahout this.

> IESG. In my mind that means:

That may be the intent, but the effect is to substitute boilerplate for
review, which won't improve specification quality at all.

>    prior to advancing a document out of the WG.

This is all very logical, but we're dealing with people here, not perfect
logical systems. 

				Ned

---

From: Pekka Savola <[email-masked]>
Date: Fri, 10 Jun 2005 19:38:12 +0300 (EEST)

> not containing any IANA actions needs to be dropped. I have been extremely

It's good, because this is already the case.  Even if you're required 
to add a "null" IANA considerations section in the internet-drafts 
when being sent to the IESG, the RFC-editor removes the IANA 
considerations section completely if it doesn't have any real content.

Anything else?

-- 
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: John C Klensin <[email-masked]>
Date: Fri, 10 Jun 2005 12:48:42 -0400

Thomas,

I won't attempt to speak for Ned, but I think there is some
confusion here about what I, at least, intended by "checklist".
It is not, for me, tied up with the form of the list or what
content it has, but goes back to questions of WG
responsibilities (not just authority).   The issue isn't whether
something is listed somewhere, it is who, if anyone, is taking
formal responsibility for asserting that the list has been
checked and is correct.

When I've talked about a "submission checklist", it is less
"something the WG ought to check before sending something to the
IESG" or "something the IESG checks after receiving something".
It is, symmetrically with the WG Charter, an formal assertion by
the WG and its Chair(s) that things have been reviewed, checked,
and are correct... an assertion on which they are willing to
commit their reputations (at least).  

And that is what has been missing from the picture.  It is
trivial to check whether an IANA Considerations section (or a
Security Considerations section, or an Internationalization
Considerations one, or any of the other things that have been
asked for) is present.  But, if it says "none", or contains a
collection of words that are irrelevant to the document at hand,
checking  becomes very hard --independent of whether the words
are a section of an I-D or appear on a submission document
somewhere.   

IMO, the key to making progress in this area is not to expect
omniscience from the IESG, it is getting the WG Chair to
formally sign off that the section has been seriously reviewed
by the WG and found to be complete.   I'd expect that the
responsibility for making that sign off would, itself and by
making the responsibilities clear, improve things.  I'd also
expect that, if problems are later found that the WG should have
detected and didn't, or would have found had there been a
meaningful review but that review didn't really occur, that the
relevant AD would deal with that situation somewhat more sternly
than, e.g., a WG missing a benchmark deadline: once the
assertion is made that the review occurred and was diligent, a
bad or no review is a sin of commission, not omission, and,
absent external circumstances, I'd expect intense review of
charters, changes of chairs, even closing of the relevant WG...
or having the community hold the AD formally responsible for not
taking those actions.

If that didn't help, we would be in very bad shape indeed.

   john

--On Friday, 10 June, 2005 07:35 -0400 Thomas Narten
<[email-masked]> wrote:

>> Like it or not, careful reviews and review checklists, while
>> quited flawed in their own right, are the best tool we have.
>> When I was on the IESG I had my own private review checklist;
>> it was the only thing I found that worked.
> 
> I agree careful reviews are necessary. What I find surprising
> is your logic, which seems to say:
> 
>   IANA considerations sections in IDs are not sufficient,
> therefore   they are useless (or worse).
> 
> Is that really what you are advocating? What exactly is it
> that you think should be done (in addition to careful reviews)
> that would help reduce the odds that the careful review find
> issues with the IANA instructions (or lack thereof)?
> 
> Note that having IC sections is all about improving the odds
> that they contain the Right Thing before the document is
> approved by the IESG. In my mind that means:
> 
> 1) IANA reviews an (essentially) final version, to be sure
> what it    says is consistent with their understanding of what
> needs to be    carried out. But, IANA does this review during
> Last Call. Thus, the    IC section really needs to be complete
> _before_ the full IETF    review.
> 
> 2) Well, the Shepherding AD can do the "careful review" during
> the AD    review phase, but there is already plenty of
> pressure to skimp on    the AD review in order to send a
> document the WG says is finished    to IETF LC ASAP. I.e., to
> get the IETF LC started and "fix any    issues that come up
> later". Plus, in my experience, plenty of IC    issues are
> caught by ADs other than the shepherding AD. So relying    on
> them to catch all such issues is far from ideal.
> 
> 3) Voila, have a checklist item that alerts WGs to things they
> should    take steps to make sure their documents have already
> addressed    prior to advancing a document out of the WG.
> 
> Thomas

---

From: Ned Freed <[email-masked]>
Date: Fri, 10 Jun 2005 11:15:05 -0700 (PDT)

> Anything else?

It is the requirement that Internet Drafts always contain IANA 
considerations sections that has to go. What the RFC Editor does after document
approval is not the issue here.

				Ned

---

From: Fred Baker <[email-masked]>
Date: Sun, 12 Jun 2005 22:16:30 -0400

from my very humble perspective, it is actually useful to test a -00 
draft. The more revisions a draft goes through, the more reticent and 
author becomes to change it. Getting the test done early makes that job 
easier.

On Jun 10, 2005, at 7:25 AM, Bill Fenner wrote:

> This message was passed through [email-masked], 
> which is a sublist of [email-masked]. Not all messages are passed. 
> Decisions on what to pass are made solely by IETF_CENSORED ML 
> Administrator ([email-masked]).
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Jun 2005 10:03:52 +0200

Ned Freed wrote:
> considerations sections that has to go.

Ned, you have not produced any argument for this position, and since
the absence of such a section does not imply the absence of IANA
considerations, your logic continues to escape me.

The argument for the mandatory presence of such a section is that
it increases the probability that any IANA considerations have been
identified.

> What the RFC Editor does after 
> document

Not for you, maybe, but it is for me.

    Brian

---

From: Ned Freed <[email-masked]>
Date: Mon, 13 Jun 2005 07:33:39 -0700 (PDT)

> considerations, your logic continues to escape me.

Repeating for about the fourth time...

The argument against it is that requiring the section in the absence of actual
IANA considerations simply adds to the amount of required stuff we have in our
documents that serves no real purpose. We have way too much of this junk
already and attempts to require more need to be resisted.

The only reason to have it would as an indicator that a check for IANA
considerations was done and none were found. But the problem with that is that
there's no way to distinguish between a careful review leading to the prduction
of "no considerations" text and the text being added with little if any review
just "to make the IESG happy". And we already have at least one example where
this appears to have happened.

> it increases the probability that any IANA considerations have been

I disagree. I don't think it increases the probability much if at all, and in 
fact may actually decrease it. And even if it did increase the probability
slightly, the benefit of that increase needs to be weighed against the cost,
and I don't think it measures up.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 09:17:56 -0700

>  Repeating for about the fourth time...

Here's my own take:

It is empty bureaucracy.  It is form, without content.  It is additional 
effort, with no benefit.

It is reasonable and necessary to require that documents contain 
important considerations.  This is not accomplished by having pro forma 
sections lacking content.  

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Bob Hinden <[email-masked]>
Date: Mon, 13 Jun 2005 15:28:52 -0700

Dave,

>sections lacking content.

I am not a big fan of a lot of the current boiler plate.   I would be happy 
if I could submit drafts with <INSERT IETF STANDARD FIXED BOILERPLATE> and 
have it done automatically instead of having to figure out what the boiler 
plate text to add is.

I think the the IANA Considerations section is different as it's contents 
vary (unlike things like the copyright statement).  The argument to 
requiring it even if there aren't any required IANA actions is similar to 
why protocols with NACKs don't work.  The IANA needs to know in a positive 
manner that the author considered it.  The lack of an IANA considerations 
section is ambiguous.

Bob

---

From: Ned Freed <[email-masked]>
Date: Mon, 13 Jun 2005 15:33:41 -0700 (PDT)

> manner that the author considered it.  The lack of an IANA considerations

Unfortunately so is the presence of an empty IANA considerations section - you
cannot tell the difference between such a section that was arrived as as a
result of careful review of the draft and one that was simply created as a form
of boilerplate.

And that's why the costs of requiring null IANA consideratiosn sections
outweigh the benefits.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Mon, 13 Jun 2005 15:40:49 -0700

Bob,

>  The IANA needs to know in a positive manner that the author considered it.
>  The lack of an IANA considerations section is ambiguous.

So is the presence of an empty or pro forma one.

Let's all recall the wonderfully astute content that used to be present 
in the pro forma "security considerations" sections... until the IESG 
pressed to have them to be the result of serious consideration and to 
document the results diligently.

When there are, in fact, IANA issues, then of course they need to be 
documented, well and thoroughly.  

There is nothing in having a pro forma section that assures this -- in 
fact, pro forma performance tends to reduce sensitivity to situations 
requiring more effort.  All it assures is mindless ritual and extra 
effort.

  d/
  ---
  Dave Crocker

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Jun 2005 20:25:38 -0400

Better yet would be late binding: <INSERT LATEST IETF STANDARD FIXED
BOILERPLATE>.

- Ralph

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 14 Jun 2005 18:09:43 -0400

> Better yet would be late binding: <INSERT LATEST IETF STANDARD FIXED

Has anyone actually _read_ the boilerplate in drafts you are submitting?
Much of that text affects what rights you have, what rights you grant to 
the IETF, and what responsibilities you have.  It's not just a placeholder; 
it applies at the time of submission of an I-D, not just at RFC publication 
time.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 16 Jun 2005 15:28:25 +0200

Jeffrey Hutzelman wrote:
> 
> 
> On Monday, June 13, 2005 08:25:38 PM -0400 Ralph Droms 
> <[email-masked]> wrote:
> 
> the IETF, and what responsibilities you have.  It's not just a 
> placeholder; it applies at the time of submission of an I-D, not just at 
> RFC publication time.

Correct, and that is why the "Note Well" text is in your face at various
points on the IETF site. Those legal sounding words do actually mean
something.

xml2rfc saves you the bother of manually inserting the boilerplate, of course.
It's more or less late binding.

    Brian

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Jun 2005 22:02:41 -0400

>>>>> "Ned" == Ned Freed <[email-masked]> writes:

    >> Dave, >Here's my own take:
    >> >
    >> >It is empty bureaucracy.  It is form, without content.  It is
    >> additional >effort, with no benefit.
    >> >
    >> >It is reasonable and necessary to require that documents
    >> contain >important considerations.  This is not accomplished by
    >> having pro forma >sections lacking content.

    >> I am not a big fan of a lot of the current boiler plate.  I
    >> would be happy if I could submit drafts with <INSERT IETF
    >> STANDARD FIXED BOILERPLATE> and have it done automatically
    >> instead of having to figure out what the boiler plate text to
    >> add is.

    >> I think the the IANA Considerations section is different as
    >> it's contents vary (unlike things like the copyright
    >> statement).  The argument to requiring it even if there aren't
    >> any required IANA actions is similar to why protocols with
    >> NACKs don't work.  The IANA needs to know in a positive manner
    >> that the author considered it.  The lack of an IANA
    >> considerations section is ambiguous.

    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.  Thus
as an individual I support the requirement.  I do not have rigorous
data to support my assertion.

That said, I agree that if there is a consensus to drop the
requirement we should do so.

--Sam

---

From: Ned Freed <[email-masked]>
Date: Thu, 23 Jun 2005 09:22:17 -0700 (PDT)

> 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

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 23 Jun 2005 09:33:32 -0700

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

For anyone who was sleeping during the relevant Psych 101 lecture, this is 
called the Hawthorne effect.  Doing anything at all gets folk's attention.  
Whether the thing, itself, has a real effect is a very separate issue.

The IANA Considerations form requirement creates attention on the matter of 
IANA.  But that does not mean that it carries any long-term focus on real IANA 
issues, any more than the original, vacuous requirement for a Security 
Considerations section resulted in good security considerations.

What improved the security considerations work was requiring that it be real.

  d/
  ---
  Dave Crocker

---

From: Ned Freed <[email-masked]>
Date: Thu, 23 Jun 2005 09:45:53 -0700 (PDT)

> called the Hawthorne effect.

Damn. I knew there was a famous study that identified this effect, but I
couldn't remember the name.

  Doing anything at all gets folk's attention.

> What improved the security considerations work was requiring that it be real.

Which in turn works because there are always security considerations - the
closest thing to valid empty security considerations section  we have is one
that says "this entire document is about security". A section that simply says
"there are no security considerations here" is invalid on its face and
indicates insufficient review has been done.

The same isn't true of IANA considerations. It is perfectly valid for a
document not to have any, and in fact common. And that completely changes the
dynamics of the situation.

				Ned

---

From: Steve Crocker <[email-masked]>
Date: Thu, 23 Jun 2005 13:03:54 -0400

>   Doing anything at all gets folk's attention.

The name "Hawthorne Effect" comes from some early work (1927-1932) on  
organizational measurement done at the Western Electric plant in  
Hawthorne, Illinois, where management tried to determine optimum  
levels of factory-floor lighting. Because the employees knew about  
the study, they responded to each adjustment in light level by  
increasing productivity.

Steve

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 23 Jun 2005 13:45:45 -0400

On Jun 23, 2005, at 13:03, Steve Crocker wrote:
> levels of factory-floor lighting. Because the employees knew about the 
> study, they responded to each adjustment in light level by increasing 
> productivity.

So maybe we should change around the set of required sections every 
couple of years just to keep people's attention? :-)

Ken

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 25 Jun 2005 23:48:00 +0200

> couple of years just to keep people's attention? :-)

Thanks for the suggestion. Shall we write it up as a BCP? ;-)

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 26 Jun 2005 00:04:25 +0200

> What improved the security considerations work was requiring that it be real.

Indeed. And by analogy, that's why we need to update RFC 2434, which is
almost 7 years old.

     Brian

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 26 Jun 2005 01:27:38 +0200

>Indeed. And by analogy, that's why we need to update RFC 2434, which is

I suggest that all the IANA parts of RFCs are compiled in a parallel 
document, may be with a reference number to be discussed for a IANA logical 
classification. They would make the IANA "permanent orders" everyone could 
consult. It would probably help standarding the IANA ways what would be 
usueful to everyone - probably showing initially the complexity of the IANA 
task to translate the IANA consideration parts as they are often written. 
But it would probably improve quickly if a IANA Registry management 
tool/system resulted from it. Maybe in relation with ISO 11179?
jfc