Hi, all, Sorry, but this seems incorrect to me. 1. if you want to reserve codepoints for an API (e.g., so that "0" means "let the OS decide" or "any"), then you don't "reserve" it; you remove it from the namespace. I.e., instead of defining the namespace as 0-255, you define the namespace as 1-255 and indicate that the value of 0 is specifically excluded *FROM THE PROTOCOL*. Otherwise, you end up with exactly the problem we have with things like transport port numbers - where 0 is effectively excluded as a protocol codepoint because no API can access it, but it's not technically excluded from being used inside a packet. I would absolutely advise against claiming that 0 is Reserved to assist with protocol development unless that's indicated in the specification itself to avoid this problem in the future. 2. there is absolutely no reason to reserve the maximum value for codepoint space extension; ANY reserved codepoint can accomplish that. It might be useful to indicate that at least one codepoints SHOULD be reserved for such extension, and that this is typically the highest value -- but if you need to list a reason, the only one that comes to mind is convenience of list management. Having it at the end makes it easy to see. But there's no algorithmic reason for suggesting this. Some other comments for this version: 1.1 - it's useful to remind authors to use only symbolic names for codepoints until assignments are completed by IANA. Those symbolic names should be used throughout the document AND in the IANA considerations section. 4.2 - experimental use codepoints should clearly indicate whether they are allowed or prohibited in widescale deployments on the public Internet; this is a good place to cite the methods described in RFC 6994 as potentially useful for other shared use of experimental codepoints. 4.3 - other guidance to expert reviewers appears in the BCP165 document pair (RFC6335 and RFC7605). 4.5 - transport ports should be listed under the examples provided in this section, as they are one of the most frequently assigned this way. 4.8 / 4.10 - Transport ports in the system range (0-1023) are assigned based on *either* IETF approval or IESG review, i.e., there's a case where either sections 4.8 or 4.10 apply. That might be a useful example. 4.11 - examples where IETF review or standards action are needed include cases where a namespace involves privilege, i.e., where simply using that space could provide increased access (e.g., transport ports in the system range). 4.12 - another place where transport ports are a good example of using multiple policies - both for different subsets of the namespace AND within one of those subsets. 6. another term useful to include here is "known unauthorized use". It is a flag that can accompany any of these registration status values listed and indicates when a codepoint is known to be deployed in the Internet in ways other than as indicated. That helps sysadmins understand when they see the codepoint whether it is likely that the assignee is involved or not. NOTE: I do not recommend indicating the name or contact point of the squatter because that only helps validate their squatting. 7. it's useful to note that documents in registries should be provided by a relatively permanent reference; a URL alone is typically insufficient (and dead within a few months). 9.3 - this section ought to explain the term "squatting" and its impact. In particular, I would like to see the IETF assert the claim that "use of a codepoint prior to its assignment should not influence a subsequent consideration of assignment", and reiterate that Internet drafts, RFCs, and other documentation must avoid using specific codepoints unless assigned for that purpose (i.e., assigned for that use specifically or consistent with generic assignments - the latter including experimental codepoints when deployed in ways consistent with such experiments) 9.4 - this section ought to differentiate between IANA revocation, assignee release, and transfer. I recommend seeing RFC6335 about transfers - e.g., transfers ought to be prohibited in favor of release/request where each of those two steps should need to pass the same hurdles as if they were independent. Speaking from experience, this section should also discuss what happens to abandoned contacts, i.e., when a codepoint is assigned based on a point of contact or assignee who no longer works at a company of whose company no longer exists. Joe On 4/26/2016 4:47 PM, Brian E Carpenter wrote: > On 27/04/2016 08:28, Adrian Farrel wrote: > ... >> Section 6 >> Include hint on best practice for top and bottom of ranges. >> 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 common practice for documents that define numeric registries >> to mark the zero value as "Reserved" because this often aids protocol >> implementations. > I'm not sure about the "because" clause. It sounds a bit like an excuse for > sloppy coding. Defining it explicitly as a no-op would seem like better > practice in many cases. > > Brian > >> It is also common practice to mark the maximum >> value as "Reserved" so that it can be used as part of a strategy to >> extend the registry if the range proves too small in the future. >> END >> >> Thanks, >> Adrian >> >>