Subject: IANA Considerations

From: Bruce Lilly <[email-masked]>
Date: Wed, 6 Jul 2005 17:19:16 -0400

>  Date: 2005-07-06 16:16
>  From: Joe Touch <[email-masked]>

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

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.

and there's similar text for internationalization and security.

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

I wouldn't call it ad-hoc; it's part of an IESG-generated document on
the official IETF web site, and it also has been documented for quite
some time in the draft successor to RFC 2223 also known as
instructions2authors.

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

---

From: Fred Baker <[email-masked]>
Date: Wed, 6 Jul 2005 16:58:35 -0700

>    reviewed IANA considerations.

I like it. Consider my template to have changed.

---

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

> and there's similar text for internationalization and security.

This helps a lot less than you'd think. Lots of documents start out with no
IANA considerations. Then somewhere along the way they acquire some. The
tendency is going to be to change the text to say "no considerations" the very
first thing, and after that not bother to check. I suspect this is what happen
in the case of the MMS document, as a matter of fact - the header registry came
online between the time the document was first written and when it was
approved, which changed the situation from one where there weren't IANA
considerations to one where there were some.

People aren't machines, and it is mistake to expect them to behave like
machines.

				Ned

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Jul 2005 19:43:22 -0700

>> From: Joe Touch <[email-masked]>
...
> the official IETF web site,

Which, as far as process is concerned, isn't quite worth the disk space
it occupies ;-)

> and it also has been documented for quite

2223bis is still an ID. Until it's an RFC, this is just a *proposed*
change to process, and should be treated as such.

Joe

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 11:15:09 -0400

>  Date: 2005-07-06 14:43
>  From: Ned Freed <[email-masked]>

> > > 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 can't speak for others, but
1. if a draft has no IANA considerations section, idnits will so indicate
   (but see below), and that's a warning sign to check -- if idnits is run.
   Of course, one would expect conscientious authors/editors to
   a) abide by the guidelines (which is where the MUST include an IANA
      considerations section is specified)
   b) check against the I-D Checklist
   c) run idnits
   but obviously some authors/editors do not do so, and not all reviewers
   check vs. the Checklist and/or run idnits
2. if a draft has a "no IANA considerations" text, that certainly prompts
   this reviewer to check that statement for accuracy
At the moment (see below), that means that if there is no IANA
considerations section at all, idnits will flag that fact and if there
is such a section it will be reviewed; either way *seems* to result in
review of the draft w.r.t. IANA considerations.

> > I suppose. That said, if IANA considerations was *not* built into the
> > 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.

Unless I misunderstood your earlier comments, Ned, you suggested that the
requirement should be dropped.  Which would presumably mean that the idnits
check against that requirement would be dropped, and then there would be
the very real possibility, nay probability, that a draft with no IANA
considerations section would get through review even if there is something
that should be addressed by IANA.   And that is precisely why several
people have been advocating the rule, namely that it prompts review of
the issue (whether or not a particular author/editor adheres to the rule).

Indeed, although BCP 18 (RFC 2277, Frank) recommends an internationalization
considerations section, many documents do not include one even where
internationalization is an issue.  If the IETF feels that
internationalization is an important issue, a similar guideline prompting
authors/editors to include, and reviewers to review such a section might
be worth adding.  That is another matter, as is whether or not a published
RFC should contain a null internationalization considerations section.

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jul 2005 12:32:54 -0700 (PDT)

> requirement should be dropped.

I have never suggested that the requirment for an IANA considerations section
in documents that contain IANA considerations be dropped. Nor have I ever
suggested that review for IANA considerations be dropped. On the contrary, such
review is essential.

> Which would presumably mean that the idnits
> check against that requirement would be dropped,

On the contrary, it is important that automated tools warn that such sections
are missing. This warning should not prevent a document from being last called,
however.

> and then there would be
> that should be addressed by IANA.

Doesn't follow.

> And that is precisely why several

I disagree. I think it will over time come to have exactly the opposite effect.

> RFC should contain a null internationalization considerations section.

Sigh. More boilerplate BS, more unnecessary nonsense, more disincentives for
authors, less and lower quality review, and fewer and poorer documents.

