Subject: Errata against RFC 5226 rejected

From: Russ Housley <[email-masked]>
Date: Thu, 8 Dec 2011 13:51:02 -0500

Errata 2684 was entered against RFC 5226, "Guidelines for Writing an IANA Considerations Section in RFCs".  After discussion with one of the RFC authors and IANA staff, I rejected the errata.

The errata author is saying that in many registries, there are no "unreserved" values.  For registries where there are a finite number of entries possible, the "unreserved" has a clear meaning.  For registries with an unbounded number of potential entries (such as media-types), the errata author is claiming that the "unreserved" label does not make sense.

I'd like to know what others think about this errata.

Russ

---

From: Thomas Narten <[email-masked]>
Date: Thu, 08 Dec 2011 14:02:04 -0500

As background, the actual errata is at
http://www.rfc-editor.org/errata_search.php?rfc=5226&eid=2715

In it Julian suggests (wdiff shows the proposed text changes):

 5) Initial assignments and reservations.  Clear instructions
        [-should-] {+SHALL+} be provided to identify any initial
        assignments or registrations.  In addition, any ranges that
        are {+"Unassigned" (only for those registries that have a
        bounded size),+} to be [-reserved-] {+"Reserved", used+} for
        "Private Use", [-"Reserved", "Unassigned",-]
        {+"Experimentation",+} etc. [-should-] {+SHALL+} be clearly
        indicated.

I don't see the need for this. "should" seems good enough for
me. Also, the wording "any ranges that are ... etc."  implies to me
that the list provided are examples and if a category doesn't apply,
you don't include it.

In other words, I don't see a problem with the existing text that
warrants bothering with an errata.

But maybe I'm missing what the problem is.

Russ Housley <[email-masked]> writes:

> Errata 2684 was entered against RFC 5226, "Guidelines for Writing an
> IANA Considerations Section in RFCs".  After discussion with one of
> the RFC authors and IANA staff, I rejected the errata.

> The errata author is saying that in many registries, there are no
> "unreserved" values.  For registries where there are a finite number
> of entries possible, the "unreserved" has a clear meaning.  For
> registries with an unbounded number of potential entries (such as
> media-types), the errata author is claiming that the "unreserved"
> label does not make sense.

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 8 Dec 2011 11:05:20 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Narten
> Sent: Thursday, December 08, 2011 11:02 AM
> To: Russ Housley
> Cc: IETF; [email-masked]
> Subject: Re: Errata against RFC 5226 rejected
> 
> I don't see the need for this. "should" seems good enough for me. Also,
> the wording "any ranges that are ... etc."  implies to me that the list
> provided are examples and if a category doesn't apply, you don't
> include it.
> 

+1.

-MSK

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 8 Dec 2011 13:12:24 -0600

I agree, and I think the original text is a better description of the requirement.

Cheers,
-Benson

---

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Dec 2011 14:18:04 -0500

> Errata 2684 was entered against RFC 5226, "Guidelines for Writing an IANA
> Considerations Section in RFCs".  After discussion with one of the RFC authors
> and IANA staff, I rejected the errata.
>
> The errata author is saying that in many registries, there are no "unreserved"
> values.  For registries where there are a finite number of entries possible, the
> "unreserved" has a clear meaning.  For registries with an unbounded number
> of potential entries (such as media-types), the errata author is claiming that the
> "unreserved" label does not make sense.

First, Thomas, in his response, is addressing the wrong errata report.
 2715 is a report submitted by Mykyta that makes reference to Julian's
report (2684).  The latter is the one that Russ has rejected.  The
former is still in "reported" status.  I agree with Thomas that the
"SHALL" changes in 2715 are unnecessary, but that's not what Russ is
asking about.

Russ, you talk about "unreserved", but never mention the word that
Julian is asking to have removed, "unassigned", which is not the same
thing.  Do registries explicitly need to *list* the entries that are
*unassigned*?  As he says, this makes no sense for registries with
unlimited (or even very many) possible entries.  Even for those with a
small number, the value is questionable.  For example, suppose we had
a registry of three-bit unsigned integer values, and we said the
initial registry looked like this:

