Subject: Standardizing the zeroth and last code point of a registry

From: Jeffrey Haas <[email-masked]>
Date: Thu, 4 Jun 2015 16:18:32 -0400

John Scudder and I were having a brief discussion regarding some BGP code
points managed at IANA.  Over the course of that discussion, he suggested
that I send one of the thoughts to this list to see if it merited a small
draft.

Many Working Groups traditionally set aside the first and last code point
within a registry.  When you ask some people why this is so, it's not always
obvious to them.  The usual reasons I give:

0 - the unitialized value.  It makes writing code a bit easier sometimes and
lets you avoid a boolean state just to track whether 0 is set or not set as
a value.

max-val - often leveraged for Something Clever when you run out of code
points in the registry to do a feature extension.

There isn't a lot here obviously.  It may even be sufficient to drop a note
about this in the wiki.

-- Jeff

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 4 Jun 2015 20:27:08 +0000

Yeah, not using 0 is nice - mainly as you point out to have a not set/invalid value in code (avoiding an extra flag and more complex logic).

The max-val is less of a concern as you may have plenty of time to work out something once the unused space gets low (unless of course you have a very small space at first). And, why deal with an issue you may never have when the space is (very) large. (And, it may also be possible to use 0 in that case - at least on the wire - as a similar marker as max-val and it avoids wasting one value.)

- Bernie

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, June 04, 2015 4:19 PM
To: [email-masked]
Subject: Standardizing the zeroth and last code point of a registry

John Scudder and I were having a brief discussion regarding some BGP code points managed at IANA.  Over the course of that discussion, he suggested that I send one of the thoughts to this list to see if it merited a small draft.

Many Working Groups traditionally set aside the first and last code point within a registry.  When you ask some people why this is so, it's not always obvious to them.  The usual reasons I give:

0 - the unitialized value.  It makes writing code a bit easier sometimes and lets you avoid a boolean state just to track whether 0 is set or not set as a value.

max-val - often leveraged for Something Clever when you run out of code points in the registry to do a feature extension.

There isn't a lot here obviously.  It may even be sufficient to drop a note about this in the wiki.

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 4 Jun 2015 16:36:57 -0400

On Jun 4, 2015, at 4:27 PM, Bernie Volz (volz) <[email-masked]> wrote:
> 
> The max-val is less of a concern as you may have plenty of time to work out something once the unused space gets low (unless of course you have a very small space at first). And, why deal with an issue you may never have when the space is (very) large.

On the other hand, the same logic suggests there is no downside to reserving the maximum value.

– John

---

From: Michelle Cotton <[email-masked]>
Date: Thu, 4 Jun 2015 22:19:28 +0000

If 5226bis is the right place to have a note regarding this, we could
probably squeeze it in.
I¹ll wait to see what others think.

‹Michelle

---

From: Loa Andersson <[email-masked]>
Date: Fri, 05 Jun 2015 10:51:57 +0200

Folks,

> On the other hand, the same logic suggests there is no downside to reserving the maximum value.

Agree with John, doesn't take any extra effort and it is good practice.

Also, if we tell IANA that a code point is "unassigned" there is
nothing to stop IANA to assign it.

I also agree with Michelle that if we need a note on this, put it in the
5226bis.

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 5 Jun 2015 08:59:52 +0000

Also remember RFC3692 "Assigning Experimental and Testing Numbers Considered Useful".

Lars

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 12:21:53 -0400

Jeff:

I'll put a note in the IDR wiki. 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, June 04, 2015 4:19 PM
To: [email-masked]
Subject: Standardizing the zeroth and last code point of a registry

-- Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 5 Jun 2015 12:23:20 -0400

Can't hurt for individual WGs to do it, but I do agree that Jeff's observation has IETF-wide applicability.

--John

> On Jun 5, 2015, at 12:21 PM, Susan Hares <[email-masked]> wrote:
> 
> Jeff:
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 5 Jun 2015 12:25:47 -0400

> On Jun 4, 2015, at 6:19 PM, Michelle Cotton <[email-masked]> wrote:
> 

I think 5226bis is an appropriate place for these types of reservations and some documentation as to the reasoning for it.

I’m somewhat at a loss of how it would structurally fit into that document.

— Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 5 Jun 2015 12:36:36 -0400

> I’m somewhat at a loss of how it would structurally fit into that document.

How about something like this in S. 6?

OLD:

      Reserved: Not assigned and not available for assignment.  Reserved
            values are held for special uses, such as to extend the
            namespace when it becomes exhausted.  Note that this is
            distinctly different from "Unassigned".

