Internet Engineering Task Force (IETF)                         A. Farrel
Request for Comments: 9029                            Old Dog Consulting
Updates: 7752                                                  June 2021
Category: Standards Track
ISSN: 2070-1721


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

Abstract

  RFC 7752 defines the Border Gateway Protocol - Link State (BGP-LS).
  IANA created a registry consistent with that document called "Border
  Gateway Protocol - Link State (BGP-LS) Parameters" with a number of
  subregistries.  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 is an Internet Standards Track document.

  This document is a product of the Internet Engineering Task Force
  (IETF).  It represents the consensus of the IETF community.  It has
  received public review and has been approved for 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 this document, any errata,
  and how to provide feedback on it may be obtained at
  https://www.rfc-editor.org/info/rfc9029.

Copyright Notice

  Copyright (c) 2021 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  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
    1.1.  Requirements Language
  2.  IANA Considerations
    2.1.  Guidance for Designated Experts
  3.  Security Considerations
  4.  Normative References
  Acknowledgements
  Author's Address

1.  Introduction

  "North-Bound Distribution of Link-State and Traffic Engineering (TE)
  Information Using BGP" [RFC7752] requested IANA to create a registry
  called "Border Gateway Protocol - Link State (BGP-LS) Parameters"
  with a number of subregistries.  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 [RFC7752] 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 "Border Gateway Protocol - Link
  State (BGP-LS) Parameters".  This registry contains four
  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

  IANA 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.  This
  section replaces that guidance.

  In all cases of review by the designated expert described here, 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 discussed in this document:

  1.  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 point.
      Such documentation SHOULD be presented in the form of an
      Internet-Draft but MAY arrive in any form that can be reviewed
      and exchanged amongst reviewers.

  2.  The designated experts SHOULD only consider requests that arise
      from Internet-Drafts 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
      MUST 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 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 MUST notify the IDR mailing
      list (or its successor) of the request and MUST provide access to
      the document.  The designated expert MUST allow two weeks for any
      response.  Any comments received MUST be considered by the
      designated expert as part of the subsequent step.

  5.  The designated experts MUST then review the assignment requests
      on their technical merit.  The 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 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 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 document or is
      AD Sponsored, and that document fails to progress to publication
      as an RFC, the 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
      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 considerations described in Section 8 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.  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: [email protected]

You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.