Put Your Internet Draft/RFC Title Here

Introduction The current Guidelines for Writing an IANA Considerations Section in RFCs 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 in the last quarter of 2022 about reconciling the Standards Track or IESG Approved Experimental requirement for SMTP registries 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 and documents generated in other WGs with similar requirements. This draft is being posted at this time in the hope of moving the process along by specifying an update to RFC 8126 rather than waiting for a revision to it. 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 and RFC 8174 when, and only when, they appear in all capitals, as shown here.

Definition of "Hybrid" Registration Policy 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. 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 .

IETF Review and Approval 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, but involves a stronger preference for a Standards Track or Experimental publication as a result.

Simple Registration 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 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..

Options for Registry Structure 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.

List of Required or Recommended Information The following information must be supplied for all registrations under either option.

the textual name being registered;
Contact information for the submitter or other responsible party and identification of the change controller. The change controller value MUST be "IETF" for all registrations using the first option and MUST provide appropriate authority and contact information for all other extensions.

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".

Acknowledgements This policy description was derived from work originally done for by the EMAILCORE working group and its participants is gratefully acknowledged. The specification is also heavily dependent on RFC 8126 and its authors.

IANA Considerations This memo is entirely about specification of a new well-known registration policy, adding to those in RFC 8126.

Security Considerations See the Security Considerations section of RFC 8126. This specification does not change that description in any way.