NEW:

      Reserved: Not assigned and not available for assignment.  Reserved
            values are held for special uses, such as to extend the
            namespace when it becomes exhausted.  Note that this is
            distinctly different from "Unassigned".

            It is a best practice to reserve the minimum and maximum values,
            commonly zero and the all-ones value. This allows the minimum 
            value to be safely used as a distinguished "not set" by implementations,
            and protects the ability of the maximum value to be used as part of
            an extension strategy if the range proves too small in the future.

--John

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Jun 2015 17:37:08 +0100

I think 5226bis already defines the term "Reserved" for use in registries.

You could put a note after this to say:

"It is common practice for documents that define registries to mark the code
point zero as Reserved because this often aids protocol implementations."

I think that discussion of reserving the top values in registries is far more
debatable and I would not want to see that discussed in 5226bis.

Ciao,
Adrian

> Sent: 05 June 2015 17:26
> To: Michelle Cotton
> Cc: [email-masked]
> Subject: Re: Standardizing the zeroth and last code point of a registry
> 
> 
> I think 5226bis is an appropriate place for these types of reservations and
some
> documentation as to the reasoning for it.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 5 Jun 2015 17:38:04 +0100

Oh, John said what I said except he includes the max value. I disagree with him
on that point :-)

> From: WGChairs [mailto:[email-masked]] On Behalf Of John G.
> Scudder
> Sent: 05 June 2015 17:37
> To: Jeffrey Haas
> Cc: [email-masked]; Michelle Cotton
some
> > I'm somewhat at a loss of how it would structurally fit into that document.
>

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 5 Jun 2015 12:44:14 -0400

> On Jun 5, 2015, at 12:38 PM, Adrian Farrel <[email-masked]> wrote:
> 

FWIW, I agree with John’s text.  I don’t even consider the reservation of max value as being contentious since if we need to burn it and we’re *not* concerned with an extension strategy the WG can simply request IANA to allocate it.

Did you want to propose some additional text that says “if you need it, it can be burned, but please leave 0 alone”?

— Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 5 Jun 2015 13:00:05 -0400

> Did you want to propose some additional text that says “if you need it, it can be burned, but please leave 0 alone”?

You know, this suggests that the zero value should have some clearer description than merely "reserved", for example "reserved for use as an implementation-internal state variable distinguished value". (Feel free to come up with something less wordy.)

So, e.g.:

OLD:

NEW:

           Suggested descriptive text for the min and max reserved values is
           "reserved for use as an implementation-internal state variable
           distinguished value" and "reserved for potential future expansion",
           respectively.

           Finally, we note that if deemed necessary, the max value could be
           allocated for some other use, but the min value, once reserved as
           described here, can't be considered fair game for reassignment.

--John

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 16:34:02 -0400

Michelle: 

I think squeezing it into RFC5226bis is the right place. 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Michelle
Cotton
Sent: Thursday, June 04, 2015 6:19 PM
To: Jeffrey Haas; [email-masked]
Subject: Re: Standardizing the zeroth and last code point of a registry

‹Michelle

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 16:34:51 -0400

Jeff and all: 

Just to make sure I was clear - IDR Wiki + RFC5226bis. 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, June 05, 2015 12:22 PM
To: 'Jeffrey Haas'; [email-masked]
Subject: RE: Standardizing the zeroth and last code point of a registry

Jeff:

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Jeffrey Haas
Sent: Thursday, June 04, 2015 4:19 PM
To: [email-masked]
Subject: Standardizing the zeroth and last code point of a registry

-- Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 16:35:42 -0400

The text looks great to me! 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of John G.
Scudder
Sent: Friday, June 05, 2015 12:37 PM
To: Jeffrey Haas
Cc: [email-masked]; Michelle Cotton
Subject: Re: Standardizing the zeroth and last code point of a registry

On Jun 5, 2015, at 12:25 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> 
> I think 5226bis is an appropriate place for these types of reservations
and some documentation as to the reasoning for it.

OLD:

NEW:

            It is a best practice to reserve the minimum and maximum values,
            commonly zero and the all-ones value. This allows the minimum 
            value to be safely used as a distinguished "not set" by
implementations,
            and protects the ability of the maximum value to be used as part
of
            an extension strategy if the range proves too small in the
future.

--John

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 5 Jun 2015 16:36:54 -0400

John and Jeff: 

I like the clear assignment of 255 and 0 as reserved.   However, I'm fine with this text as well. 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Friday, June 05, 2015 1:00 PM
To: Jeffrey Haas
Cc: [email-masked]; Michelle Cotton; [email-masked]
Subject: Re: Standardizing the zeroth and last code point of a registry

So, e.g.:

OLD:

NEW:

