Hybrid IANA Registration Policy
draft-klensin-iana-consid-hybrid-02

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]