Re: Code point reservation BCP

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

 



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

On 9/18/2015 7:20 AM, Jeffrey Haas wrote:
> 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 internet-drafts@xxxxxxxx -----
> 
> Date: Fri, 18 Sep 2015 07:09:38 -0700
> From: internet-drafts@xxxxxxxx
> To: i-d-announce@xxxxxxxx
> 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
> I-D-Announce@xxxxxxxx
> 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 -----
> 




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