Subject: Q about use of "reserved" vs. "currently unused" in docs

From: "James M. Polk" <[email-masked]>
Date: Tue, 05 Jan 2010 13:12:34 -0600

TSVWG has been involved in a low level discussion that's not 
resolved, and perhaps can't be at this time - focusing on parameter 
values being IANA registered as either

	"reserved" i.e., not defined in the original creation of an IANA registry,
	and need to a document to allow the usage of a value

or

	"currently unused/unassigned"  i.e., not defined in the original
	creation of an IANA registry, with an added meaning similar to
	'these are up for grabs, without restriction on usage until
	documented'.

Is there a distinction within our documentation?

Do I have the definition correct based on existing documentation?

If no to both the above -- do we need to refine our terms to 
differentiate the two?

There are many examples of using either, rather inconsistently too.

James

---

From: James Carlson <[email-masked]>
Date: Tue, 05 Jan 2010 14:20:07 -0500

James M. Polk wrote:
> TSVWG has been involved in a low level discussion that's not resolved,
> and perhaps can't be at this time - focusing on parameter values being
> IANA registered as either
> 

I've seen "reserved" used to mean "can't be allocated for reasons of
protocol correctness or conflict with some other standards body or some
other historical issue," while "unassigned" means only that there's no
current definition.

I'd expect any specification that picks up a "reserved" code point would
be obligated to amend some part of the base specification to allow that
usage.

-- 
James Carlson         42.703N 71.076W         <[email-masked]>

---

From: Tom Taylor <[email-masked]>
Date: Tue, 05 Jan 2010 14:22:53 -0500

I'd say your definition of "reserved" applies to bits in a protocol. When it 
comes to an IANA registry, "reserved" to me would denote a codepoint that is 
being controlled -- held back for a particular usage or being allocated 
carefully because there are so few of them.

"Currently unused/unassigned" means that the value is available for use subject 
to the rules for assignment for the registry concerned.

---

From: Marc Blanchet <[email-masked]>
Date: Tue, 05 Jan 2010 16:03:11 -0500

>     'these are up for grabs, without restriction on usage until

well, old registries did not have all the info, but new ones have 
registration rules that tells precisely what/how you can get an 
assignment in the "Unassigned" values.

"Reserved" I think means "assigned" to some specific protocol reasons 
and could not be changed unless another RFC is published to change the 
reservation.

Marc.

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 5 Jan 2010 16:31:20 -0500

I think there are actually three states and we don't distinguish very well
between the second two of them.

The unassigned / unallocated / available state, which means that IANA can
allocate the code point under some clearly specified criterion.

Reserved, meaning set aside for some purpose not yet fully specified. A
typical example of this is to reserve the all ones value of some bit field
to be used to define some expansion mechanism, which is as yet not
specified, when other values are near exhaution.

Reserved / permanently reserved means set aside because, for some
fundamental protocol reason, new uses/meanings can not practically be
specified for the code point. A typical example would be a field where the
all zeros value for that field in protocol messages means the value is
unspecified/unknown. Allocating the all zeros value to some specific meaning
would conflict with the fundamental protocol meaning of all zeros.

Donald
=============================
Donald E. Eastlake 3rd   +1-508-634-2066 (home)
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

On Tue, Jan 5, 2010 at 4:03 PM, Marc Blanchet <[email-masked]>wrote:

> James M. Polk a écrit :
>
>  TSVWG has been involved in a low level discussion that's not resolved, and
>> perhaps can't be at this time - focusing on parameter values being IANA
>> registered as either
>>
> registration rules that tells precisely what/how you can get an assignment
> in the "Unassigned" values.
>
> "Reserved" I think means "assigned" to some specific protocol reasons and
> could not be changed unless another RFC is published to change the
> reservation.
>
> Marc.
>
>
>
>> If no to both the above -- do we need to refine our terms to differentiate
>> the two?
>>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 06 Jan 2010 10:57:30 +0100

Donald, all,

> I think there are actually three states and we don't distinguish very 
> well between the second two of them.
>
> The unassigned / unallocated / available state, which means that IANA 
> can allocate the code point under some clearly specified criterion.
>
> Reserved, meaning set aside for some purpose not yet fully specified. 
> A typical example of this is to reserve the all ones value of some bit 
> field to be used to define some expansion mechanism, which is as yet 
> not specified, when other values are near exhaution.
>
> specified for the code point. A typical example would be a field where 
> the all zeros value for that field in protocol messages means the 
> value is unspecified/unknown. Allocating the all zeros value to some 
> specific meaning would conflict with the fundamental protocol meaning 
> of all zeros.

Right.

And this is why in new specifications its useful to be explicit about 
what you mean. For instance,

  "value 0 has a special meaning as described in Section 3.3 and is 
reserved"
  "values 1-2 have been described in Section 4"
  "values 3-254 are available for allocation based on First Come, First 
Served basis [RFC 5226]"
  "value 255 is reserved for future extensions and is available for 
allocation only through revisions of this specification"
  "the remaining bits are reserved and are available for allocation 
based on Standards Action [RFC 5226]"

Jari

---

From: Michelle Cotton <[email-masked]>
Date: Tue, 5 Jan 2010 11:51:44 -0800

Please see Section 4 of RFC5226 where these descriptions are defined.
http://www.rfc-editor.org/rfc/rfc5226.txt

I hope this helps!

Michelle
IANA

On 1/5/10 11:22 AM, "Tom Taylor" <[email-masked]> wrote: