Subject: Code point reservation BCP

From: Jeffrey Haas <[email-masked]>
Date: Fri, 18 Sep 2015 10:20:05 -0400

After a little discussion and initial review on the wgchairs list, I'd like
to draw the broader IETF community's attention to the draft below.  It's my
belief that the practice of reserving bottom and top code points is fairly
common in the IETF (and perhaps it has analogs in other SDOs?).  However, I
don't think the practice has been written down anywhere for the benefit of
those who may be new to our organization.

Note that the goal of this document is to discuss specifically certain
reserved values.  It does not have the intention of discussing allocation
strategies for various ranges and their types.  (See
draft-leiba-cotton-iana-5226bis-11 and RFC 3692 as examples of such
documents.)  As such, I don't believe this document should have much a
creeping scope of things to cover.

The goal would be to submit this as a BCP document sometime this year,
potentially as an AD-sponsored draft.

I welcome your comments.

-- Jeff

----- Forwarded message from [email-masked] -----

Date: Fri, 18 Sep 2015 07:09:38 -0700
From: [email-masked]
To: [email-masked]
Subject: I-D Action: draft-haas-code-point-reservation-bcp-02.txt

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-02.txt
	Pages           : 5
	Date            : 2015-09-18

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.  This 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-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-haas-code-point-reservation-bcp-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

----- End forwarded message -----

---

From: Joe Touch <[email-masked]>
Date: Fri, 18 Sep 2015 10:27:18 -0700

If this is intended as a BCP on the general concept of code point
reservation, there are a lot of issues -- and existing RFCs -- that need
to be addressed:

	RFC2780
	RFC3692
	RFC4727
	RFC5226
	RFC6994

Issues include:
	reserving values in a numeric range for:
		future variants
		extensibility of the range
		concurrent signals:
			as values within the range
			as values orthogonal to the range
	reserved flags
		default when sent
		interpretation at receiver
			ignore unless signaled elsewhere
			require 0
			treat 0 as ignore/1 as "upgraded"

There's also the issue of the space of codepoints, i.e., port numbers
are much more limited than service names, even though both are finite.

I think there's danger in assuming that "0" means "unset"; that's not
"Reserved", but really "means that the codepoint is not supported or not
set" and is thus assigned. Zero is often reserved for other reasons.

Reserved codepoints MUST NOT be used and MUST NOT be interpreted.

The semantics of why a codepoint is reserved MUST NOT be indicated;
that's not "Reserved" but "Assigned for future use".

I.e., "Reserved" means only that - with an undefined future use. Every
assignment - including Reserved - MUST have a defined sender and
receiver action:

	MUST NOT be set until defined
	MUST be silently ignored? or generate error? etc.

I don't think this doc should specify the behavior, but should indicate
that a behavior MUST be specified.

That's the short list off issues off the top of my head. If you're
interested in more feedback or text, contact me off-list.

Joe

---

From: t.p. <[email-masked]>
Date: Mon, 21 Sep 2015 12:55:07 +0100

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 18, 2015 3:20 PM
Subject: Code point reservation BCP

> those who may be new to our organization.

Yup; a part of 'How to Write Code 101' but nonetheless a debate that I
have lost on a number of occasions over the years, so I hope that this
makes it through the process.

I would prefer 'first' to 'zeroth' - I find the latter somewhat
obscure - and I would prefer the title to be more specific, slotting in
the word 'numeric' after IETF (or should that be IANA?) since textual
registries can be ordered and have a first and last but the
considerations here would not apply.

Tom Petch

>         Title           : Reservation Strategies for the Zeroth and
Last Code Points in IETF Registries and for Bit Field Registries
> A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-haas-code-point-reservation-bcp-
02

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 21 Sep 2015 09:38:32 -0400

Tom,

Thanks for the feedback.

On Mon, Sep 21, 2015 at 12:55:07PM +0100, t.p. wrote:
> obscure - and I would prefer the title to be more specific,

The intention is to strongly imply "code point zero".  While we don't have
many things that start counting from one (BITS in SMIv2 being a counter
example, iirc.) the intention is definitley not to reserve the first thing
if it's non-zero.  

This probably shows a bit of prejudice to C and similar language constructs,
but there you have it.

> slotting in

I'll look at wedging in numeric somewhere in there.  The name is already
getting to be a bit long.

IANA was specifically not included in the text since some code point
registries may exist solely within a document for some length of its
lifetime.  I was also suggested to consider dropping "IETF" since the
practice is still useful outside of IETF documents, but other SDOs get
cranky if you start recommending what they should do. :-)

-- Jeff

---

From: t.p. <[email-masked]>
Date: Mon, 21 Sep 2015 17:00:47 +0100

---- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, September 21, 2015 2:38 PM

> example, iirc.) the intention is definitley not to reserve the first
thing

Jeff

I was unclear.  I agree that we should not be reserving 'one' if it is
the first - rather, I was suggesting that in the title, and probably in
the Abstract, 'first' would be more readily understood than 'zeroth'
(which sounds like the last letter of an little-known Eastern
language:-).  Then in the Introduction, spell out that it is zero that
is meant by first.

Tom Petch