--John

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 5 Jun 2015 21:28:41 +0000

> I like the clear assignment of 255 and 0 as reserved

But that only works if the field is an octet (8-bits). The text with "zero" and "all ones" works for all field sizes (well, except for a 1-bit field but I think that's obvious).

- Bernie

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, June 05, 2015 4:37 PM
To: 'John G. Scudder'; 'Jeffrey Haas'
Cc: [email-masked]; 'Michelle Cotton'; [email-masked]
Subject: RE: Standardizing the zeroth and last code point of a registry

John and Jeff: 

Sue 

-----Original Message-----
From: WGChairs [mailto:[email-masked]] On Behalf Of John G. Scudder
Sent: Friday, June 05, 2015 1:00 PM
To: Jeffrey Haas
Cc: [email-masked]; Michelle Cotton; [email-masked]
Subject: Re: Standardizing the zeroth and last code point of a registry

So, e.g.:

OLD:

NEW:

--John

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 5 Jun 2015 14:56:39 -0700

> From: WGChairs [mailto:[email-masked]] On Behalf Of Bernie Volz
> (volz)
> Sent: Friday, June 05, 2015 2:29 PM
> To: Susan Hares; 'John G. Scudder'; 'Jeffrey Haas'
> But that only works if the field is an octet (8-bits). The text with "zero" and "all
> ones" works for all field sizes (well, except for a 1-bit field but I think that's
> obvious).

All ones does not work well if you are looking at field as either a signed value (-128 to 127) or if the size of the field is not fixed.

> > FWIW, I agree with John’s text.  I don’t even consider the reservation of max
> value as being contentious since if we need to burn it and we’re *not*
> concerned with an extension strategy the WG can simply request IANA to
> allocate it.
> >
> You know, this suggests that the zero value should have some clearer
> description than merely "reserved", for example "reserved for use as an
> implementation-internal state variable distinguished value". (Feel free to come
> up with something less wordy.)
> 
> So, e.g.:
> 
> OLD:
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 05 Jun 2015 23:26:26 +0000

I think that that having this as a general guideline is probably a nice
idea, but it should be clear that it is simply a recommendation / good
practice (I'm not quite sure it is a *best* practice). For example, what if
I'm building a protocol where the IANA registry is strings - I could see
reserving an empty string or null string, but what is the maximum of a null
terminated string? Or OIDs? Or if I have a very limited set of options - I
can only spare 4 bits, and I know (because <handwave>) that there can never
be more than 10 possible options?

So, yes, I like this as a general principle, but we often seem to somehow
convert general principles into golden cows.

W

On Fri, Jun 5, 2015 at 5:57 PM Jim Schaad <[email-masked]> wrote:

> All ones does not work well if you are looking at field as either a signed
> value (-128 to 127) or if the size of the field is not fixed.
>
> >
> > - Bernie
> >
> > I like the clear assignment of 255 and 0 as reserved.   However, I'm
> fine with this
> > text as well.
> >
> > Sue
> >
> > > Did you want to propose some additional text that says “if you need
> it, it can
> > be burned, but please leave 0 alone”?
> >

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 5 Jun 2015 19:40:50 -0400

Sure. 

To your point (and Jim's): "send text". (Or not, but it would probably advance the discussion faster.)

--John

> On Jun 5, 2015, at 7:26 PM, Warren Kumari <[email-masked]> wrote:
> 
> I think that that having this as a general guideline is probably a nice idea, but it should be clear that it is simply a recommendation / good practice (I'm not quite sure it is a *best* practice). For example, what if I'm building a protocol where the IANA registry is strings - I could see reserving an empty string or null string, but what is the maximum of a null terminated string? Or OIDs? Or if I have a very limited set of options - I can only spare 4 bits, and I know (because <handwave>) that there can never be more than 10 possible options? 
> 
> So, yes, I like this as a general principle, but we often seem to somehow convert general principles into golden cows.
> 
> W
>

---

From: Warren Kumari <[email-masked]>
Date: Sat, 06 Jun 2015 00:50:29 +0000

On Fri, Jun 5, 2015 at 7:40 PM John G. Scudder <[email-masked]> wrote:

> Sure.
>
> To your point (and Jim's): "send text".
>

I see what you did there.

:-)
W

> (Or not, but it would probably advance the discussion faster.)
>
>
> --John
>
>> All ones does not work well if you are looking at field as either a
>> signed value (-128 to 127) or if the size of the field is not fixed.
>>
>> >
>> > - Bernie
>> >

---

From: <[email-masked]>
Date: Mon, 8 Jun 2015 08:07:33 +0000

1) I support Jeff & John's proposal

2) IMO status of "0" must be very clear. We want to avoid implementations hard coding their own behavior and then IETF allocating 0 for a new usage and breaking existing implementations.
Rather than defining "0" as a reserved value, I would rather propose assigning/registering the value "0" to implementations.

3) IMHO, I would phrase it as a proposition/may. i.e. nice practice but up to you.

