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

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 21 Apr 2016 16:09:05 +0100

Thanks to the authors for resurrecting this work, and thanks also for addressing
comments from the previous review cycle. I went back and read the review
comments I entered back in 2014 when the document was last up before the IESG
(https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ballot/#adrian
-farrel) before I did this review and I feel that the general point still
applies that it is really hard for a document author to extract a simple
"cookbook for an IANA considerations section". [I'm afraid I can no longer swap
in the context of any email threads that happened at that time.] Maybe this is
intended to be covered at the URL mentioned in 1.2 - that would be good, but had
I held my breath back in 2014 and waited for this URL to receive some content, I
would not now be bothering you with this email!  (All the detailed nits I raised
back then seem to have been addressed, however, so very many thanks!)

I think this document is ready for publication, but I wonder whether some
further emphasis for clarity might be added to section 4.4. The point I would
like to labor is that the assignment is made for a specific use not for a
specific person, organization, company, etc. You do already state that changes
to the registration of a First Come First Served code point retain compatibility
with the current usage of that code point, and this is exactly the right
message. But I have recently heard several cases of a code point that was
assigned using FCFS as "Foo Corp's BLEAGH protocol" being completely repurposed
by Foo Corp as "Foo Corp's YUCK protocol". You appear to be saying that "this
should not happen" and I largely agree (modulo - we really know this is not in
the field), but how is IANA to interpret this text and how do you expect them to
act if Foo Corp sends them mail to say what they have done? Maybe also a forward
pointer to 9.4 and 9.5?

In 4.9 you have
   For the Standards Action policy, values are assigned only through
   Standards Track or Best Current Practice RFCs approved by the IESG.
Do you want to harmonize this with language in other sections by saying "IETF
Stream" not "approved by the IESG"?

15.1 has a dated title.

Cheers,
Adrian

> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Guidelines for Writing an IANA Considerations Section in RFCs'
>   <draft-leiba-cotton-iana-5226bis-12.txt> as Best Current Practice

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 26 Apr 2016 21:28:02 +0100

Hi,

A couple of further thoughts arising from the discussions on the WG chairs'
mailing list (but not claiming the opinions as other than my own).

Section 4.4
Aim to set the expectations of consumers better (and fix the grammar) by...
OLD
 For numbers, the exact
 value is generally assigned by IANA; with names, specific text
   strings can usually be requested.
NEW:
 For numbers, IANA generally assigns the next in-sequence unallocated
 value, but other values may be requested and assigned if an extenuating
 circumstance exists.  With names, specific text strings can usually be
 requested.
END

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Apr 2016 11:47:14 +1200

On 27/04/2016 08:28, Adrian Farrel wrote:
...
>           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

---

From: Joe Touch <[email-masked]>
Date: Wed, 27 Apr 2016 11:27:52 -0700

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