Re: Errata against RFC 5226 rejected

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 08/12/2011 19:18, Barry Leiba wrote:
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

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
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]