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