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

["Adrian Farrel" <[e-mail]>]

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