<?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-ietf-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="May" day="20"/>

    
    
    

    <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 "Expert 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 changes 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 changed to be "Expert 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:
H4sIAGh+S2YAA5WUUWvbQAzH3+9TCPdlgziEwmDN07KuhZRSRhP6fr6TYxHn
LrvTJQsh3306O2mysbIuEGzLOumnv2SVZamMt+QWY0hcl58VE7c4hmfcUCTv
gL3cLyhy0Jyfvwdv0KaAEWofYDorpzN4Qlo0lTw+kluWE+ZAVWKEr8TwotuE
UemqCrgZv+3xWxplvXF6JSA26JpLQoFrYyhbXW3KcOFZjkbKaMaFD7sxRLYq
pmpFMcPzbi0Rpnfze0XrMAYOKfL1aHQzulZpbeVUHMOn0fWNUjpx48NYAZTy
737k5O18KMQnS0809253YfRBtHtIjtYYRAje+rCMp5e40tRKYjkybOnL8aqU
82El+BvMGZ/vbzPEWKmyLEFXuTTDSom9oxtA8Q1rctQ1wNeg3VH3LCacxZyl
qpw/vhQDsNlfNNXqqNWu61bx3nYVQ4B5QzH3Ia3QMZhGu4VE5AbhUn9Ynwai
y8CNZjjnDH6lihlrZ3WwESYmHynyUBV3P0Uw7gYNt8WwL35F1rao1BVMHQdv
U3dAqf3+KNLh8FpbJnl/QWchBAbiGg3VlBV6qxrR+UyujuRD4RIfaQ8ZHAgC
xbfOy5vkHBqMUQdqdwIgXmRy1wegIwjbWj4JEVco2tYbfepvRWISjTBLRFl+
3SqJzN74Ng5g25BpZD6BU3ByNQF1PPWG4jLHMN7VrWSTPEcl0UK1Uyl2pSXX
Y2MQs2wAhLWnTPIh+tIIjpiLsx3ij6SZZU8UH6VVE2N8yFuj3R1F+P85wdeO
dGpYjEa6Jmmlrv1+OnmaHA7DbhLkFm69i2SxjxVhf9U5KDX/Z5p3zIg6zsh5
cKWivhCb+1DhX8b1CmZoUiDe/QGXoS4VsV7kcJ5B1zUa7pji6agsqrz7LEWT
Yuyrl1FXeda7JBOzdH4r7Vhgjhb7kvt1BVufWgstLTFjyrcn6+DBNw5mJlkB
6jTIMDINfb0ZUOL+Ag3v+rz4BQAA

-->

</rfc>

