draft-ietf-idr-bgp-ls-registry-01.txt   draft-ietf-idr-bgp-ls-registry-02.txt 
IDR Group A. Farrel IDR Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Updates: 7752 (if approved) May 21, 2020 Updates: 7752 (if approved) December 8, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: November 22, 2020 Expires: June 11, 2021
Updates to the Allocation Policy for the Border Gateway Protocol - Link Updates to the Allocation Policy for the Border Gateway Protocol - Link
State (BGP-LS) Parameters Registries State (BGP-LS) Parameters Registries
draft-ietf-idr-bgp-ls-registry-01 draft-ietf-idr-bgp-ls-registry-02
Abstract Abstract
RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS). IANA RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS). IANA
created a registry consistent with that document called the "Border created a registry consistent with that document called the "Border
Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a
number of sub-registries. The allocation policy applied by IANA for number of sub-registries. The allocation policy applied by IANA for
those policies is "Specification Required" as defined in RFC 8126. those registries is "Specification Required" as defined in RFC 8126.
This document updates RFC 7752 by changing the allocation policy for This document updates RFC 7752 by changing the allocation policy for
all of the registries to "Expert Review" and by updating the guidance all of the registries to "Expert Review" and by updating the guidance
to the Designated Experts. to the Designated Experts.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 22, 2020. This Internet-Draft will expire on June 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Guidance for Designated Experts . . . . . . . . . . . . . 3 2.1. Guidance for Designated Experts . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
5. Normative References . . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
Border Gateway Protocol - Link State (BGP-LS) [RFC7752] requested Border Gateway Protocol - Link State (BGP-LS) [RFC7752] requested
IANA to create a registry consistent called the "Border Gateway IANA to create a registry called the "Border Gateway Protocol - Link
Protocol - Link State (BGP-LS) Parameters Registry" with a number of State (BGP-LS) Parameters Registry" with a number of sub-registries.
sub-registries. The allocation policy applied by IANA for those The allocation policy applied by IANA for those registries is
policies is "Specification Required" as defined in [RFC8126]. "Specification Required" as defined in [RFC8126].
The "Specification Required" policy requires evaluation of any The "Specification Required" policy requires evaluation of any
assignment request by a "Designated Expert" and guidelines for any assignment request by a "Designated Expert" and guidelines for any
such experts are given in section 5.1 of [RFC7752]. In addition, such experts are given in section 5.1 of [RFC7752]. In addition,
this policy requires "the values and their meanings must be this policy requires that "the values and their meanings must be
documented in a permanent and readily available public specification, documented in a permanent and readily available public specification,
in sufficient detail so that interoperability between independent in sufficient detail so that interoperability between independent
implementations is possible" [RFC8126]. Further, the intention implementations is possible" [RFC8126]. Further, the intention
behind "permanent and readily available" is that "a document can behind "permanent and readily available" is that "a document can
reasonably be expected to be findable and retrievable long after IANA reasonably be expected to be findable and retrievable long after IANA
assignment of the requested value" [RFC8126]. assignment of the requested value" [RFC8126].
It is often considered that it is the responsibility of the
Designated Expert to make a determination as to whether a
specification meets the requirement to be permanent and readily
publicly available. A degree of contention arises in this case
because Internet-Drafts are now permanently archived in the IETF&s
tools archive, yet each such document is marked with a piece of
boilerplate text as follows that brings doubt about its suitability
as a permanent record:
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
Another allocation policy called "Expert Review" is defined in Another allocation policy called "Expert Review" is defined in
[RFC8126]. This policy also requires Expert Review, but has no [RFC8126]. This policy also requires Expert Review, but has no
requirement for a formal document. requirement for a formal document.
All reviews by Designated Experts are guided by advice given in the All reviews by Designated Experts are guided by advice given in the
document that defined the registry and set the allocation policy. document that defined the registry and set the allocation policy.
This document updates RFC 7752 by changing the allocation policy for This document updates RFC 7752 by changing the allocation policy for
all of the registries to "Expert Review" and updating the guidance to all of the registries to "Expert Review" and updating the guidance to
the Designated Experts. the Designated Experts.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. IANA Considerations 2. IANA Considerations
IANA maintains a registry called the "Border Gateway Protocol - Link IANA maintains a registry called the "Border Gateway Protocol - Link
State (BGP-LS) Parameters Registry". This registry contains four State (BGP-LS) Parameters Registry". This registry contains four
sub-registries: sub-registries:
o BGP-LS NLRI-Types o BGP-LS NLRI-Types
o BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and o BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs Attribute TLVs
skipping to change at page 3, line 43 skipping to change at page 3, line 38
IANA is requested to change the assignment policy for each of these IANA is requested to change the assignment policy for each of these
registries to "Expert Review". registries to "Expert Review".
2.1. Guidance for Designated Experts 2.1. Guidance for Designated Experts
Section 5.1 of [RFC7752] gives guidance to Designated Experts. This Section 5.1 of [RFC7752] gives guidance to Designated Experts. This
section replaces that guidance. section replaces that guidance.
In all cases of review by the Designated Expert (DE) described here, In all cases of review by the Designated Expert (DE) described here,
the DE is expected to check the clarity of purpose and use of the the DE is expected to check the clarity of purpose and use of the
requested code points. Additionally, the DE must verify that any requested code points. The following points apply to the registries
request for one of these code points has been made available for discussed in this document:
review and comment within the IETF: the DE will post the request to
the IDR Working Gorup mailing list (or a successor mailing list 1. Application for a codepoint allocation MAY be made to the
designated by the IESG). If the request comes from within the IETF, Designated Experts at any time.
it should be documented in an Internet-Draft. Lastly, the DE must
ensure that any other request for a code point does not conflict with 2. The Designated Experts SHOULD only consider requests that arise
work that is active or already published within the IETF. 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.
3. 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.
4. If the document is not adopted by the IDR Working Group (or its
successor), the Designated Expert SHOULD notify the IDR mailing
list (or its successor) of the request and allow two weeks for
any response. Any comments received SHOULD be considered by the
Designated Expert as part of the subsequent step.
5. 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.
6. The Designated Expert MUST attempt to ensure that any request for
a code point does not conflict with work that is active or
already published within the IETF.
7. Once the Designated Experts have granted approval, IANA will
update the registry by marking the allocated codepoints with a
reference to the associated document.
8. In the event that the document fails to progress to RFC, the
Working Group chairs or AD SHOULD contact the Designated Expert
to coordinate with IANA over marking the code points as
deprecated following similar principles to Section 3.3 of
[RFC7120].
3. Security Considerations 3. Security Considerations
The security consideration of [RFC7752] still apply. The security consideration of [RFC7752] still apply.
Note that the change to the expert review guidelines make the Note that the change to the expert review guidelines makes the
registry and the Designated Experts slightly more vulnerable to registry and the Designated Experts slightly more vulnerable to
denial of service attacks through excessive and bogus requests for denial of service attacks through excessive and bogus requests for
code points. It is expected that the registry cannot be effectively code points. It is expected that the registry cannot be effectively
attacked because the Designated Experts would, themselves, fall to attacked because the Designated Experts would, themselves, fall to
any such attack first. Designated Experts are expected to report to any such attack first. Designated Experts are expected to report to
the IDR working group chairs and responsible Area Director if they the IDR working group chairs and responsible Area Director if they
believe an attack to be in progress, and should immediately halt all believe an attack to be in progress, and should immediately halt all
requests for allocation. This may temporarily block all legitimate requests for allocation. This may temporarily block all legitimate
risks until mitigations have been put in place. requests until mitigations have been put in place.
This change in allocation policy should not have any effect on the
integrity of BGP-LS since there is no change to the review
requirements for the work that underlies the request.
4. Acknowledgements 4. Acknowledgements
This work is based on the IANA considerations section of [RFC7752]. This work is based on the IANA considerations section of [RFC7752].
The author thanks the people who worked on that document. The author thanks the people who worked on that document.
The author would like to be able to thank John Scudder for suggesting The author would like to be able to thank John Scudder for suggesting
the need for this document. the need for this document.
Thanks to John Scudder, Donald Eastlake, and Ketan Talaulikar for Thanks to John Scudder, Donald Eastlake, Ketan Talaulikar, and Alvaro
review, comments, and discussion. Retana for review, comments, and discussion.
Additional thanks to Gyan Mishra, Acee Lindem, Ketan Talaulikar, Les
Ginsberg, and Bruno Decraene for engaging in discussion on the
details of this work.
5. Normative References 5. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code
Points", BCP 100, RFC 7120, DOI 10.17487/RFC7120, January
2014, <https://www.rfc-editor.org/info/rfc7120>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Author's Address Author's Address
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
 End of changes. 18 change blocks. 
43 lines changed or deleted 85 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/