<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>

<rfc number="7370" category="std" submissionType="IETF" consensus="yes"
     ipr="pre5378Trust200902">
  <front>
    <title abbrev="IS-IS TLV Codepoints">Updates to the IS-IS TLV Codepoints
    Registry</title>

    <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>510 McCarthy Blvd.</street>

          <city>Milpitas</city>

          <code>95035</code>

          <region>CA</region>

          <country>USA</country>
        </postal>

        <email>ginsberg@cisco.com</email>
      </address>
    </author>

    <date month="September" year="2014"/>

    <area>Routing Area</area>

    <keyword>Codepoint</keyword>

    <abstract>
      <t>This document recommends some editorial changes to the IANA 
      "IS-IS TLV Codepoints" registry to more accurately document the
      state of the protocol. It also sets out new guidelines for
      Designated Experts to apply when reviewing allocations from the
      registry.</t>
    </abstract>

  </front>

  <middle>
    <section title="Introduction">
      <t>The "IS-IS TLV Codepoints" registry was created by <xref target="RFC3563"/> and
      extended by <xref target="RFC6233"/>. The assignment policy for the registry is "Expert
      Review" as defined in <xref target="RFC5226"/>. As documents related to
      IS&nbhy;IS are developed, the codepoints required for the protocol
      extensions are reviewed by the Designated Experts and added to the
      IANA-managed registry. As these documents are published as RFCs, the
      registries are updated to reference the relevant RFC.</t>

      <t>In the case of TLVs supporting prefix advertisement, currently
      separate sub&nbhy;TLV registries are maintained for each TLV. These
      registries need to be combined into a common sub&nbhy;TLV registry similar to
      what has been done for neighbor advertisement TLVs.</t>

      <t>In some cases, there is a need to allocate codepoints defined in
      Internet-Drafts (I-Ds) that seem likely to eventually gain Working Group
      approval, without waiting for those I-Ds to be published as RFCs.
      This can be achieved using Expert Review, and this document sets
      out guidance for the Designated Experts to apply when reviewing
      allocations from the registry.</t>

    <section title="Requirements Language">
      <t>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 RFC 2119 <xref target="RFC2119"/>.</t>
    </section>

    </section>

    <section title="IS Neighbor Sub-TLV Registry" anchor="IS_Neighbor">
      <t>There was an existing common sub-TLV registry named "Sub&nbhy;TLVs
      for TLVs 22, 141, and 222". <xref target="RFC5311"/> defines the
      IS Neighbor Attribute TLV (23) and the MT IS Neighbor Attribute TLV
      (223). The format of these TLVs is identical to TLVs 22 and 222,
      respectively. The IS Neighbor sub&nbhy;TLV registry has been extended
      to include these two TLVs. Settings for inclusion of each sub&nbhy;TLV
      are identical to the settings for TLVs 22 and 222, respectively.</t>

    </section>

    <section title="Prefix Reachability Sub-TLV Registry"
    anchor="prefix_reach">

      <t>Previously, there existed separate sub-TLV registries for TLVs
      135, 235, 236, and 237. As in the case of the IS Neighbor TLVs
      discussed in the previous section, assignment of sub&nbhy;TLVs applicable
      to one or more of these TLVs is intended to be common. Therefore,
      the existing separate sub&nbhy;TLV registries have been combined into a
      single registry entitled "Sub&nbhy;TLVs for TLVs 135, 235, 236, and 237".
      As existing sub&nbhy;TLV assignments are common to all the TLVs, this
      represents no change to the protocol -- only a clearer representation
      of the intended sub&nbhy;TLV allocation strategy. The format of the
      registry is as shown below:</t>

      <t><figure>
          <artwork><![CDATA[
Type  Description                       135 235 236 237  Reference
----  ------------                      --- --- --- ---  ---------
0     Unassigned
1     32-bit Administrative Tag Sub-TLV  y   y   y   y   [RFC5130]
2     64-bit Administrative Tag Sub-TLV  y   y   y   y   [RFC5130]
3-255 Unassigned
]]></artwork>
        </figure></t>
    </section>

    <section title="Guidance for Designated Experts" anchor="guidance">
      <t>When new I-Ds are introduced requiring new codepoints, it is
      advantageous to be able to allocate codepoints without waiting for them
      to progress to RFC. The reasons this is advantageous are described in
      <xref target="RFC7120"/>. However, the procedures in <xref target="RFC7120"/> for early allocation do not
      apply to registries, such as the "IS-IS TLV Codepoints" registry, that
      utilize the "Expert Review" allocation policy. In such cases, what is
      required is that a request be made to the Designated Experts who MAY
      approve the assignments according to the guidance that has been
      established for the registry concerned.</t>

      <t>The following guidance applies specifically to the "IS-IS TLV
      Codepoints" registry.</t>

      <t><list style="numbers">
          <t>Application for a codepoint allocation MAY be made to the
          Designated Experts at any time.</t>

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

          <t>In the case of Working Group documents, the Designated Experts
          SHOULD check with the Working Group chairs that there is consensus
          within the Working Group to make the allocation at this time. In the
          case of AD Sponsored documents, the Designated Experts SHOULD check
          with the AD for approval to make the allocation at this time.</t>

          <t>The Designated Experts SHOULD then review the assignment requests
          on their technical merit. The Designated Experts SHOULD NOT seek to
          overrule IETF consensus, but they MAY raise issues for further
          consideration before the assignments are made.</t>

          <t>Once the Designated Experts have granted approval, IANA will
          update the registry by marking the allocated codepoints with a
          reference to the associated document as normal.</t>

          <t>In the event that the document fails to progress to RFC, the
          Expiry and deallocation process defined in <xref target="RFC7120"/> MUST be
          followed for the relevant codepoints -- noting that the Designated
          Experts perform the role assigned to Working Group chairs.</t>
        </list></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This document provides guidance to the Designated Experts appointed
      to manage allocation requests in the "IS-IS TLV Codepoints" registry.</t>

      <t>IANA has updated the registry that was specified as "Sub-TLVs for
      TLVs 22, 141, and 222" to be named "Sub-TLVs for TLVs 22, 23, 141, 222,
      and 223".</t>

      <t>Per this document, the existing sub&nbhy;TLV registries for TLVs 135,
      235, 236, and 237 have been combined into a single registry --
      the "Sub&nbhy;TLVs for TLVs 135, 235, 236, and 237" registry -- as
      described in <xref target="prefix_reach"/>.</t>

    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document introduces no new security issues.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">

