wdiff rfc9029.original rfc9029.txt

IDR Group

Internet Engineering Task Force (IETF) A. Farrel
Internet-Draft
Request for Comments: 9029 Old Dog Consulting
Updates: 7752 (if approved) March 25, June 2021
Intended status:
Category: Standards Track
Expires: September 26, 2021
ISSN: 2070-1721

Updates to the Allocation Policy for the Border Gateway Protocol - Link
State (BGP-LS) Parameters Registries
draft-ietf-idr-bgp-ls-registry-05

Abstract

RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).
IANA created a registry consistent with that document called the "Border
Gateway Protocol - Link State (BGP-LS) Parameters Registry" Parameters" with a number of sub-registries.
subregistries. The allocation policy applied by IANA for those
registries is "Specification Required" Required", as defined in RFC 8126.

This document updates RFC 7752 by changing the allocation policy for
all of the registries to "Expert Review" and by updating the guidance
to the Designated Experts. designated experts.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 26, 2021.
https://www.rfc-editor.org/info/rfc9029.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 3
2.1. Guidance for Designated Experts . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Acknowledgements
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6

1. Introduction

Border Gateway Protocol - Link State (BGP-LS)

"North-Bound Distribution of Link-State and Traffic Engineering (TE)
Information Using BGP" [RFC7752] requested IANA to create a registry
called the "Border Gateway Protocol - Link State (BGP-LS) Parameters Registry" Parameters"
with a number of sub-registries. subregistries. The allocation policy applied by
IANA for those registries is "Specification Required" Required", as defined in
[RFC8126].

The "Specification Required" policy requires evaluation of any
assignment request by a "Designated Expert" "designated expert", and guidelines for any
such experts are given in section Section 5.1 of [RFC7752]. In addition,
this policy requires that "the values and their meanings must be
documented in a permanent and readily available public specification,
in sufficient detail so that interoperability between independent
implementations is possible" [RFC8126]. Further, the intention
behind "permanent and readily available" is that "a document can
reasonably be expected to be findable and retrievable long after IANA
assignment of the requested value" [RFC8126].

Another allocation policy called "Expert Review" is defined in
[RFC8126]. This policy also requires Expert Review, Review but has no
requirement for a formal document.

All reviews by Designated Experts designated experts are guided by advice given in the
document that defined the registry and set the allocation policy.

This document updates RFC 7752 [RFC7752] by changing the allocation policy for
all of the registries to "Expert Review" and updating the guidance to
the Designated Experts. 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

IANA maintains a registry called the "Border Gateway Protocol - Link
State (BGP-LS) Parameters Registry". Parameters". This registry contains four
sub-registries:

o
subregistries:

* BGP-LS NLRI-Types

* BGP-LS Protocol-IDs

* BGP-LS Well-Known Instance-IDs

* BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs

o BGP-LS Protocol-IDs

o BGP-LS Well-Known Instance-IDs

IANA is requested to change has changed the assignment policy for each of these registries
to "Expert Review".

IANA has also added this document as a reference for the registries
mentioned above.

2.1. Guidance for Designated Experts

Section 5.1 of [RFC7752] gives guidance to Designated Experts. designated experts. This
section replaces that guidance.

In all cases of review by the Designated Expert (DE) designated expert described here, the DE
designated expert is expected to check the clarity of purpose and use
of the requested code points. The following points apply to the
registries discussed in this document:

1. Application for a code point allocation may be made to the
Designated Experts at any time.

2. Application for a code point allocation may be made to the
Designated Experts
designated experts at any time, time and MUST be accompanied by
technical documentation explaining the use of the code point.
Such documentation SHOULD be presented in the form of an
Internet-Draft,
Internet-Draft but MAY arrive in any form that can be reviewed
and exchanged amongst reviewers.

2. The Designated Experts designated experts SHOULD only consider requests that arise
from I-Ds Internet-Drafts that have already been accepted as Working Group working
group documents or that are planned for progression as AD AD-
Sponsored documents in the absence of a suitably chartered Working Group.

4.
working group.

3. In the case of Working Group working group documents, the Designated Experts designated experts
MUST check with the Working Group working group chairs that there is consensus
within the Working Group working group to make the allocation at this time. In
the case of AD Sponsored AD-Sponsored documents, the Designated Experts designated experts MUST
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 designated expert MUST notify the IDR mailing
list (or its successor) of the request and MUST provide access to
the document. The Designated Expert designated expert MUST allow two weeks for any
response. Any comments received MUST be considered by the
Designated Expert
designated expert as part of the subsequent step.

5. The Designated Experts designated experts MUST then review the assignment requests
on their technical merit. The Designated Experts designated experts MAY raise
issues related to the allocation request with the authors and on
the IDR (or successor) mailing list for further consideration
before the assignments are made.

6. The Designated Expert designated expert MUST 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 designated experts have granted approval, IANA will
update the registry by marking the allocated code points with a
reference to the associated document.

8. In the event that the document is a Working Group working group document or is
AD Sponsored, and that document fails to progress to publication
as an RFC, the Working Group working group chairs or AD SHOULD contact IANA to
coordinate about marking the code points as deprecated. A
deprecated code point is not marked as allocated for use and is
not available for allocation in a future document. The WG chairs
may inform IANA that a deprecated code point can be completely
de-allocated
deallocated (i.e., made available for new allocations) at any
time after it has been deprecated if there is a shortage of
unallocated code points in the registry.

3. Security Considerations

The security consideration considerations described in Section 8 of [RFC7752] still
apply.

Note that the change to the expert review Expert Review guidelines makes the
registry and the Designated Experts designated experts slightly more vulnerable to
denial of service
denial-of-service attacks through excessive and bogus requests for
code points. It is expected that the registry cannot be effectively
attacked because the Designated Experts designated experts would, themselves, fall to
any such attack first. Designated Experts experts are expected to report to
the IDR working group Working Group chairs and responsible Area Director if they
believe an attack to be in progress, progress and should immediately halt all
requests for allocation. This may temporarily block all legitimate
requests until mitigations have been put in place.

4. Acknowledgements

This work is based on the IANA considerations section of [RFC7752].
The author thanks the people who worked on that document.

The author would like to be able to thank John Scudder for suggesting
the need for this document.

Thanks to John Scudder, Donald Eastlake, Ketan Talaulikar, and Alvaro
Retana for review, comments, and discussion.

Additional thanks to Gyan Mishra, Acee Lindem, Ketan Talaulikar, Les
Ginsberg, Bruno Decraene, Benjamin Kaduk, and Martin Vigoureux for
engaging in discussion on the details of this work.

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>.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<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>.

Acknowledgements

This work is based on the IANA Considerations described in Section 5
of [RFC7752]. The author thanks the people who worked on that
document.

The author would like to thank John Scudder for suggesting the need
for this document.

Thanks to John Scudder, Donald Eastlake 3rd, Ketan Talaulikar, and
Alvaro Retana for their review, comments, and discussion.

Additional thanks to Gyan Mishra, Acee Lindem, Ketan Talaulikar, Les
Ginsberg, Bruno Decraene, Benjamin Kaduk, and Martin Vigoureux for
engaging in discussion on the details of this work.

Author's Address

Adrian Farrel
Old Dog Consulting

Email: adrian@olddog.co.uk