Internet DRAFT - draft-klensin-iana-consid-hybrid
draft-klensin-iana-consid-hybrid
IETF J.C. Klensin
Internet-Draft 9 February 2024
Updates: 8126 (if approved)
Intended status: Best Current Practice
Expires: 12 August 2024
Hybrid IANA Registration Policy
draft-klensin-iana-consid-hybrid-02
Abstract
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.
Note
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.
Status of This Memo
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/.
Klensin Expires 12 August 2024 [Page 1]
Internet-Draft Abbreviated Title February 2024
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 12 August 2024.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definition of "Hybrid" Registration Policy . . . . . . . . . 4
2.1. IETF Review and Approval . . . . . . . . . . . . . . . . 4
2.2. Simple Registration . . . . . . . . . . . . . . . . . . . 4
2.3. Options for Registry Structure . . . . . . . . . . . . . 5
2.4. List of Required or Recommended Information . . . . . . . 5
3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
A.1. Changes from version -00 (2023-08-06) to -01 . . . . . . 7
A.2. Changes from version -01 (2023-08-07) to -02 . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
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
Klensin Expires 12 August 2024 [Page 2]
Internet-Draft Abbreviated Title February 2024
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. 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
[RFC2119] and RFC 8174 [RFC8174] when, and only when, they appear in
all capitals, as shown here.
Klensin Expires 12 August 2024 [Page 3]
Internet-Draft Abbreviated Title February 2024
2. 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 Section 2.4.
2.1. 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 [RFC8126], but involves a stronger preference for
a Standards Track or Experimental publication as a result.
2.2. 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 Section 2.4 below or in
the protocol specification establishing the particular registry as
Klensin Expires 12 August 2024 [Page 4]
Internet-Draft Abbreviated Title February 2024
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].
2.3. 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.
2.4. List of Required or Recommended Information
The following information must be supplied for all registrations
under either option.
(1) the textual name being registered;
(2) 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".
Klensin Expires 12 August 2024 [Page 5]
Internet-Draft Abbreviated Title February 2024
3. Acknowledgements
This policy description was derived from work originally done for
[rfc5321bis] by the EMAILCORE working group [EMAILCORE] and its
participants is gratefully acknowledged. The specification is also
heavily dependent on RFC 8126 and its authors.
4. IANA Considerations
This memo is entirely about specification of a new well-known
registration policy, adding to those in RFC 8126.
5. Security Considerations
See the Security Considerations section of RFC 8126 [RFC8126]. This
specification does not change that description in any way.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
[EMAILCORE]
IETF, "IETF EMAILCORE WG", 10 March 2021,
<https://datatracker.ietf.org/wg/emailcore/about/>.
[MailParamsIANARegistry]
Internet Assigned Number Authority (IANA), "Mail
Parameters", 2022, <https://www.iana.org/assignments/mail-
parameters/mail-parameters.xhtml>.
Klensin Expires 12 August 2024 [Page 6]
Internet-Draft Abbreviated Title February 2024
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[rfc5321bis]
Klensin, J., "Simple Mail Transfer Protocol", 9 February
2024, <https://datatracker.ietf.org/doc/draft-ietf-
emailcore-rfc5321bis/>.
Appendix A. Change Log
RFC Editor: Please remove this appendix before publication.
A.1. Changes from version -00 (2023-08-06) to -01
* The only substantive difference between this two versions was a
correction to the title. In the original (-00) version, it had
not been adjusted from a template.
A.2. Changes from version -01 (2023-08-07) to -02
* Small update to reflect activity in the last six months, including
updating a reference.
Author's Address
John C Klensin
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
United States of America
Email: john-ietf@jck.com
Klensin Expires 12 August 2024 [Page 7]