<reference anchor='RFC2119' target="http://www.rfc-editor.org/info/rfc2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
</author>
<date year='1997' month='March' />
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
</reference>

<reference anchor='RFC5130' target="http://www.rfc-editor.org/info/rfc5130">
<front>
<title>A Policy Control Mechanism in IS-IS Using Administrative Tags</title>
<author initials='S.' surname='Previdi' fullname='S. Previdi'>
<organization /></author>
<author initials='M.' surname='Shand' fullname='M. Shand'>
<organization /></author>
<author initials='C.' surname='Martin' fullname='C. Martin'>
<organization /></author>
<date year='2008' month='February' />
</front>
<seriesInfo name='RFC' value='5130' />
</reference>

<reference anchor='RFC5226' target="http://www.rfc-editor.org/info/rfc5226">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
</front>
<seriesInfo name='BCP' value='26' />
<seriesInfo name='RFC' value='5226' />
</reference>

<reference anchor='RFC5311' target="http://www.rfc-editor.org/info/rfc5311">
<front>
<title>Simplified Extension of Link State PDU (LSP) Space for IS-IS</title>
<author initials='D.' surname='McPherson' fullname='D. McPherson'>
<organization /></author>
<author initials='L.' surname='Ginsberg' fullname='L. Ginsberg'>
<organization /></author>
<author initials='S.' surname='Previdi' fullname='S. Previdi'>
<organization /></author>
<author initials='M.' surname='Shand' fullname='M. Shand'>
<organization /></author>
<date year='2009' month='February' />
</front>
<seriesInfo name='RFC' value='5311' />
</reference>

<reference anchor='RFC6233' target="http://www.rfc-editor.org/info/rfc6233">
<front>
<title>IS-IS Registry Extension for Purges</title>
<author initials='T.' surname='Li' fullname='T. Li'>
<organization /></author>
<author initials='L.' surname='Ginsberg' fullname='L. Ginsberg'>
<organization /></author>
<date year='2011' month='May' />
</front>
<seriesInfo name='RFC' value='6233' />
</reference>

<reference anchor='RFC7120' target="http://www.rfc-editor.org/info/rfc7120">
<front>
<title>Early IANA Allocation of Standards Track Code Points</title>
<author initials='M.' surname='Cotton' fullname='M. Cotton'>
<organization /></author>
<date year='2014' month='January' />
</front>
<seriesInfo name='BCP' value='100' />
<seriesInfo name='RFC' value='7120' />
</reference>

    </references>

    <references title="Informative References">

<reference anchor='RFC3563' target="http://www.rfc-editor.org/info/rfc3563">
<front>
<title>Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development</title>
<author initials='A.' surname='Zinin' fullname='A. Zinin'>
<organization /></author>
<date year='2003' month='July' />
</front>
<seriesInfo name='RFC' value='3563' />
</reference>

    </references>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The author wishes to thank Alia Atlas and Amanda Baber for their
      input in defining the correct process to follow to get these changes
      implemented. Special thanks to Adrian Farrel for crafting the text in
      <xref target="guidance"/>.</t>
    </section>

  </back>
</rfc>