4) It's really up to Michelle, but I would rather put the text somewhere in "2.  Creating and Revising Registries", may be in "2.2.  Documentation Requirements for Registries" (rather than in the currently proposed "6.  Well-Known Registration Status Terminology")

5) In summary, proposed text:

OLD:

 6.  Well-Known Registration Status Terminology
[...]

 

NEW:
2.2.  Documentation Requirements for Registries
[...]
   Initial assignments and reservations

      Any initial assignments or registrations to be included.  In
      addition, any ranges that are to be reserved for "Private Use",
      "Reserved", "Unassigned", etc.  (see Section 6) should be
      indicated.

           It is usually useful to set aside the minimum and maximum values,

        If so, the minimum value should be assigned to "Implementation-internal state variable distinguished value" and the maximum value should be reserved as "Reserved for potential future expansion".

/Bruno

> Sent: Friday, June 05, 2015 7:00 PM
> 
> > FWIW, I agree with John’s text.  I don’t even consider the reservation of
> max value as being contentious since if we need to burn it and we’re *not*
> > Did you want to propose some additional text that says “if you need it, it
> can be burned, but please leave 0 alone”?
> 
> implementation-internal state variable distinguished value". (Feel free to
> come up with something less wordy.)
> 
> So, e.g.:
> 
> OLD:
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Jun 2015 14:20:13 -0400

Bruno,
>        If so, the minimum value should be assigned to "Implementation-internal state variable distinguished value" and the maximum value should be reserved as "Reserved for potential future expansion”.

I think it’s sufficient just to document 0 as reserved and then perhaps point to the RFC we’re documenting this behavior in.  Noting that the max value is “reserved for potential future expansion” seems like wonderful text to me, especially with a similar pointer to the RFC

— Jeff

---

From: Barry Leiba <[email-masked]>
Date: Mon, 8 Jun 2015 14:57:25 -0400

>      an extension strategy if the range proves too small in the future.

Sorry for coming in a bit late to this, and excuse me for sticking my
oar in, but:

It seems to me that:

(1) None of this belongs in the long-delayed (SORRY!) 5226bis unless
it really *is* agreed that it's a best practice, so let's please be
quite careful about the text we ask for there.

(2) The discussion is not really supporting "zero" as a "reserved"
value.  It's supporting having it be an *invalid* value -- that is,
outside the range of acceptable values.  Specs can, of course, say
what implementations should do when they encounter it -- consider it
an error, use a default value, and so on.  But the point is that we
will *never* want to un-reserve it and assign it to something.

Because of point (2), if we say anything about this I would rather say
that if we don't want zero to be assigned, we should put in the IANA
Considerations that valid values are from 1 to <whatever>, and IANA
will note that in the registry.

This, of course, doesn't apply to the max_value case, where we *are*
reserving the value for possible use to signal an extension at some
point.

Barry

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 8 Jun 2015 15:08:13 -0400

On Jun 8, 2015, at 2:57 PM, Barry Leiba <[email-masked]> wrote:
> value.  It's supporting having it be an *invalid* value
[etc]

It seems to me that Bruno's description of it as an assigned value is equally accurate, if not more so, and easier to understand.

– John

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Jun 2015 15:12:54 -0400

Barry,

> quite careful about the text we ask for there.

While I was fine having it rolled in, I’m also fine rolling a new document.  FWIW, the practice is somewhat common but perhaps not “best”.  Mostly when it’s done, it’s not always been codified as to why it’s 
> will *never* want to un-reserve it and assign it to something.

This was in the same lines as my response to Bruno: I don’t know what value we get by have a state in the registry that isn’t “reserved”.  Reserved, to me, says “don’t use this - there’s a reason”.  We will ideally never un-reserve it, whereas in the max-val case we may choose to.  Changing a reserved value to un-reserved will already involve getting the appropriate registry experts involved; if the reason is a future RFC indicating 0 is a magic number, the experts are likely to say no.  Similarly if the future experts decide it’s wise to do so anyway, they can.

Specs definitely should be specific as to what they do when encountering reserved or unassigned values.  Occasionally weird behaviors creep in.  As a recent example, we now have a Autonomous System 0 draft because a 0 getting out into the wild caused Bad Things to happen.

— Jeff

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 8 Jun 2015 23:23:47 +0100

