wdiff rfc9029xml2.original.xml rfc9029.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7752 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7752.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
]> "rfc2629-xhtml.ent">

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-idr-bgp-ls-registry-05" ipr="trust200902" updates="7752"> updates="7752" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3" number="9029" consensus="true">

  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <front>
    <title abbrev="BGP-LS Registry Update">Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries</title>
    <seriesInfo name="RFC" value="9029"/>
    <author fullname="Adrian Farrel" initials="A." surname="Farrel">
      <organization>Old Dog Consulting</organization>
      <address>
        <email>adrian@olddog.co.uk</email>
      </address>
    </author>
    <date month="" month="June" year="2021"/>
    <area>Routing Area</area>
    <workgroup>IDR Group</workgroup>
    <keyword>BGP-LS</keyword>
    <keyword>IANA</keyword>
    <abstract>
      <t>RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).  IANA created
         a registry consistent with that document called the "Border Gateway Protocol - Link
         State (BGP-LS) Parameters Registry" Parameters" with a number of sub-registries. subregistries.  The
         allocation policy applied by IANA for those registries is "Specification Required" Required",
         as defined in RFC 8126.</t>
      <t>This document updates RFC 7752 by changing the allocation policy for all of
         the registries to "Expert Review" and by updating the guidance to the Designated
         Experts.</t> designated
         experts.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction">
      <t>Border Gateway Protocol - Link State (BGP-LS) numbered="true" toc="default">
      <name>Introduction</name>
      <t>"North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP" <xref target="RFC7752" /> format="default"/> requested IANA to create
         a registry called the "Border Gateway Protocol - Link State (BGP-LS)
         Parameters Registry"
         Parameters" with a number of sub-registries. subregistries.  The allocation policy
         applied by IANA for those registries is "Specification Required" Required", as defined in
      <xref target="RFC8126" />.</t> format="default"/>.</t>
            <t>The "Specification Required" policy requires evaluation of any assignment
         request by a "Designated Expert" "designated expert", and guidelines for any such experts are
         given in section 5.1 of <xref target="RFC7752" />. sectionFormat="of" section="5.1"/>.  In addition, this policy requires that "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" <xref target="RFC8126" />. format="default"/>.
         Further, 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" <xref target="RFC8126" />.</t> format="default"/>.</t>
      <t>Another allocation policy called "Expert Review" is defined in <xref target="RFC8126" />. format="default"/>.
         This policy also requires Expert Review, Review but has no requirement for a
         formal document.</t>
      <t>All reviews by Designated Experts designated experts are guided by advice given in the
         document that defined the registry and set the allocation policy.</t>
      <t>This document updates RFC 7752 <xref target="RFC7752" format="default"/> by changing the allocation policy for all of
         the registries to "Expert Review" and updating the guidance to the
         Designated Experts.</t>
         designated experts.</t>
      <section title="Requirements Language">
        <t>The numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
           "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
           "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" /> target="RFC2119"/> <xref target="RFC8174" /> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA maintains a registry called the "Border Gateway Protocol - Link State (BGP-LS) Parameters Registry". Parameters".
         This registry contains four sub-registries:
         <list style="symbols">
           <t>BGP-LS NLRI-Types</t>
           <t>BGP-LS subregistries:
      </t>
      <ul spacing="normal">
        <li>BGP-LS NLRI-Types</li>
        <li>BGP-LS Protocol-IDs</li>
        <li>BGP-LS Well-Known Instance-IDs</li>
        <li>BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs</t>
           <t>BGP-LS Protocol-IDs</t>
           <t>BGP-LS Well-Known Instance-IDs</t>
         </list></t> TLVs</li>
      </ul>
      <t>IANA is requested to change has changed the assignment policy for each of these registries to "Expert Review".</t>
      <t>IANA has also added this document as a reference for the registries mentioned above.</t>
      <section anchor="expert" title="Guidance numbered="true" toc="default">
        <name>Guidance for Designated Experts">

        <t>Section 5.1 of <xref Experts</name>

