rfc9029xml2.original.xml   rfc9029.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<?rfc toc="yes"?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC tf-idr-bgp-ls-registry-05" ipr="trust200902" updates="7752" obsoletes="" submiss
.2119.xml"> ionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortR
<!ENTITY RFC7752 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC efs="true" version="3" number="9029" consensus="true">
.7752.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
]>
<rfc category="std" docName="draft-ietf-idr-bgp-ls-registry-05" ipr="trust200902 " updates="7752"> <!-- xml2rfc v2v3 conversion 3.6.0 -->
<front> <front>
<title abbrev="BGP-LS Registry Update">Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries</title> <title abbrev="BGP-LS Registry Update">Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries</title>
<seriesInfo name="RFC" value="9029"/>
<author fullname="Adrian Farrel" initials="A." surname="Farrel"> <author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization>Old Dog Consulting</organization> <organization>Old Dog Consulting</organization>
<address> <address>
<email>adrian@olddog.co.uk</email> <email>adrian@olddog.co.uk</email>
</address> </address>
</author> </author>
<date month="June" year="2021"/>
<date month="" year="2021"/>
<area>Routing Area</area> <area>Routing Area</area>
<workgroup>IDR Group</workgroup> <workgroup>IDR Group</workgroup>
<keyword>BGP-LS</keyword> <keyword>BGP-LS</keyword>
<keyword>IANA</keyword> <keyword>IANA</keyword>
<abstract> <abstract>
<t>RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS). IANA c <t>RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS). IA
reated NA created
a registry consistent with that document called the "Border Gateway Pro a registry consistent with that document called "Border Gateway Protoco
tocol - Link l - Link
State (BGP-LS) Parameters Registry" with a number of sub-registries. T State (BGP-LS) Parameters" with a number of subregistries. The
he allocation policy applied by IANA for those registries is "Specificatio
allocation policy applied by IANA for those registries is "Specificatio n Required",
n Required"
as defined in RFC 8126.</t> as defined in RFC 8126.</t>
<t>This document updates RFC 7752 by changing the allocation policy for al l of <t>This document updates RFC 7752 by changing the allocation policy for al l of
the registries to "Expert Review" and by updating the guidance to the D the registries to "Expert Review" and by updating the guidance to the d
esignated esignated
Experts.</t> experts.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>Border Gateway Protocol - Link State (BGP-LS) <xref target="RFC7752" /> <name>Introduction</name>
requested IANA to create <t>"North-Bound Distribution of Link-State and Traffic Engineering (TE) In
a registry called the "Border Gateway Protocol - Link State (BGP-LS) formation Using BGP" <xref target="RFC7752" format="default"/> requested IANA to
Parameters Registry" with a number of sub-registries. The allocation p create
olicy a registry called "Border Gateway Protocol - Link State (BGP-LS)
applied by IANA for those registries is "Specification Required" as def Parameters" with a number of subregistries. The allocation policy
ined in applied by IANA for those registries is "Specification Required", as de
<xref target="RFC8126" />.</t> fined in
<xref target="RFC8126" format="default"/>.</t>
<t>The "Specification Required" policy requires evaluation of any assignme <t>The "Specification Required" policy requires evaluation of any as
nt signment
request by a "Designated Expert" and guidelines for any such experts ar request by a "designated expert", and guidelines for any such experts a
e re
given in section 5.1 of <xref target="RFC7752" />. In addition, this p given in <xref target="RFC7752" sectionFormat="of" section="5.1"/>. In
olicy requires that "the addition, this policy requires that "the
values and their meanings must be documented in a permanent and readily values and their meanings must be documented in a permanent and readily
available public specification, in sufficient detail so that available public specification, in sufficient detail so that
interoperability between independent implementations is possible" <xref target="RFC8126" />. interoperability between independent implementations is possible" <xref target="RFC8126" format="default"/>.
Further, the intention behind "permanent and readily available" is that "a Further, the intention behind "permanent and readily available" is that "a
document can reasonably be expected to be findable and retrievable long after document can reasonably be expected to be findable and retrievable long after
IANA assignment of the requested value" <xref target="RFC8126" />.</t> IANA assignment of the requested value" <xref target="RFC8126" format="
default"/>.</t>
<t>Another allocation policy called "Expert Review" is defined in <xref ta <t>Another allocation policy called "Expert Review" is defined in <xref ta
rget="RFC8126" />. rget="RFC8126" format="default"/>.
This policy also requires Expert Review, but has no requirement for a This policy also requires Expert Review but has no requirement for a
formal document.</t> formal document.</t>
<t>All reviews by designated experts are guided by advice given in the
<t>All reviews by Designated Experts are guided by advice given in the
document that defined the registry and set the allocation policy.</t> document that defined the registry and set the allocation policy.</t>
<t>This document updates <xref target="RFC7752" format="default"/> by chan
<t>This document updates RFC 7752 by changing the allocation policy for al ging the allocation policy for all of
l of
the registries to "Expert Review" and updating the guidance to the the registries to "Expert Review" and updating the guidance to the
Designated Experts.</t> designated experts.</t>
<section numbered="true" toc="default">
<section title="Requirements Language"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
<xref target="RFC2119" /> <xref target="RFC8174" /> when, and only wh RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
en, "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
they appear in all capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA maintains a registry called "Border Gateway Protocol - Link State
(BGP-LS) Parameters".
This registry contains four subregistries:
</t>
<ul spacing="normal">
<li>BGP-LS NLRI-Types</li>
<li>BGP-LS Protocol-IDs</li>
<li>BGP-LS Well-Known Instance-IDs</li>
<li>BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attr
ibute TLVs</li>
</ul>
<t>IANA has changed the assignment policy for each of these registries to
"Expert Review".</t>
<t>IANA has also added this document as a reference for the registries men
tioned above.</t>
<section anchor="expert" numbered="true" toc="default">
<name>Guidance for Designated Experts</name>
<section anchor="IANA" title="IANA Considerations"> <t><xref target="RFC7752" sectionFormat="of" section="5.1"/> gives guidance to d
<t>IANA maintains a registry called the "Border Gateway Protocol - Link St esignated experts. This section replaces that guidance.</t>
ate (BGP-LS) Parameters Registry".
This registry contains four sub-registries:
<list style="symbols">
<t>BGP-LS NLRI-Types</t>
<t>BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and At
tribute TLVs</t>
<t>BGP-LS Protocol-IDs</t>
<t>BGP-LS Well-Known Instance-IDs</t>
</list></t>
<t>IANA is requested to change the assignment policy for each of these reg
istries to "Expert Review".</t>
<section anchor="expert" title="Guidance for Designated Experts">
<t>Section 5.1 of <xref target="RFC7752" /> gives guidance to Designated
Experts. This section replaces that
guidance.</t>
<t>In all cases of review by the Designated Expert (DE) described here, <t>In all cases of review by the designated expert described here,
the DE is expected to check the clarity of purpose and use of the the designated expert is expected to check the clarity of purpose and
use of the
requested code points. The following points apply to the registries requested code points. The following points apply to the registries
discussed in this document: discussed in this document:
<list style="numbers"> </t>
<ol spacing="normal" type="1">
<t>Application for a code point allocation may be made to the <li>Application for a code point allocation may be made to the
Designated Experts at any time.</t> designated experts at any time and <bcp14>MUST</bcp14> be accomp
anied
<t>Application for a code point allocation may be made to the
Designated Experts at any time, and MUST be accompanied
by technical documentation explaining the use of the code by technical documentation explaining the use of the code
point. Such documentation SHOULD be presented in the point. Such documentation <bcp14>SHOULD</bcp14> be presented in
form of an Internet-Draft, but MAY arrive in any form that the
can be reviewed and exchanged amongst reviewers.</t> form of an Internet-Draft but <bcp14>MAY</bcp14> arrive in any f
orm that
<t>The Designated Experts SHOULD only consider requests that arise can be reviewed and exchanged amongst reviewers.</li>
from I-Ds that have already been accepted as Working Group <li>The designated experts <bcp14>SHOULD</bcp14> only consider request
documents or that are planned for progression as AD Sponsored s that arise
documents in the absence of a suitably chartered Working Group.< from Internet-Drafts that have already been accepted as working
/t> group
documents or that are planned for progression as AD-Sponsored
<t>In the case of Working Group documents, the Designated Experts documents in the absence of a suitably chartered working group.<
MUST check with the Working Group chairs that there is /li>
consensus within the Working Group to make the allocation at thi <li>In the case of working group documents, the designated experts
s <bcp14>MUST</bcp14> check with the working group chairs that the
time. In the case of AD Sponsored documents, the Designated re is
Experts MUST check with the AD for approval to make the consensus within the working group to make the allocation at thi
allocation at this time.</t> s
time. In the case of AD-Sponsored documents, the designated
<t>If the document is not adopted by the IDR Working Group (or its experts <bcp14>MUST</bcp14> check with the AD for approval to ma
successor), the Designated Expert MUST notify the IDR mailing li ke the
st allocation at this time.</li>
(or its successor) of the request and MUST provide access to the <li>If the document is not adopted by the IDR Working Group (or its
document. The Designated Expert MUST allow two weeks for any re successor), the designated expert <bcp14>MUST</bcp14> notify the
sponse. IDR mailing list
Any comments received MUST be considered by the Designated Exper (or its successor) of the request and <bcp14>MUST</bcp14> provid
t e access to the
as part of the subsequent step.</t> document. The designated expert <bcp14>MUST</bcp14> allow two w
eeks for any response.
<t>The Designated Experts MUST then review the assignment requests Any comments received <bcp14>MUST</bcp14> be considered by the d
on their technical merit. The Designated Experts MAY raise esignated expert
as part of the subsequent step.</li>
<li>The designated experts <bcp14>MUST</bcp14> then review the assignm
ent requests
on their technical merit. The designated experts <bcp14>MAY</bc
p14> raise
issues related to the allocation request with the issues related to the allocation request with the
authors and on the IDR (or successor) mailing list authors and on the IDR (or successor) mailing list
for further consideration before the assignments for further consideration before the assignments
are made.</t> are made.</li>
<li>The designated expert <bcp14>MUST</bcp14> ensure that any request
<t>The Designated Expert MUST ensure that any request for for
a code point does not conflict with work that is active or alrea dy a code point does not conflict with work that is active or alrea dy
published within the IETF.</t> published within the IETF.</li>
<li>Once the designated experts have granted approval, IANA will
<t>Once the Designated Experts have granted approval, IANA will
update the registry by marking the allocated code points with a update the registry by marking the allocated code points with a
reference to the associated document.</t> reference to the associated document.</li>
<li>In the event that the document is a working group document or is
<t>In the event that the document is a Working Group document or is
AD Sponsored, and that document fails to progress to publication AD Sponsored, and that document fails to progress to publication
as an RFC, the Working Group chairs or AD SHOULD contact IANA as an RFC, the working group chairs or AD <bcp14>SHOULD</bcp14> contact IANA
to coordinate about marking the code points as deprecated. A to coordinate about marking the code points as deprecated. A
deprecated code point is not marked as allocated for use and is not deprecated code point is not marked as allocated for use and is not
available for allocation in a future document. The WG chairs ma y available for allocation in a future document. The WG chairs ma y
inform IANA that a deprecated code point can be completely inform IANA that a deprecated code point can be completely
de-allocated (i.e., made available for new allocations) at any t ime deallocated (i.e., made available for new allocations) at any ti me
after it has been deprecated if there is a shortage of unallocat ed after it has been deprecated if there is a shortage of unallocat ed
code points in the registry.</t> code points in the registry.</li>
</ol>
</list></t>
</section> </section>
</section> </section>
<section anchor="Security" numbered="true" toc="default">
<section anchor="Security" title="Security Considerations"> <name>Security Considerations</name>
<t>The security considerations described in <xref target="RFC7752" section
<t>The security consideration of <xref target="RFC7752" /> still apply.</t Format="of" section="8"/> still apply.</t>
> <t>Note that the change to the Expert Review guidelines makes the registry
and the designated experts slightly more
<t>Note that the change to the expert review guidelines makes the registry vulnerable to denial-of-service attacks through excessive and bogus req
and the Designated Experts slightly more uests for code points. It is expected that
vulnerable to denial of service attacks through excessive and bogus req the registry cannot be effectively attacked because the designated expe
uests for code points. It is expected that rts would, themselves, fall to any such
the registry cannot be effectively attacked because the Designated Expe attack first. Designated experts are expected to report to the IDR Wor
rts would, themselves, fall to any such king Group chairs and responsible Area
attack first. Designated Experts are expected to report to the IDR wor Director if they believe an attack to be in progress and should immedia
king group chairs and responsible Area tely halt all requests for allocation.
Director if they believe an attack to be in progress, and should immedi
ately halt all requests for allocation.
This may temporarily block all legitimate requests until mitigations ha ve been put in place.</t> This may temporarily block all legitimate requests until mitigations ha ve been put in place.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This work is based on the IANA considerations section of <xref target="
RFC7752" />. The author thanks the people who worked on that document.</t>
<t>The author would like to be able to thank John Scudder for suggesting t
he need for this document.</t>
<t>Thanks to John Scudder, Donald Eastlake, Ketan Talaulikar, and Alvaro R
etana for review, comments, and discussion.</t>
<t>Additional thanks to Gyan Mishra, Acee Lindem, Ketan Talaulikar, Les Gi
nsberg, Bruno Decraene, Benjamin Kaduk,
and Martin Vigoureux for engaging in discussion on the details of this w
ork.</t>
</section> </section>
</middle> </middle>
<back> <back>
<references>
<references title="Normative References"> <name>Normative References</name>
&RFC2119; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
&RFC7752; .2119.xml"/>
&RFC8126; <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
&RFC8174; .7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>This work is based on the IANA Considerations described in <xref target
="RFC7752" sectionFormat="of" section="5"/>. The author thanks the people who w
orked on that document.</t>
<t>The author would like to thank <contact fullname="John Scudder"/> for s
uggesting the need for this document.</t>
<t>Thanks to <contact fullname="John Scudder"/>, <contact fullname="Donald
Eastlake 3rd"/>, <contact fullname="Ketan Talaulikar"/>, and <contact fullname=
"Alvaro Retana"/> for their review, comments, and discussion.</t>
<t>Additional thanks to <contact fullname="Gyan Mishra"/>, <contact fullna
me="Acee Lindem"/>, <contact fullname="Ketan Talaulikar"/>, <contact fullname="L
es Ginsberg"/>, <contact fullname="Bruno Decraene"/>, <contact fullname="Benjami
n Kaduk"/>,
and <contact fullname="Martin Vigoureux"/> for engaging in discussion on
the details of this work.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 37 change blocks. 
199 lines changed or deleted 173 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/