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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





   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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]