This is absolutely the wrong path for us to be on.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 07 Jul 2005 13:30:10 -0700 (PDT)

> On Thu July 7 2005 15:32, Ned Freed wrote:

> > in documents that contain IANA considerations be dropped.

> The specific requirement is for the presence of a section in an I-D
> presented for publication as an RFC even in the case that there are
> no IANA actions.

> idnits generates a warning because there is a requirement for such a
> section.  I don't think it is reasonable to expect that an automated
> tool will be able to determine whether or not IANA actions would be
> required; it is easy to determine whether or not a section is
> present.

Which is all that should be done.

> If the unconditional requirement for a section goes away,
> I would expect the test to go away, or to at least require some
> non-default option to be specified to enable it.  Otherwise it will
> appear when there are in fact no IANA actions and then it will be
> treated as noise, like the fabled boy who cried "wolf".

Then by all means only issue the warning when in "let's find out what
needs to be reviewed mode".

> The only way to tell for sure is to let the experiment run its course.
 
Early indications are that it is already having the opposite effect.

> Not boilerplate, a reminder for authors/editors to consider the issue, and
> the remainder simply don't follow.

I disagree completely. And I believe that further disucssion of this
is pointless, so this will be my final note on the topic.

				Ned

---

From: Bruce Lilly <[email-masked]>
Date: Thu, 7 Jul 2005 16:08:56 -0400

present.  If the unconditional requirement for a section goes away,

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 08 Jul 2005 02:32:00 +0200

Commenting only on the idnits specific issue here:

> On Thu July 7 2005 15:32, Ned Freed wrote:

[...]

> required; it is easy to determine whether or not a section is

Right.

> treated as noise, like the fabled boy who cried "wolf".

Yes.  When http://www.ietf.org/ID-Checklist.html changes, idnits is
updated to match.  Otherwise, the tool would swiftly become useless.

	Henrik

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 08 Jul 2005 07:08:42 +0200

Bruce Lilly wrote:
 
> BCP 18 (RFC 2277, Frank) recommends an internationalization
> considerations section

Oh, that beast, a MUST UTF-8, not less.  Didn't make it into
RfC 3912, can I declare it "broken by design" and return to
RfC 954, please ?  It took me hours to find RfC 1032 for RFCI.

While we're at it, did you see draft-hoffman-utf8-rfcs-00.txt ?

OTOH Paul saw no problem to submit some I-Ds without a dummy
IANA section - and for gopher I even asked, after all there is
this IANA URI scheme registry, they might wish to update it.

> If the IETF feels that internationalization is an important
> issue, a similar guideline prompting authors/editors to
> include, and reviewers to review such a section might be
> worth adding.

Maybe.  OTOH it wouldn't be polite to write "SMTP error texts
are i-default US-ASCII, stupid, so that's what you put in an
SPF exp= explanation, for more I18N you could use a http URL".

Thinking about IANA doesn't upset me, it's rather harmless,
just one of the dozens of nits distributed in at least three
obscure texts, none of them an RfC.

The IPR boilerplate makes me mad, but unfortunately the authors
of xml2rfc didn't adopt my ipr="full<meep>" or ipr="fulleula"
proposals.  Insert four-letter word for <meep>.  At most three
lines pointing to a "creative commons BY SA license" should be
good enough for most I-Ds.
                           Bye, Frank

---

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

> that should be addressed by IANA.

Actually, the original reason for adding this was to avoid the
observed-in-practice behavior on IESG telechats:

 Q: Does this document have an IANA issues?
 A: um, I dunno, I can't remember now (since this is one of many
    documents)

A non-existant IANA Considerations section is taken as a flag that
maybe there are, but they haven't been called out. Sure, in some
cases, it's obvious there are no IANA issues, and the IESG would just
approve the document. But for any half-way long technical document,
making such determinations is non-trivial. Really!

So, if one leaves out the IANA considerations section, authors run the
risk that their document will be delayed in the IESG while
clarification is obtained about whether there are IANA issues.

I continue to be mystified by the overall thrust of much of this
thread when the implication of not having an IANA considerations
section is an increased probability of needless delay, something I
thought the community wanted to avoid.

Thomas