rfc8810xml2.original.xml | rfc8810.xml | |||
---|---|---|---|---|
<?xml version="1.0" encoding="US-ASCII"?> | <?xml version="1.0" encoding="UTF-8"?> | |||
<!-- 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' ?> | <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> | |||
<!-- 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-09" | ||||
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 ***** --> | <rfc xmlns:xi="http://www.w3.org/2001/XInclude" | |||
docName="draft-ietf-idr-capabilities-registry-change-09" number="8810" | ||||
ipr="trust200902" updates="5492" obsoletes="" submissionType="IETF" | ||||
category="std" consensus="true" xml:lang="en" tocInclude="true" | ||||
tocDepth="4" symRefs="true" sortRefs="true" version="3"> | ||||
<front> | <!-- xml2rfc v2v3 conversion 2.44.0 --> | |||
<front> | ||||
<title abbrev="Capability Codes Registration Procedures"> | <title abbrev="Capability Codes Registration Procedures"> | |||
Revision to Capability Codes Registration Procedures</title> | Revision to Capability Codes Registration Procedures</title> | |||
<seriesInfo name="RFC" value="8810"/> | ||||
<!-- add 'role="editor"' below for the editors if appropriate --> | <author fullname="John Scudder" initials="J." surname="Scudder"> | |||
<!-- Another author who claims to be an editor --> | ||||
<author fullname="John Scudder" initials="J.S." | ||||
surname="Scudder"> | ||||
<organization>Juniper Networks</organization> | <organization>Juniper Networks</organization> | |||
<address> | <address> | |||
<postal> | <postal> | |||
<street>1194 N. Mathilda Ave</street> | <street>1194 N. Mathilda Ave</street> | |||
<!-- Reorder these if your country does things differently --> | ||||
<city>Sunnyvale</city> | <city>Sunnyvale</city> | |||
<region>CA</region> | <region>CA</region> | |||
<code>94089</code> | <code>94089</code> | |||
<country>United States of America</country> | ||||
<country>USA</country> | ||||
</postal> | </postal> | |||
<email>jgs@juniper.net</email> | <email>jgs@juniper.net</email> | |||
<!-- uri and facsimile elements may also be added --> | ||||
</address> | </address> | |||
</author> | </author> | |||
<date year="2020" month="August" /> | ||||
<date/> | ||||
<!-- Meta-data Declarations --> | ||||
<area>General</area> | <area>General</area> | |||
<workgroup>Network Working Group</workgroup> | <workgroup>Network Working Group</workgroup> | |||
<keyword>IDR</keyword> | <keyword>IDR</keyword> | |||
<abstract> | ||||
<abstract> | <t> | |||
<t> | ||||
This document updates RFC 5492 by making a change to the | This document updates RFC 5492 by making a change to the | |||
registration procedures for BGP Capability Codes. Specifically, the | registration procedures for BGP Capability Codes. Specifically, the | |||
range formerly designated "Reserved for Private Use" is divided into | range formerly designated "Private Use" is divided into | |||
three new ranges, respectively designated as "First Come First Served", | three new ranges: "First Come First Served", | |||
"Experimental Use" and "Reserved". | "Experimental Use", and "Reserved". | |||
</t> | </t> | |||
</abstract> | </abstract> | |||
</front> | </front> | |||
<middle> | <middle> | |||
<section anchor="introduction" numbered="true" toc="default"> | ||||
<section anchor="introduction" title="Introduction"> | <name>Introduction</name> | |||
<t> | <t> | |||
The Border Gateway Protocol uses a mechanism called "Capability | The Border Gateway Protocol uses a mechanism called "Capability | |||
Advertisement" <xref target="RFC5492"/> to enable BGP peers to | Advertisement" <xref target="RFC5492" format="default"/> to enable BGP pe ers to | |||
tell one another about their optional protocol extensions. These | tell one another about their optional protocol extensions. These | |||
so-called "Capabilities" are signaled using code points called | so-called "Capabilities" are signaled using code points called | |||
"Capability Codes". | "Capability Codes". | |||
</t> | </t> | |||
<t> | <t> | |||
<xref target="RFC5492"/> designates the range of Capability Codes | <xref target="RFC5492" format="default"/> designates the range of Capabil | |||
128-255 as "Reserved for Private Use". Subsequent experience has | ity Codes | |||
128-255 as "Private Use". Subsequent experience has | ||||
shown this to be not only useless, but actively confusing to | shown this to be not only useless, but actively confusing to | |||
implementors. | implementors.</t> | |||
</t> | <t> | |||
<t> | ||||
Accordingly, this document revises the registration procedures for | Accordingly, this document revises the registration procedures for | |||
the range 128-255, as follows, using the terminology defined in | the range 128-255, as follows, using the terminology defined in <xref | |||
<xref target="RFC8126"/>: | target="RFC8126" format="default"/>:</t> | |||
<?rfc subcompact="yes" ?> | <dl newline="false" spacing="compact" indent="10"> | |||
</t> | <dt>128-238:</dt> | |||
<t><list style="symbols"> | <dd>First Come First Served</dd> | |||
<t> | <dt>239-254:</dt> | |||
128-238: First Come First Served | <dd>Experimental Use</dd> | |||
</t> | <dt>255:</dt> | |||
<t> | <dd>Reserved</dd> | |||
239-254: Experimental Use | </dl> | |||
</t> | <t> | |||
<t> | ||||
255: Reserved | ||||
</t> | ||||
</list></t> | ||||
<?rfc subcompact="no" ?> | ||||
<t> | ||||
The procedures for the ranges 1-63 and 64-127 are unchanged, | The procedures for the ranges 1-63 and 64-127 are unchanged, | |||
remaining "IETF Review" and "First Come First Served" respectively. | remaining "IETF Review" and "First Come First Served", | |||
</t> | respectively. The full range for “First Come First Served” is now 64-238.< | |||
</section> | /t> | |||
</section> | ||||
<section anchor="discussion" title="Discussion"> | <section anchor="discussion" numbered="true" toc="default"> | |||
<t> | <name>Discussion</name> | |||
The reason for providing an Experimental Use range is to preserve a | <t> | |||
The reason for providing an "Experimental Use" range is to preserve a | ||||
range for use during early development. Although there are few | range for use during early development. Although there are few | |||
practical differences between Experimental and Private Use, the | practical differences between "Experimental Use" and "Private Use", the | |||
change both makes it clear that code points from this space should | change both makes it clear that code points from this space should | |||
not be used long-term or in shipping products, and reduces the | not be used long term or in shipping products and reduces the | |||
consumption of the scarce Capability Code space expended for this | consumption of the scarce Capability Codes space expended for this | |||
purpose. Once classified as Experimental, it should be considered | purpose. Once classified as "Experimental Use", it should be considered | |||
difficult to reclassify the space for some other purpose in the | difficult to reclassify the space for some other purpose in the | |||
future. | future. | |||
</t> | </t> | |||
<t> | <t> | |||
The reason for reserving the maximum value is that it may be useful | The reason for reserving the maximum value is that it may be useful | |||
in the future if extension of the number space is needed. | in the future if extension of the number space is needed. | |||
</t> | </t> | |||
<t> | ||||
Since the range 128-255 was formerly designated Private Use, | ||||
implementors may have chosen to use code points within that range | ||||
prior to publication of this document. For this reason, a survey was | ||||
conducted beginning August 14, 2015 (version 01 of the individual | ||||
draft) to find any such uses. A number were contributed and were | ||||
used to seed <xref target="new_allocations"/>. Of course there can | ||||
be no guarantee that all uses were discovered, however the | ||||
likelihood seems high that remaining uses, if any, genuinely do fall | ||||
under the intended use of "Private Use" and are restricted to some | ||||
special deployment, and are not in wide use. Furthermore, any | ||||
remaining uses would be no worse than any other code point | ||||
collision, such as occasionally occurs with code point "squatting", | ||||
and could be dealt with in the same manner. | ||||
</t> | ||||
</section> | <t> | |||
Since the range 128-255 was formerly designated "Private Use", | ||||
implementors may have chosen to use code points within that range prior to | ||||
publication of this document. For this reason, a survey was conducted | ||||
beginning August 14, 2015 (version 01 of the individual draft <xref | ||||
target="I-D.scudder-idr-capabilities-registry-change"/>) to find any such | ||||
uses. A number were contributed and were used to seed <xref | ||||
target="new_allocations" format="default"/>. Of course, there can be no | ||||
guarantee that all uses were discovered; however, the likelihood seems | ||||
high that remaining uses, if any, genuinely do fall under the intended use | ||||
of "Private Use" and are restricted to some special deployment and are not | ||||
in wide use. Furthermore, any remaining uses would be no worse than any | ||||
other code point collision, such as occasionally occurs with code point | ||||
"squatting", and could be dealt with in the same manner. | ||||
</t> | ||||
</section> | ||||
<section anchor="IANA" numbered="true" toc="default"> | ||||
<name>IANA Considerations</name> | ||||
<section anchor="IANA" title="IANA Considerations"> | <t> | |||
<t> | IANA has revised the "Capability Codes" registry as follows. | |||
IANA is requested to revise the "Capability Codes" registry in the | ||||
"Border Gateway Protocol (BGP) Parameters" group as follows. | ||||
</t> | </t> | |||
<t> | <t> | |||
Reference: <xref target="RFC5492"/> and this document. | Reference: <xref target="RFC5492" format="default"/> and this document. | |||
</t> | </t> | |||
<t> | ||||
<t>Note: The IETF will be the Change Controller for all future registrations. | ||||
</t> | ||||
<t> | ||||
Registration procedures: | Registration procedures: | |||
</t> | </t> | |||
<texttable anchor="registration_procedures"> | <table anchor="registration_procedures" align="center"> | |||
<ttcol align='center'>Range</ttcol> | <thead> | |||
<ttcol align='left'>Registration Procedures</ttcol> | <tr> | |||
<c>1-63</c> | <th align="center">Range</th> | |||
<c>IETF Review</c> | <th align="left">Registration Procedures</th> | |||
<c>64-238</c> | </tr> | |||
<c>First Come First Served</c> | </thead> | |||
<c>239-254</c> | <tbody> | |||
<c>Experimental</c> | <tr> | |||
</texttable> | <td align="center">1-63</td> | |||
<t> | <td align="left">IETF Review</td> | |||
IANA is requested to perform the following new allocations within the | </tr> | |||
<tr> | ||||
<td align="center">64-238</td> | ||||
<td align="left">First Come First Served</td> | ||||
</tr> | ||||
<tr> | ||||
<td align="center">239-254</td> | ||||
<td align="left">Experimental Use</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
<t> | ||||
IANA has made the following new allocations within the | ||||
"Capability Codes" registry: | "Capability Codes" registry: | |||
</t> | </t> | |||
<texttable anchor="new_allocations" style="all"> | <table anchor="new_allocations" align="center"> | |||
<ttcol align='center'>Value</ttcol> | <thead> | |||
<ttcol align='left'>Description</ttcol> | <tr> | |||
<ttcol align='left'>Reference</ttcol> | <th align="center">Value</th> | |||
<ttcol align='left'>Change Controller</ttcol> | <th align="left">Description</th> | |||
<c>128</c> | <th align="left">Reference</th> | |||
<c>Prestandard Route Refresh (deprecated)</c> | <th align="left">Change Controller</th> | |||
<c>(this document)</c> | </tr> | |||
<c>IETF</c> | </thead> | |||
<c>129</c> | <tbody> | |||
<c>Prestandard Outbound Route Filtering (deprecated), | <tr> | |||
prestandard Routing Policy Distribution (deprecated)</c> | <td align="center">128</td> | |||
<c>(this document)</c> | <td align="left">Prestandard Route Refresh (deprecated)</td> | |||
<c>IETF</c> | <td align="left">RFC 8810</td> | |||
<c>130</c> | <td align="left">IETF</td> | |||
<c>Prestandard Outbound Route Filtering (deprecated)</c> | </tr> | |||
<c>(this document)</c> | <tr> | |||
<c>IETF</c> | <td align="center">129</td> | |||
<c>131</c> | <td align="left">Prestandard Outbound Route Filtering (deprecated), | |||
<c>Prestandard Multisession (deprecated)</c> | prestandard Routing Policy Distribution (deprecated)</td> | |||
<c>(this document)</c> | <td align="left">RFC 8810</td> | |||
<c>IETF</c> | <td align="left">IETF</td> | |||
<c>184</c> | </tr> | |||
<c>Prestandard FQDN (deprecated)</c> | <tr> | |||
<c>(this document)</c> | <td align="center">130</td> | |||
<c>IETF</c> | <td align="left">Prestandard Outbound Route Filtering (deprecated)</ | |||
<c>185</c> | td> | |||
<c>Prestandard OPERATIONAL message (deprecated)</c> | <td align="left">RFC 8810</td> | |||
<c>(this document)</c> | <td align="left">IETF</td> | |||
<c>IETF</c> | </tr> | |||
<c>255</c> | <tr> | |||
<c>Reserved</c> | <td align="center">131</td> | |||
<c>(this document)</c> | <td align="left">Prestandard Multisession (deprecated)</td> | |||
<c>IETF</c> | <td align="left">RFC 8810</td> | |||
</texttable> | <td align="left">IETF</td> | |||
</section> | </tr> | |||
<tr> | ||||
<td align="center">184</td> | ||||
<td align="left">Prestandard FQDN (deprecated)</td> | ||||
<td align="left">RFC 8810</td> | ||||
<td align="left">IETF</td> | ||||
</tr> | ||||
<tr> | ||||
<td align="center">185</td> | ||||
<td align="left">Prestandard OPERATIONAL message (deprecated)</td> | ||||
<td align="left">RFC 8810</td> | ||||
<td align="left">IETF</td> | ||||
</tr> | ||||
<tr> | ||||
<td align="center">255</td> | ||||
<td align="left">Reserved</td> | ||||
<td align="left">RFC 8810</td> | ||||
<td align="left">IETF</td> | ||||
</tr> | ||||
</tbody> | ||||
</table> | ||||
</section> | ||||
<section anchor="Security" numbered="true" toc="default"> | ||||
<name>Security Considerations</name> | ||||
<t>This revision to registration procedures does not change the | ||||
underlying security issues inherent in the existing <xref | ||||
target="RFC5492" format="default"/> and <xref target="RFC4271" | ||||
format="default"/>.</t> | ||||
</section> | ||||
</middle> | ||||
<section anchor="Security" title="Security Considerations"> | <back> | |||
<t> | <displayreference target="I-D.scudder-idr-capabilities-registry-change" to="SCUD | |||
This revision to registration procedures does not change the | DER"/> | |||
underlying security issues inherent in the existing <xref | <references> | |||
target="RFC5492"/> and <xref target="RFC4271"/>. | <name>References</name> | |||
</t> | <references> | |||
</section> | <name>Normative References</name> | |||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere | ||||
nce.RFC.5492.xml"/> | ||||
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer | ||||
ence.RFC.8126.xml"/> | ||||
</references> | ||||
<references> | ||||
<name>Informative References</name> | ||||
<xi:include | ||||
href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC. | ||||
4271.xml"/> | ||||
<section anchor="Acknowledgements" title="Acknowledgements"> | <reference anchor='I-D.scudder-idr-capabilities-registry-change'> | |||
<t> | <front> | |||
Thanks to Alia Atlas, Bruno Decraene, Martin Djernaes, Jie Dong, | <title>Revision to Capability Codes Registration Procedures</title> | |||
Jeff Haas, Sue Hares, Acee Lindem, Thomas Mangin, and Tom Petch for | ||||
review and comments. | ||||
</t> | ||||
</section> | ||||
</middle> | <author initials='J' surname='Scudder' fullname='John Scudder'> | |||
<organization /> | ||||
</author> | ||||
<!-- *****BACK MATTER ***** --> | <date month='August' day='14' year='2015' /> | |||
<back> | <abstract><t>This document updates RFC 5492 by making a change to the registrati | |||
<references title="Normative References"> | on procedures for BGP Capability Codes. Specifically, the range formerly design | |||
<!--?rfc include= | ated "Reserved for Private Use" is divided into three new ranges, respectively d | |||
"http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?--> | esignated as "First Come First Served", "Experimental" and "Reserved".</t></abst | |||
ract> | ||||
<?rfc include="reference.RFC.5492.xml"?> | </front> | |||
<?rfc include="reference.RFC.8126.xml"?> | ||||
</references> | ||||
<references title="Informative References"> | <seriesInfo name='Internet-Draft' value='draft-scudder-idr-capabilities-registry | |||
<?rfc include="reference.RFC.4271.xml"?> | -change-01' /> | |||
</references> | <format type='TXT' | |||
target='http://www.ietf.org/internet-drafts/draft-scudder-idr-capabiliti | ||||
es-registry-change-01.txt' /> | ||||
</reference> | ||||
</references> | ||||
</references> | ||||
<section anchor="Acknowledgements" numbered="false" toc="default"> | ||||
<name>Acknowledgements</name> | ||||
<t> | ||||
Thanks to <contact fullname="Alia Atlas"/>, <contact fullname="Bruno | ||||
Decraene"/>, <contact fullname="Martin Djernaes"/>, <contact fullname="Ji | ||||
e Dong"/>, | ||||
<contact fullname="Jeff Haas"/>, <contact fullname="Sue Hares"/>, | ||||
<contact fullname="Acee Lindem"/>, <contact fullname="Thomas | ||||
Mangin"/>, and <contact fullname="Tom Petch"/> for their | ||||
reviews and comments.</t> | ||||
</section> | ||||
</back> | </back> | |||
</rfc> | </rfc> | |||
End of changes. 46 change blocks. | ||||
207 lines changed or deleted | 217 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |