<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that
    most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-idr-capabilities-registry-change-00.txt"
ipr="trust200902" updates="5492">
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: full3667, noModification3667, noDerivatives3667
    you can add the attributes updates="NNNN" and obsoletes="NNNN"
    they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="Capability Codes Registration Procedures">
    Revision to Capability Codes Registration Procedures</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="John Scudder" initials="J.S."
            surname="Scudder">
      <organization>Juniper Networks</organization>

      <address>
        <postal>
          <street>1194 N. Mathilda Ave</street>

          <!-- Reorder these if your country does things differently -->

          <city>Sunnyvale</city>

          <region>CA</region>

          <code>94089</code>

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

        <email>jgs@juniper.net</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2018" />

    <!-- Meta-data Declarations -->

    <area>General</area>

    <workgroup>Network Working Group</workgroup>

    <keyword>IDR</keyword>

<abstract>
<t>
	This document updates RFC 5492 by making a change to the
	registration procedures for BGP Capability Codes. Specifically, the
	range formerly designated "Reserved for Private Use" is divided into
	three new ranges, respectively designated as "First Come First Served",
	"Experimental" and "Reserved".
</t>
</abstract>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
	<xref target="RFC5492"/> designates the range of Capability Codes
	128-255 as "Reserved for Private Use". Subsequent experience has
	shown this to be not only useless, but actively confusing to
	implementors.  BGP Capability Codes do not meet the criteria for
	"Private Use" described in <xref target="RFC8126"/> 
	S. 4.1. An example of a legitimate "private use" code point might be 
	a BGP <xref target="RFC1997">community</xref> value assigned for use
	within a given AS, but no analogous use of Capabilities exists.
</t>
<t>
	Accordingly, this document revises the registration procedures for
	the range 128-255, as follows, using the terminology defined in
	<xref target="RFC8126"/>:
</t>
<t>
	128-238: First Come First Served
</t>
<t>
	239-254: Experimental Use
</t>
<t>
	255: Reserved
</t>
<t>
	The procedures for the ranges 1-63 and 64-127 are unchanged,
	remaining "IETF Review" and "First Come First Served" respectively.
</t>
</section>

<section anchor="discussion" title="Discussion">
<!--<t>
	The reason for choosing Standards Action and not some other policy
	is that it provides opportunity for working group oversight of the
	space, when and if it becomes depleted. At time of writing there is
	ample space available in both the IETF Review and First Come First
	Served portions of the 1-127 range. Note that any unallocated space
	in this range can be reclassified with some other allocation policy
	in the future, if needed.
</t>-->
<t>
	The reason for providing an Experimental Use range is to preserve a
	range for use during early development. Although there are few
	practical differences between Experimental and Private Use, the
	change both makes it clear that code points from this space should
	not be used long-term or in shipping products, and reduces the
	consumption of the scarce Capability Code space expended for this
	purpose. Once classified as Experimental, it should be considered
	difficult to reclassify the space for some other purpose in the
	future.
</t>
<t>
	The reason for reserving the maximum value is that it may be useful
	in the future if extension of the number space is needed.
</t>
<t>
	We note that since the range 128-255 was formerly
	ungoverned, implementors may have chosen to use code points within
	that range prior to publication of this document. Although it is
	not possible to know what code points implementors may have used,
	experience suggests 128 is a likely value. For that reason, this
	document asks IANA to reserve that value, to minimize the risk of
	conflict with existing implementations.
</t>
<t>
    Finally, we invite implementors who have used values in the range
    128-255 to contribute to this draft, so that the values can be
    included in the registry.
</t>
</section>

<section anchor="IANA" title="IANA Considerations">
<t>
	IANA is requested to revise the "Capability Codes" registry as
	described in <xref target="introduction"/>. Since the range
	128-238 is adjacent to the existing First Come First Served range, 
	after this change the entire First Come First Served range will
	be 64-238.
</t>
<t>
	IANA is requested to allocate value 128 as "Reserved".
</t>
</section>

<section anchor="Security" title="Security Considerations">
<t>
	This revision to registration procedures does not change the
	underlying security issues inherent in the existing <xref
	target="RFC5492"/> and <xref target="RFC4271"/>.
</t>
</section>

<section anchor="Acknowledgements" title="Acknowledgements">
<t>
	Thanks to Alia Atlas, Bruno Decraene, Jeff Haas, Sue Hares and Thomas Mangin for review and
	comments.
</t>
</section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <!--?rfc include=
      "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      
	  <?rfc include="reference.RFC.5492.xml"?>
	  <?rfc include="reference.RFC.8126.xml"?>
    </references>
    
    <references title="Informative References">
      <?rfc include="reference.RFC.4271.xml"?>
      <?rfc include="reference.RFC.1997.xml"?>
	</references>
	
  </back>
</rfc>
