Some comments on draft-leiba-cotton-iana-5226bis-19

[Stewart Bryant <[e-mail]>]

    The Protocol field in the IP header [RFC0791] and MIME media types
    [RFC6838] are two examples of such coordinations.

SB> nit I suspect that coordination should be singular.

===========


1.2.  For Updated Information

    IANA Services maintains a web page that includes additional
    clarification information, beyond what is provided here, such as
    minor updates and summary guidance.  Document authors should check
    that page.  Any significant updates to the best current practice will
    have to feed into updates to BCP 26 (this document), which is
    definitive.

       <https://iana.org/help/protocol-registration>.

SB> The URL seems stranded.
SB> Surely the para should be slit and it placed up there.

=============

    If you are registering into an existing registry...

SB> I am surprised that there is no guidance to copy the layout in
SB> the existing registry. So authors don't do that and it is much
SB> harder to check that it is correct.

==============

       Providing a URL to precisely identify the registry helps IANA
       Services understand the request.  Such URLs can be removed from
       the RFC prior to final publication, or left in the document for
       reference.  If you include iana.org URLs, IANA Services will
       provide corrections, if necessary, during their review.


SB> This seems new. Certainly it is not common in documenting the lower
SB> layers of the stack. Has this led to any significant problems in the
SB> past?

================

2.4.  Revising Existing Registries



    Normally, numeric values to be used are chosen by IANA Services when
    the document is approved, and drafts should not specify final values.
    Instead, placeholders such as "TBD1" and "TBD2" should be used
    consistently throughout the document, giving each item to be
    registered a different placeholder.  The IANA Considerations should
    ask the RFC Editor to replace the placeholder names with the assigned
    values.  When drafts need to specify numeric values for testing or
    early implementations, they will either request early allocation (see
    Section 3.4) or use values that have already been set aside for
    testing or experimentation (if the registry in question allows that
    without explicit assignment).  It is important that drafts not choose
    their own values, lest IANA Services assign one of those values to
    another document in the meantime.  A draft can request a specific
    value in the IANA Considerations section, and IANA Services will
    accommodate such requests when that's possible, but the proposed
    number might have been assigned to some other use by the time the
    draft is approved.

SB> It would be useful to remind the new reader of early allocation
SB> so that they can gain pre-standards experience with the protocol

=================

    The IANA Considerations section should summarize all of the actions,
    with pointers to the relevant sections elsewhere in the document as
    appropriate.  Including section numbers is especially useful when the
    reference document is large; the section numbers will make it easier
    for those searching the reference document to find the relevant
    information.

SB> It can be hard enough to display some registries without this extra text
SB> 80 chars is not much space.
SB> Hopefully this will not escalate to become a requirement.

=============

    Note: In cases where authors feel that including the full table of
    changes is too verbose or repetitive, authors should still include
    the table in the draft, but may include a note asking that the table
    be removed prior to publication of the final RFC.


SB> Surely this risks loosing tractability? Maybe relegate it to an
SB> appendix? Many times I have found it useful to know exactly
SB> when an why a registry entry changed.

=================

3.3.  Overriding Registration Procedures

    Experience has shown that the documented IANA considerations for
    individual protocols do not always adequately cover the reality of
    registry operation, or are not sufficiently clear.  In addition,
    documented IANA considerations are sometimes found to be too
    stringent to allow even working group documents (for which there is
    strong consensus) to perform a registration in advance of actual RFC
    publication.

    In order to allow assignments in such cases, the IESG is granted
    authority to override registration procedures and approve assignments
    on a case-by-case basis.

    The intention here is not to overrule properly documented procedures,
    or to obviate the need for protocols to properly document their IANA
    considerations.  Rather, it is to permit assignments in specific
    cases where it is obvious that the assignment should just be made,
    but updating the process beforehand is too onerous.

SB> Perhaps this should also make clear that in the event of a dispute
SB> with a designated expert the IESG can overrule the expert.

==================

3.4.  Early Allocations

    IANA Services normally takes its actions when a document is approved
    for publication.  There are times, though, when early allocation of a
    value is important for the development of a technology: for example,
    when early implementations are created while the document is still
    under development.

    IANA Services has a mechanism for handling such early allocations in
    some cases.  See [RFC7120] for details.  It is usually not necessary
    to explicitly mark a registry as allowing early allocation, because
    the general rules will apply.


SB> RFC7120 has text saying that an early allocation dies of old age
SB> unless certain procedures are followed. In practice I have seen
SB> such code-point technically die, but remain in deployed use up
SB> until the draft later becomes ready for publication perhaps a couple
SB> of years later.
SB> It would be useful to clarify that at publication the in use
SB> but technically dead codepoint can be allocated to the RFC.


========================


    It should be noted that it often makes sense to partition a namespace
    into multiple categories, with assignments within each category
    handled differently.  Many protocols now partition namespaces into
    two or more parts, with one range reserved for Private or
    Experimental Use while other ranges are reserved for globally unique
    assignments assigned following some review process.  Dividing a
    namespace into ranges makes it possible to have different policies in
    place for different ranges and different use cases.

SB> What can also be useful is to reserve a bunch of numbers in case
SB> is "a run on the bank". Particularly if done is such a was
SB> as to permit range extension. RFC7274 is an example of where
SB> a range extension method was published.


=====================

4.1.  Private Use

    For private or local use only, with the type and purpose defined by
    the local site.  No attempt is made to prevent multiple sites from
    using the same value in different (and incompatible) ways.  IANA
    Services does not record assignments from registries or ranges with
    this policy (and therefore there is no need for IANA Services to
    review them) and assignments are not generally useful for broad
    interoperability.  It is the responsibility of the sites making use
    of the Private Use range to ensure that no conflicts occur (within
    the intended scope of use).

    Examples:

       Site-specific options in DHCP [RFC2939]
       Fibre Channel Port Type Registry [RFC4044]
       TLS ClientCertificateType Identifiers 224-255 [RFC5246]

SB> The 192.168.0.0 and 10/24 subnets are possibly better known
SB> examples to the new reader.

==============

    When code points are set aside for experimental use, it's important
    to make clear any expected restrictions on experimental scope.  For
    example, say whether it's acceptable to run experiments using those
    code points over the open Internet, or whether such experiments
    should be confined to more closed environments.  See [RFC6994] for an
    example of such considerations.

SB> This seems to be backing away from what I have always thought was
SB> best practice, i.e. don't deploy these codepoints outside the lab.
SB> Otherwise what happens is code-point-squatting on experimental
SB> values with all sorts of consequential problems.

=================

4.5.  Expert Review

SB> I did not see it covered here, but my recollection is that
SB> the documentation of ER codepoints does not need to be placed
SB> in the public domain, and that where this is a matter of
SB> conflict of interest, or commercial confidentially a suitably
SB> no-partizan expert may be appointed to the task.

=================


4.6.  Specification Required

    The intention behind "permanent and readily available" is that a
    document can reasonably be expected to be findable and retrievable
    long after assignment of the requested value.

SB> Do we need to comment on the cost of acquiring the specification?
SB> A text may be publicly available but at unaffordable cost. It may
SB> also be both copyright and out of print.

=================

4.12.  Using Multiple Policies in Combination

SB> An alternative to consider is to use a lower bar registration but reserve
SB> some values for the future.

=================


5.2.  The Role of the Designated Expert

    Designated experts are generally
    not expected to be "gatekeepers", setting out to make registrations
    difficult to obtain, unless the guidance in the defining document
    specifies that they should act as such.

SB> I wonder if "generally not expected to be" is strong enough?

    If a designated expert has a conflict of interest for a particular
    review (is, for example, an author or significant proponent of a
    specification related to the registration under review),

SB> The CoI is of course corporate, and it is generally best practise
SB> for an employee of the requesting organization not to act as
SB> ER for their employers codepoint requests.

==================


9.  Miscellaneous Issues

9.1.  When There Are No Actions

    Before an Internet-Draft can be published as an RFC, IANA Services
    needs to know what actions (if any) it needs to perform.  Experience
    has shown that it is not always immediately obvious whether a
    document has no actions, without reviewing the document in some
    detail.  In order to make it clear to IANA Services that it has no
    actions to perform (and that the author has consciously made such a
    determination), such documents should, after the authors confirm that
    this is the case, include an IANA Considerations section that states:

       This document has no actions.

    IANA Services prefers that these "empty" IANA Considerations sections
    be left in the document for the record: it makes it clear later on
    that the document explicitly said that no actions were needed (and
    that it wasn't just omitted).  This is a change from the prior
    practice of requesting that such sections be removed by the RFC
    Editor, and authors are asked to accommodate this change.

SB> I am wondering why this change of policy? It would have made
SB> sense in the past when drafts really were ephemeral, but now
SB> the full history of the drafts is available through datatracker
SB> we have a full audit trail.
SB> If anything we should be moving the other way from leaving
SB> the null section in to now taking it out.

=================


9.4.  Reclaiming Assigned Values
SB> A reference to RFC7274 might be a useful case study here.


12.  Security Considerations

This section considers protocol security.

As a process document do we need to consider the security and
auditability of the IANA process itself?

- Stewart