<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.14 (Ruby 2.6.10) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

<!ENTITY RFC5029 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5029.xml">
]>


<rfc ipr="trust200902" docName="draft-li-lsr-labv-registration-00" category="std" consensus="true" submissionType="IETF" updates="5029">
  <front>
    <title abbrev="Link-Attribute Bit Values Registration">Revision to Registration Procedures for IS-IS Neighbor Link-Attribute Bit Values</title>

    <author initials="T." surname="Li" fullname="Tony Li">
      <organization>Juniper Networks</organization>
      <address>
        <email>tony.li@tony.li</email>
      </address>
    </author>

    <date year="2024" month="April" day="18"/>

    
    
    

    <abstract>


<t>RFC 5029, "Definition of an IS-IS Link Attribute Sub-TLV", defines a
registry for "IS-IS Neighbor Link-Attribute Bit Values".  This
document changes the registration procedure for that registry from
"Standards Action" to "IETF Review".</t>



    </abstract>



  </front>

  <middle>


<section anchor="introduction"><name>Introduction</name>

<t><xref target="RFC5029"/> defines the "IS-IS Neighbor Link-Attribute Bit Values"
registry and specifies a registration procedure of "Standards
Action". In practice, this registration procedure is unnecessarily
restrictive, as it prevents allocation of bits to experimental
protocols, which in turn increases the risk of conflicts introduced by
use of unregistered code points (so-called "code point squatting").</t>

<t>Accordingly, this document revises the registration procedure for the
registry, as described in <xref target="IANA"/>.</t>

</section>
<section anchor="IANA"><name>IANA Considerations</name>

<t>The registration procedure for the "IS-IS Neighbor Link-Attribute Bit
Values" registry is revised to be "IETF Review".</t>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>This document does not affect the security issues discussed in RFC
5029.</t>

</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>The author would like to thank John Scudder for his contributions.</t>

</section>


  </middle>

  <back>


    <references title='Normative References'>

&RFC5029;


    </references>




  </back>

<!-- ##markdown-source:
H4sIAKSQIWYAA41U74saMRD9nr9i2PvSghE5KPT8VHvtgcdxlFPuezaZdQdj
YvNDK+L/3smunrblqILs7mSSefPey0gphfaG3GIMOTXys0iULI7hBTcUyTtI
nt8XFFNQqXz/CF6jyQEjND7AdCanM3hGWrQ1fz6RW8pJSoHqnBC+UoJXZTNG
oeo64Gb8fsYfZYTx2qkVAzFBNUlakjYGaVW9keEiT45GQquECx92Y4jJiJjr
FcUCPe3WvH/6ff4gaB3GkEKO6XY0uhvdirw2vCuO4dPo9k4IlVPrw1gASP53
P3K8Oh8y3lOkxzP3bncR9IGZe8yO1hiYhrT1YRlPi7hSZLkwbxla+nJ8CuF8
WDH8DZaKLw/3BcRYCCklqLq0ppMQHO/QDaD6hg056uj3DSh3ZL1QCWcqZ7mW
86fXagCm5DOjShy52nVaVdeKVQ0B5i3FokJeoUugW+UWfGJqES75h/XJDl2F
1KoE55rBr0Q1S8oZFUyEiS5bqmKpqsjSmQy31bBvfUXGWBTiBqYuBW9yly7E
fn+k6HB466zguL6dMw0MBeIaNTVU+HmvF2b5jFsccQ8ZF+ewOKRxwBAovref
V7JzqDFGFcjuGABnkS6aD0BFYGxrvg5MLaOw1mt1UrcmDjFD+IsdRYV8ZQWf
nLz2Ng5g25Ju2Z2QcnD81AFVPClDcVnO0N41lqtxnSOTaKDeiRy71rLrYWPg
MN9+hLWnguRD9FIzHA5X5zjEn1mlxDOi+shSTbT2oUwMuzuS8OaSUIbGNS7B
N0U6NgxGzapxWe5rv59OnieHw7BzAr/CvXeRDPZnRdjfdAlCzP9b5gqPiKNH
zrbtZC2NmKJDjf+Y9QZmqHOgtPsLWoF0yYfxTIbzCVTToE4donjaykOqTD1D
UecY+97Z6KI4vSsy0UvntyzGAstpsW+4H1Ww9dkasLTEApLvHY+CR986mOls
GFDHQAHDXui7LQD53N9xoGDW8gUAAA==

-->

</rfc>