Making it an invalid value is easy and different since IANA indicates the range for any code point registry and you can tell IANA that the available range is 1-254 if that is what you want.

Recall, IANA has a registry not a protocol spec!

A

> Sent: 08 June 2015 20:08
> To: Barry Leiba
> It seems to me that Bruno's description of it as an assigned value is equally
> accurate, if not more so, and easier to understand.
> 
> – John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 09 Jun 2015 13:38:54 +0200

Hi Jeff,

Sorry for coming in late as well.  Please see below.

> I think it’s sufficient just to document 0 as reserved and then perhaps point to the RFC we’re documenting this behavior in.  Noting that the max value is “reserved for potential future expansion”…

I like marking 0 as invalid, and your argument for not using the value.

Regarding other reserved fields, in particular the maximum, I think of
that situation somewhat in the context of 240/4, which I realize is an
odd case, but that's the one that burned us all (and thus taught us a
thing or two).  What it taught me was that you can never unreserve
something that is not end to end, and so expansion bits are useless
unless they can be transparently passed.  I would suggest that whether
you write a new document or plop something into 5226bis, you add some
discussion about that experience.

Eliot

---

From: Loa Andersson <[email-masked]>
Date: Tue, 09 Jun 2015 16:19:46 +0200

Folks,

I'm not sure what the difference between "invalid" and "reserved" is,
isn't "reserved" simply the name for a code point that is not available
for allocation, i.e. it is invalid.

5226bis does not the term "invalid".

/Loa

--

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 9 Jun 2015 10:25:25 -0400

Elliot,

> On Jun 9, 2015, at 7:38 AM, Eliot Lear <[email-masked]> wrote:

Wonderful idea.  240/4 is an example where we didn’t plan ahead.  A counter example is https://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-03 <https://tools.ietf.org/html/draft-ietf-idr-ext-opt-param-03>, although it’s not 100% of a match for the behavior I’m trying to codify.

— Jeff

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 9 Jun 2015 10:36:25 -0400

> 5226bis does not the term "invalid".

I agree.

The point I took from Bruno's earlier email was that "reserved" has the connotation of being potentially available for later release and allocation, if the owner of the registry agrees. That properly describes the max-value reservation, but not the zero-value because that one is actually allocated for internal use. I don't think a registry is constrained to only apply to legal on-the-wire values, so it seems proper to allocate the zero value just as we've previously discussed, nor do I think we need a new special term "invalid".

Making these "guidelines" and not anything stronger seems proper (and speaking as the person who proposed the "best practice" language I'm happy to withdraw it). As guidelines, they can be disregarded as needed, for example for a very small range, or on the other hand maybe you want to allocate more than just zero for internal use, it it's expected that several internal distinguished values are needed.

--John

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 10 Jun 2015 14:10:54 +0100

>>       an extension strategy if the range proves too small in the future.
This is useful advice to anyone writing an IANA section, but no more
that that. There may be many reasons why these values need to be
used and the code space may be too compact to have the luxury of
doing this.

Thus I think it is important to make this of the form "we suggest
you consider" and be no stronger than that.

- Stewart

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Wed, 10 Jun 2015 13:19:30 +0000

> On Jun 10, 2015, at 9:10 AM, Stewart Bryant (stbryant) <[email-masked]> wrote:
> 

+1.

“usually useful” and “suggest you consider” are good -- I do not think this amounts to a best practice.

BTW, a degenerate case is a one-bit boolean field, which has a zero and all-ones values :-) but there’s many protocol fields in which maximizing available numbers seems more important.

Thanks,

— Carlos.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Jun 2015 11:50:05 -0400

> 5226bis does not the term "invalid".

The difference is that "invalid" is an idea, not a state that's
recorded in the registry.  The registry would simply say that valid
values range from 1 to 255, say, and would list 255 as "reserved".  0
wouldn't be mentioned at all, because it's simply not in the valid
range.

That really *is* what we're saying here.  0 isn't reserved for future
use.  It's not in the valid range of values, which start at 1.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 10 Jun 2015 11:52:17 -0400

> you consider" and be no stronger than that.

I agree with that assessment, which is why I'd rather not put it into
5226bis.  I will, of course, do whatever we have rough consensus for.

Barry

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 10 Jun 2015 12:08:44 -0400

While there are plenty of contexts where having a distinct value for 
unassigned is useful, there are plenty of others where it does not add 
value.  Now, usually, burning 1 code point does not cost much, but I 
find it strange that folks are treating this as an "always" kind of rule.

Reserving the top end of the standard range makes good sense.  That is 
not always the top end of the allowed values.  For example, in some 
contexts the entire top half of the value space is FCFS.

Yours,
Joel