On Dec 8, 2011, at 11:51 AM, Russ Housley 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.
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.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf