Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

[Joe Touch <[e-mail]>]

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
>>
>>