]>

Melbourne Australia mnot@mnot.net https://mnot.net/

Internet-Draft This document defines sub-policies that refine the Specification Required registry policy in RFC 8126. About This Document Status information for this document may be found at . information can be found at . Source for this draft and an issue tracker can be found at .

Introduction currently defines Specification Required as:

• For the Specification Required policy, review and approval by a designated expert (see Section 5) is required, and the values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. This policy is the same as Expert Review, with the additional requirement of a formal public specification. In addition to the normal review of such a request, the designated expert will review the public specification and evaluate whether it is sufficiently stable and permanent, and sufficiently clear and technically sound to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path, including informal documentation.

goes on to enumerate common issues encountered in use of Specification Required, including use of Internet-Drafts as the citation, purchase-only specifications, and citing non-IETF standards. While this text offers improved clarity over the currently in-force guidance, it does not address specifications that are defined outside formal standards processes. In some registries, it is increasingly common for registration requests to come from Open Source projects, community groups and non-profits, and motivated individuals. At the same time, "permanent and readily available" is now arguably achievable for even the most ephemeral resource, thanks to cheap perpetual Web hosting (e.g., on GitHub) and archiving services (such as archive.org). suggests sub-policies of the Specification Required policy, with the aim of clarifying these situations. For a sub-policy to take effect, a given registry would need to opt into its use; note that there is no default, as existing registries may have already established relevant practices. Future revisions of this document might explore the mechanics of how a registry adopts a sub-policy (e.g., whether a revision of the registry specification is necessary, vs. an IESG or Expert declaration).

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Specification Required Sub-Policies

Specification Required (Standards) The "Standards" sub-policy of Specification Required adds a requirement that the cited specification(s) MUST be under the control of and published by an organization listed in the "IESG-Recognized Standards-Related Organizations" registry described in . This sub-policy explicitly precludes registrations using Internet-Drafts as the basis of a registration. However, IETF efforts are still eligible for early allocation, per . Likewise, specifications from recognized organizations do not qualify for registration until they have completed the relevant approval processes in those organizations. However, preliminary and in-progress specifications might qualify for early allocation, per . Organizations that appear in the "IESG-Recognized Standards-Related Organizations" registry are assumed to have met the "permanent and readily available" requirement for the purposes of this sub-policy, even if they charge for access to the specification. However, such organizations MUST provide a free copy to the Expert(s) for review.

Specification Required (Community) The "Community" sub-policy of Specification Required adds a requirement that the cited specification(s) MUST either qualify under the Standards sub-policy (), or in the opinion of the Expert(s) be the product of a significant community effort. The Expert(s) SHOULD take the following factors into consideration when determining whether a specification is the product of a significant community effort:

• The specification is well-defined and complete
• The specification is freely available to the public at a permanent and readily available location
• The specification is not tied to or heavily associated with one implementation
• There are multiple interoperable implementations of the specification, or such implementations are likely to emerge
• There is evidence of broad adoption
• The use case addressed by the specification is using the registry's extension point appropriately
• The requested value is appropriate to the use case, and not so generic that it may be considered 'squatting'

The Expert(s) have discretion in applying these criteria; in some cases, they might judge it best to register a value that fails one or more. The intent is to assure that successfully deployed community efforts have registered values. As such, the criteria above are designed to preclude anticipatory registrations. In addition, the Expert(s) MAY define additional guidance and criteria for managing the name space of the registry (e.g., to avoid "squatting" on values that are likely to be standardized). Specifications whose registration is deemed to be the product of a significant community effort are not eligible for early allocation.

Specification Required (Permissive) The "Permissive" sub-policy of Specification Required explicitly allows registration of a specification, regardless of who publishes it, that meets the requirements set by . This includes but is not limited to:

• Archived Internet-Drafts
• GitHub repositories and similar data stores
• Publicly available archive services

To qualify as "permanent and readily available", a specification SHOULD NOT be able to be made unavailable by the arbitrary decision or action of a single person. This precludes, for example, personal Web sites and personal GitHub repositories as suitable specification references, but MAY permit those operated by groups of people. Note that this requirement only applies to provision of the specification, not authorship. Note that {Section 4.6 of I-D.ietf-ianabis-rfc8126bis}} also requires a specification to be 'in sufficient detail so that interoperability between independent implementations is possible.' The Expert(s) determine this on a case-by-case basis, using any guidance available in the document(s) establishing the registry. The Expert(s) MAY define additional guidance and criteria for managing the name space of the registry (e.g., to avoid "squatting" on values that are likely to be standardized). When this sub-policy is in effect, only registrations that qualify under the Standards sub-policy () are eligible for early allocation.

IANA Considerations This document has no direct tasks for IANA, but will need to be operationalised by them.

Security Considerations The security considerations of apply.

Normative References Internet Assigned Numbers Authority Internet Assigned Numbers Authority Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the fourth edition of this document; it obsoletes RFC 8126. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet Assigned Numbers Authority Internet Assigned Numbers Authority This document describes the requirements for securing IANA code point assignments for IETF Stream Internet-Drafts and specifications being drafted by other standards-related organizations. This document obsoletes RFC 7120.