Internet-Draft BGP-LS Registry Update December 2020
Farrel Expires 11 June 2021 [Page]
Workgroup:
IDR Group
Internet-Draft:
draft-ietf-idr-bgp-ls-registry-02
Updates:
7752 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Author:
A. Farrel
Old Dog Consulting

Updates to the Allocation Policy for the Border Gateway Protocol - Link State (BGP-LS) Parameters Registries

Abstract

RFC 7752 defines 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" with a number of sub-registries. The allocation policy applied by IANA for those registries is "Specification 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.

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 of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

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

This Internet-Draft will expire on 11 June 2021.

Table of Contents

1. Introduction

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

The "Specification Required" policy requires evaluation of any assignment request by a "Designated Expert" and guidelines for any such experts are given in 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, but has no requirement for a formal document.

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

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

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

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

2.1. Guidance for Designated Experts

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

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 requested code points. The following points apply to the registries discussed in this document:

  1. Application for a codepoint allocation MAY be made to the Designated Experts at any time.
  2. The Designated Experts SHOULD only consider requests that arise 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

The security consideration of [RFC7752] still apply.

Note that the change to the expert review guidelines makes the registry and the Designated Experts slightly more vulnerable to 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 would, themselves, fall to any such attack first. Designated Experts are expected to report to the IDR working group chairs and responsible Area Director if they believe an attack to be in 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, and Bruno Decraene 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, , <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, , <https://www.rfc-editor.org/info/rfc7120>.
[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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc8174>.

Author's Address

Adrian Farrel
Old Dog Consulting