0 - reserved
1 - blue
2 - red
3 - purple
4 - private use
5 - reserved
6 - unassigned
7 - unassigned

That would indicate that 6 and 7 are available for future assignment.
But so would this:

0 - reserved
1 - blue
2 - red
3 - purple
4 - private use
5 - reserved

In the case of this hypothetical registry, with eight possible values,
there might be some use in explicitly saying that 6 and 7 are
currently unassigned.  But even extending this a little, if it were a
four-bit integer field we'd now be listing ten values as "unassigned".
 Make it six bits, and it's just plain silly.  Julian's right about
that.

That said, the best I can see for this report is "held for document
update."  It's one of those things that's not worth spending time on,
and, as Thomas says, the "should" language makes it fine as it is.

Barry

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Dec 2011 12:19:32 -0700

> and, as Thomas says, the "should" language makes it fine as it is.

+1. There's work happening in the background on 5226bis. Let those
authors sort it out. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "John Levine" <[email-masked]>
Date: 8 Dec 2011 19:26:48 -0000

>warrants bothering with an errata.

If IANA isn't able to figure out what they need to do under the
current wording, we have problems that no amount of word twiddling can
fix.

R's,
John

PS: The last time I checked, it wasn't a problem.

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Dec 2011 12:54:31 -0700

> I'd like to know what others think about this errata.

To my mind, a potential value in a registry has three possible states:
  - it might already be defined (TCP is IP Protocol 6)
  - it might be available for future definition (http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml says that the numbers 143-252 are unassigned)
  - it might be set aside to never be defined (ibid says that 255 is "reserved").

RFC 6014 uses the term "unreserved" to refer to the fact that a potential value has not been assigned and has not been "reserved":
   IANA has marked values 123 through 251 as "Reserved".  The registry
   notes that this reservation is made in RFC 6014 (this RFC) so that
   when most of the unreserved values are taken, future users and IANA
   will have a pointer to where the reservation originated and its
   purpose.

In the actual registry, at IANA, these values are listed as "unassigned".

To my small mind, "unreserved" is an alternate spelling of "unassigned". I don't see a problem with a registry having values that might be defined after the registry has been created. One could argue that the term is unfortunate in that we normally use a different one, but the term has meaning. The creators of the registry didn't assign a meaning to the value and didn't preclude use of an otherwise valid value. It is available for future definition.

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Dec 2011 16:42:49 -0500

--On Thursday, December 08, 2011 14:02 -0500 Thomas Narten
<[email-masked]> wrote:

>...
> me. Also, the wording "any ranges that are ... etc."  implies
> to me that the list provided are examples and if a category
> doesn't apply, you don't include it.
> 
> In other words, I don't see a problem with the existing text
> that warrants bothering with an errata.
> 

Agreed, and let me go a half-step further.  This sort of
suggested change would be relevant iff 5226 were a rigid,
normative, spec from which people needed to select an enumerated
option and use it without variation.   While people sometimes
confuse it with such a spec, it isn't, has never been, and we
would be, IMO, doing ourselves a serious disservice by turning
it into one.   As long as that is the case, the level of
precision tuning implied by the proposed erratum isn't so much
wrong as it is irrelevant.

   john

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 08 Dec 2011 22:58:31 +0000

> and, as Thomas says, the "should" language makes it fine as it is.
In a small registry like this, it is useful to have something in the
box in the table that makes it less likely that the value will be 
squatted on.

In the above example it is clearer in the 0..7 case that there are only
two free values and I will need a real good use case.

In the 0..5 case, someone might be more tempted to say, they are only
using up to 5 I will take 6 and hope no one notices.

Stewart

---

From: Barry Leiba <[email-masked]>
Date: Thu, 8 Dec 2011 21:39:03 -0500

> box in the table that makes it less likely that the value will be squatted
> on.
>

Fair point, and all the more reason to reject the errata report.

Barry

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 09 Dec 2011 10:30:19 +0000

> I'd like to know what others think about this errata.

The text is in an etc sequence, and in some cases "unreserved" may be 
appropriate, although some other notation may be appropriate and the 
text makes it clear that a term that is appropriate to the registry may 
be used.

Stewart