Re: Errata against RFC 5226 rejected

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

 



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


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