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

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Sep 2015 10:24:14 -0400

On Thu, Jun 04, 2015 at 04:18:32PM -0400, Jeffrey Haas wrote:
> 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.

I've put together that small draft and would appreciate review.

The long term goal is to get it published as an RFC.  I'd suspect this is a
general area draft.

: A New Internet-Draft is available from the on-line Internet-Drafts
: directories.
: 
: 
:         Title           : Reservation Strategies for the Zeroth and Last
: Code Points in IETF Registries and for Bit Field Registries
:         Author          : Jeffrey Haas
:         Filename        : draft-haas-code-point-reservation-bcp-00.txt
:         Pages           : 5
:         Date            : 2015-09-15
: 
: Abstract:
:    This document describes common code point reservation strategies for
:    the zeroth and last code points in IANA-managed IETF registries and
:    for bit-field registries.  The document additionally provides the
:    reasoning to support these strategies and their adoption as Best
:    Current Practices to be applied to all IETF registries.
: 
: 
: The IETF datatracker status page for this draft is:
: https://datatracker.ietf.org/doc/draft-haas-code-point-reservation-bcp/
: 
: There's also a htmlized version available at:
: https://tools.ietf.org/html/draft-haas-code-point-reservation-bcp-00
:

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 15 Sep 2015 11:25:47 -0400

> :         Filename        : draft-haas-code-point-reservation-bcp-00.txt

I find this text unclear:

   o  The zeroth entry of the new registry SHOULD be reserved.  This
      permits implementors to avoid the need of separate boolean state
      to represent that a code point has been set with the value zero.
      It is RECOMMENDED that the reservation text should be of the form,
      "Reserved (not to be allocated)".

I think you're suggesting that you want the value of 0 to mean the same
thing as "the codepoint has not been selected at all".  But the
sentences above can be easily misparsed as "to represent that a code
point has been (set with the value zero)".

I think what you're really asking for is a way that implementors can
easily have an "uninitialized" or "unset" state for the codepoint that
is represented in the same data field that would otherwise contain the
initialized data.  Is that right?

            --dkg

---

From: Loa Andersson <[email-masked]>
Date: Tue, 15 Sep 2015 17:48:55 +0200

Jeff and Daniel,

> point has been (set with the value zero)".

I don't see this, I don't see how "Reserved (not to be allocated)" can
be misparsed to mean that a code point has been allocated.
Having said that, I'm of course is open for improved text, when i comes
in.
> initialized data.  Is that right?
Jeff,

I find this extremely useful, and in line with what I tried to implement
for some time.

/Loa

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Sep 2015 12:07:21 -0400

Daniel,

> initialized data.  Is that right?

Your last paragraph captures my intent.  We should *not* see the value
showing up in PDUs and thus we can use it as "the state is unset".

My thought is that if it is not allocated, it shouldn't show up in the
protocol.  This is reinforced later by the operational text.

-- Jeff

---

From: Kent Watsen <[email-masked]>
Date: Tue, 15 Sep 2015 16:58:41 +0000

Hi Jeff,

On the zeroth code point, I think the following text would resolve the
concern:

  OLD
    This

  NEW
    This
    permits implementors to avoid the need of separate boolean state
    to represent that a code point has been set.

Also, on the last code point, how about the following?

  - Reserved (for future use for registry extension)
  + Reserved (for future registry extension)

Kent

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 15 Sep 2015 13:56:49 -0400

>     to represent that a code point has been set.

I think this resolves my concern (though i would have phrased it the
other way -- "to represent that a code point remains unset" or something
similar.

thanks for the proposed text!

       --dkg

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Sep 2015 15:26:44 -0400

> thanks for the proposed text!

Thanks for the text.  Here's what I've applied:

-      to represent that a code point has been set with the value zero.
-      It is RECOMMENDED that the reservation text should be of the form,
-      "Reserved (not to be allocated)".
+      to represent that a code point remains unset.  It is RECOMMENDED
+      that the reservation text should be of the form, "Reserved (not to
+      be allocated)".

I've also taken Kent's edit on the last code point.

-- Jeff

---

From: <[email-masked]>
Date: Wed, 16 Sep 2015 08:04:01 +0000

Hi Jeff,

Thinking out loud...

"   o  The zeroth entry of the new registry SHOULD be reserved.  This
      permits implementors to avoid the need of separate boolean state
      to represent that a code point has been set with the value zero."

Looks like this boolean is currently an internal state, hence trusted. The draft is proposing to replace it with an external state, hence a priori less trusted. (how much less trusted is very protocol, use case and crypto dependent).
I'm wondering whether this has security implications. e.g. now someone can clear you internal state, i.e. makes you believe you had never received the code point. 

One option may be to never update you internal variable/memory if you receive the value zero. (I agree that this should not be seen as a fatal error condition.)

-- Bruno

> -----Original Message-----
> From: WGChairs [mailto:[email-masked]] On Behalf Of Jeffrey
> Haas
> Sent: Tuesday, September 15, 2015 4:24 PM
> To: [email-masked]
> Subject: Draft posted - Standardizing the zeroth and last code point of a
> registry
> 

_________________________________________________________________________________________________________________________

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: Cullen Jennings <[email-masked]>
Date: Wed, 16 Sep 2015 20:42:50 -0600

I like the draft, but seems like there would be a better list to discuss it on.

> On Sep 15, 2015, at 8:24 AM, Jeffrey Haas <[email-masked]> wrote:
>

---

From: Loa Andersson <[email-masked]>
Date: Thu, 17 Sep 2015 18:20:21 +0200

Cullen,

two points

- this originated as a wg chair discussion, so I think it is reasonable
   to see if the draft flies with the chairs
- but pretty quickly we should have it discussed in a wider group, but
   I'm not sure which list, any idea?

/Loa

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 17 Sep 2015 13:48:28 -0400

>   I'm not sure which list, any idea?

I brought the draft back to the list as Loa says it started here.  But I
think the draft has gotten most of what it needs from wgchairs.

The question does remain: How does one take such a general draft forward?
I can prod discussion on ietf@ (I'm subscribed, but I seldom pay attention
to that inbox).  

I should prod Jari again about whether this should simply be a general-area
draft.  I thought I had done so, but I'm having issues tracking down that
mail.

-- Jeff

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 17 Sep 2015 23:58:23 +0000

Sent from my iPad

> On Sep 17, 2015, at 1:45 PM, Jeffrey Haas <[email-masked]> wrote:
> 

Jeff:

Hi!  

I think that the ietf@ list would be a good place for discussion.  It's surprising the number of people who pay attention to it.  ;-)

I'll give Jari the right if first refusal -- I'd be willing to sponsor this work.

Thanks!

Alvaro.