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