<t><xref target="RFC7752" /> sectionFormat="of" section="5.1"/> gives guidance to Designated Experts. designated experts.  This section replaces that guidance.</t>

        <t>In all cases of review by the Designated Expert (DE) designated expert described here,
           the DE designated expert is expected to check the clarity of purpose and use of the
           requested code points.  The following points apply to the registries
           discussed in this document:

           <list style="numbers">

             <t>Application

        </t>
        <ol spacing="normal" type="1">
          <li>Application for a code point allocation may be made to the
                Designated Experts at any time.</t>

             <t>Application for a code point allocation may be made to the
                Designated Experts
                designated experts at any time, time and MUST <bcp14>MUST</bcp14> be accompanied
                by technical documentation explaining the use of the code
                point.  Such documentation SHOULD <bcp14>SHOULD</bcp14> be presented in the
                form of an Internet-Draft, Internet-Draft but MAY <bcp14>MAY</bcp14> arrive in any form that
                can be reviewed and exchanged amongst reviewers.</t>

             <t>The Designated Experts SHOULD reviewers.</li>
          <li>The designated experts <bcp14>SHOULD</bcp14> only consider requests that arise
                from I-Ds Internet-Drafts that have already been accepted as Working Group working group
                documents or that are planned for progression as AD Sponsored AD-Sponsored
                documents in the absence of a suitably chartered Working Group.</t>

             <t>In working group.</li>
          <li>In the case of Working Group working group documents, the Designated Experts
                MUST designated experts
                <bcp14>MUST</bcp14> check with the Working Group working group chairs that there is
                consensus within the Working Group working group to make the allocation at this
                time.  In the case of AD Sponsored AD-Sponsored documents, the Designated
                Experts MUST designated
                experts <bcp14>MUST</bcp14> check with the AD for approval to make the
                allocation at this time.</t>

             <t>If time.</li>
          <li>If the document is not adopted by the IDR Working Group (or its
                successor), the Designated Expert MUST designated expert <bcp14>MUST</bcp14> notify the IDR mailing list
                (or its successor) of the request and MUST <bcp14>MUST</bcp14> provide access to the
                document.  The Designated Expert MUST designated expert <bcp14>MUST</bcp14> allow two weeks for any response.
                Any comments received MUST <bcp14>MUST</bcp14> be considered by the Designated Expert designated expert
                as part of the subsequent step.</t>

             <t>The Designated Experts MUST step.</li>
          <li>The designated experts <bcp14>MUST</bcp14> then review the assignment requests
                on their technical merit.  The Designated Experts MAY designated experts <bcp14>MAY</bcp14> raise
                issues related to the allocation request with the
                authors and on the IDR (or successor) mailing list
                for further consideration before the assignments
                are made.</t>

             <t>The Designated Expert MUST made.</li>
          <li>The designated expert <bcp14>MUST</bcp14> ensure that any request for
                a code point does not conflict with work that is active or already
                published within the IETF.</t>

             <t>Once IETF.</li>
          <li>Once the Designated Experts designated experts have granted approval, IANA will
                update the registry by marking the allocated code points with a
                reference to the associated document.</t>

             <t>In document.</li>
          <li>In the event that the document is a Working Group working group document or is
                AD Sponsored, and that document fails to progress to publication
                as an RFC, the Working Group working group chairs or AD SHOULD <bcp14>SHOULD</bcp14> contact IANA
                to coordinate about marking the code points as deprecated.  A
                deprecated code point is not marked as allocated for use and is not
                available for allocation in a future document.  The WG chairs may
                inform IANA that a deprecated code point can be completely
                de-allocated
                deallocated (i.e., made available for new allocations) at any time
                after it has been deprecated if there is a shortage of unallocated
                code points in the registry.</t>

           </list></t> registry.</li>
        </ol>
      </section>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The security consideration of considerations described in <xref target="RFC7752" /> sectionFormat="of" section="8"/> still apply.</t>
      <t>Note that the change to the expert review Expert Review guidelines makes the registry and the Designated Experts designated experts slightly more
         vulnerable to denial of service denial-of-service attacks through excessive and bogus requests for code points.  It is expected that
         the registry cannot be effectively attacked because the Designated Experts designated experts would, themselves, fall to any such
         attack first.  Designated Experts experts are expected to report to the IDR working group Working Group chairs and responsible Area
         Director if they believe an attack to be in progress, progress and should immediately halt all requests for allocation.
         This may temporarily block all legitimate requests until mitigations have been put in place.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
    </references>
    <section anchor="Acknowledgements" title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>This work is based on the IANA considerations section of Considerations described in <xref target="RFC7752" />. sectionFormat="of" section="5"/>.  The author thanks the people who worked on that document.</t>
      <t>The author would like to be able to thank John Scudder <contact fullname="John Scudder"/> for suggesting the need for this document.</t>
      <t>Thanks to John Scudder, Donald Eastlake, Ketan Talaulikar, and Alvaro Retana <contact fullname="John Scudder"/>, <contact fullname="Donald Eastlake 3rd"/>, <contact fullname="Ketan Talaulikar"/>, and <contact fullname="Alvaro Retana"/> for their review, comments, and discussion.</t>
      <t>Additional thanks to Gyan Mishra, Acee Lindem, Ketan Talaulikar, Les Ginsberg, Bruno Decraene, Benjamin Kaduk,
        and Martin Vigoureux <contact fullname="Gyan Mishra"/>, <contact fullname="Acee Lindem"/>, <contact fullname="Ketan Talaulikar"/>, <contact fullname="Les Ginsberg"/>, <contact fullname="Bruno Decraene"/>, <contact fullname="Benjamin Kaduk"/>,
        and <contact fullname="Martin Vigoureux"/> for engaging in discussion on the details of this work.</t>
    </section>

  </middle>

  <back>

    <references title="Normative References">
      &RFC2119;
      &RFC7752;
      &RFC8126;
      &RFC8174;
    </references>
  </back>
</rfc>