| Internet-Draft | Abbreviated Title | October 2024 |
| Klensin | Expires 23 April 2025 | [Page] |
The current Guidelines for Writing an IANA Considerations Section in RFCs specifies ten well-known registration policies. Since it was published in 2017, the IETF's focus for many registries has evolved away from the notion of strong IETF review and consensus toward trying to be sure names are registered to prevent conflicts. Several of the policies that were heavily used in the past appear to present too high a barrier to getting names into registries to prevent accidental reuse of the same strings. This specifies an eleventh well-known policy that avoids the implied tension, essentially combining two of the existing policies.¶
When the first (and trivial second) versions of this draft were posted, there was some expectation that a revision to RFC 8126 was under active development and that either the new registration policy described below would be incorporated into it or at least this document could be discussed in that context. In the subsequent six months, there has been no public sign of progress on the revision so the I-D is being reposted (with minor changes) in the hope of at least stimulating a discussion or possibly having its contents considered by the IETF.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 23 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The current Guidelines for Writing an IANA Considerations Section in RFCs [RFC8126] specifies ten well-known registration policies. Since those Guidelines were published in 2017, the IETF's focus for many registries has evolved away from the notion of strong IETF review and consensus toward trying to be sure names are registered to prevent conflicts. Several of the policies that were heavily used in the past appear to prevent too high a barrier to getting names into registries to prevent accidental reuse of the same strings. This document specifies an eleventh well-known policy that avoids the implied tension, essentially combining two of the existing policies.¶
This policy is expected to be most useful for registries for keywords or parameters that denote extensions or options for protocols and the specification is written with that use in mind. However it is not restricted to that type of use.¶
RFC Editor: The following paragraph should probably be removed or drastically rewritten before publication.¶
This new policy was motivated by discussions in the EMAILCORE WG [EMAILCORE] in the last quarter of 2022 about reconciling the Standards Track or IESG Approved Experimental requirement for SMTP registries [RFC5321] [MailParamsIANARegistry] with getting keywords registered to prevent conflicts. Similar requirements or tensions have subsequently been discovered and discussed in the context of several other documents. The hope (and expectation) during the EMAILCORE discussions was that the mechanism would swiftly be incorporated into a revision of RFC 8126, eliminating the need for specification-specific text in rfc5321bis [rfc5321bis] and documents generated in other WGs with similar requirements. The initial versions of this draft were posted in August 2023 in the hope that specifying an update to RFC 8126, rather than waiting for a revision to it, would stimulate progress. It is now hoped that it contributes to discussions of a revision to RFC 8126 that are expected to start with IETF 121.¶
The realization underlying this "hybrid" or "two options" model is that, while there is a clear community interest in having a mechanism for registering names to prevent naming conflicts and keeping the effort required to do so as low as possible, there is an equally strong interest in having keywords and associated definitions carefully considered by the community in the hope of improving clarity and interoperability. For a given specification, the choice should lie with those who intend to promote or use the keyword, not a decision made when the registry is defined that applies to all keywords associated with it.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] and RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Note in draft: although text specific to SMTP and its registries has been removed or generalized, the following was extracted and rewritten from draft-ietf-emailcore-rfc5321bis-19 (and still present in the IETF Last Call version, draft-ietf-emailcore-rfc5321bis-31).¶
The would-be registrant shall pick between the options described in the two subsections below although, if the first is attempted and proves unsuccessful, the second may then be chosen. Similarly, a registration may be made under the second option and then processed in the IETF and updated to the first one. A specification using this policy MUST specify the information to be provided by the registrant as described in Section 2.4.¶
The document goes through the normal IETF review and approval process, cumulating in a published Standards Track, BCP, Experimental, or, in rare cases specifically approved by the IESG, an IETF Stream Informational RFC. The intent is that the registration and the underlying specification will represent careful IETF community review and consensus on its technical merits, utility, and clarity of explanation. The change controller for all such registrations and specifications will be the IETF.¶
This option is approximately equivalent to "IETF Review" as described in RFC 8126/ BCP 26 [RFC8126], but involves a stronger preference for a Standards Track or Experimental publication as a result.¶
The sole purpose of this option is to get the keyword value and contact information registered in order to minimize the risk of the same name being used by different parties for different purposes. The intent is that there be no barrier to such registrations other than the time and effort required to submit the request itself. Registrants are encouraged to provide documentation of the meaning of the keyword and any underlying extension or parameter, their interactions with other specifications, etc., and to consult individuals or groups with relevant experience for advice, but none of that is required. The change controller for all such extensions will be the registrant unless otherwise specified in the registration request.¶
Even if this option is chosen, it is expected that registrants will supply all of the information in the list in Section 2.4 below or in the protocol specification establishing the particular registry as either part of the registration or in supplemental documents that will be referenced from the registry. However, the primary goals of getting extensions registered using this option are to avoid conflicts about naming (e.g., two different deployed extensions with the same name or keyword) and to either identify a stable and generally available specification or to establish contact information for additional information. Consequently, if some of the information requested is not available for some of the specified items, the registry entry should be made with the absence of such data noted in the registry as "Not supplied".¶
This model is approximately equivalent to "First Come First Served" as described in RFC 8126/ BCP 26. [RFC8126].¶
When this policy is used, the option chosen should be identified for each registry entry. In general, that should be accomplished by use of a flag or similar indication for each registry but there may be circumstances in which two subregistries would be more appropriate. A specification using the policy should either specify how the information will be recorded or leave that explicitly to IANA's discretion.¶
The following information must be supplied for all registrations under either option.¶
The specification using this policy for a registry SHOULD indicate what additional information is required or preferred for that registry. As indicated above, for the second option, there should generally be no requirements other than the above and possibly a statement of the purpose of the registration; other information may be identified as "Not supplied".¶
This policy description was derived from work originally done for [rfc5321bis] by the EMAILCORE working group [EMAILCORE] and its participants is gratefully acknowledged as are IANA reviews of, and suggestions about, that draft. The specification is also heavily dependent on RFC 8126 and its authors.¶
This memo is entirely about specification of a new well-known registration policy, adding to those in RFC 8126.¶
See the Security Considerations section of RFC 8126 [RFC8126]. This specification does not change that description in any way.¶
RFC Editor: Please remove this appendix before publication.¶