draft-ietf-idr-bgp-ls-registry-05.txt   draft-ietf-idr-bgp-ls-registry-06.txt 
IDR Group A. Farrel IDR Group A. Farrel
Internet-Draft Old Dog Consulting Internet-Draft Old Dog Consulting
Updates: 7752 (if approved) March 25, 2021 Updates: 7752 (if approved) March 30, 2021
Intended status: Standards Track Intended status: Standards Track
Expires: September 26, 2021 Expires: October 1, 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-05 draft-ietf-idr-bgp-ls-registry-06
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 registries 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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 September 26, 2021. This Internet-Draft will expire on October 1, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . . 5 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
5. Normative References . . . . . . . . . . . . . . . . . . . . 5 5. Normative References . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 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 called the "Border Gateway Protocol - Link IANA to create a registry called the "Border Gateway Protocol - Link
State (BGP-LS) Parameters Registry" with a number of sub-registries. State (BGP-LS) Parameters Registry" with a number of sub-registries.
The allocation policy applied by IANA for those registries is The allocation policy applied by IANA for those registries 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
skipping to change at page 3, line 42 skipping to change at page 3, line 42
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. 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:
1. Application for a code point allocation may be made to the 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 at any time, and MUST be accompanied by Designated Experts at any time, and MUST be accompanied by
technical documentation explaining the use of the code point. technical documentation explaining the use of the code point.
Such documentation SHOULD be presented in the form of an Such documentation SHOULD be presented in the form of an
Internet-Draft, but MAY arrive in any form that can be reviewed Internet-Draft, but MAY arrive in any form that can be reviewed
and exchanged amongst reviewers. and exchanged amongst reviewers.
3. The Designated Experts SHOULD only consider requests that arise 2. The Designated Experts SHOULD only consider requests that arise
from I-Ds that have already been accepted as Working Group from I-Ds that have already been accepted as Working Group
documents or that are planned for progression as AD Sponsored documents or that are planned for progression as AD Sponsored
documents in the absence of a suitably chartered Working Group. documents in the absence of a suitably chartered Working Group.
4. In the case of Working Group documents, the Designated Experts 3. In the case of Working Group documents, the Designated Experts
MUST check with the Working Group chairs that there is consensus MUST check with the Working Group chairs that there is consensus
within the Working Group to make the allocation at this time. In within the Working Group to make the allocation at this time. In
the case of AD Sponsored documents, the Designated Experts MUST the case of AD Sponsored documents, the Designated Experts MUST
check with the AD for approval to make the allocation at this check with the AD for approval to make the allocation at this
time. time.
5. If the document is not adopted by the IDR Working Group (or its 4. If the document is not adopted by the IDR Working Group (or its
successor), the Designated Expert MUST notify the IDR mailing successor), the Designated Expert MUST notify the IDR mailing
list (or its successor) of the request and MUST provide access to list (or its successor) of the request and MUST provide access to
the document. The Designated Expert MUST allow two weeks for any the document. The Designated Expert MUST allow two weeks for any
response. Any comments received MUST be considered by the response. Any comments received MUST be considered by the
Designated Expert as part of the subsequent step. Designated Expert as part of the subsequent step.
6. The Designated Experts MUST then review the assignment requests 5. The Designated Experts MUST then review the assignment requests
on their technical merit. The Designated Experts MAY raise on their technical merit. The Designated Experts MAY raise
issues related to the allocation request with the authors and on issues related to the allocation request with the authors and on
the IDR (or successor) mailing list for further consideration the IDR (or successor) mailing list for further consideration
before the assignments are made. before the assignments are made.
7. The Designated Expert MUST ensure that any request for a code 6. The Designated Expert MUST ensure that any request for a code
point does not conflict with work that is active or already point does not conflict with work that is active or already
published within the IETF. published within the IETF.
8. Once the Designated Experts have granted approval, IANA will 7. 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. reference to the associated document.
9. In the event that the document is a Working Group document or is 8. 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 to as an RFC, the Working Group chairs or AD SHOULD contact IANA to
coordinate about marking the code points as deprecated. A coordinate about marking the code points as deprecated. A
deprecated code point is not marked as allocated for use and is deprecated code point is not marked as allocated for use and is
not available for allocation in a future document. The WG chairs not available for allocation in a future document. The WG chairs
may inform IANA that a deprecated code point can be completely may inform IANA that a deprecated code point can be completely
de-allocated (i.e., made available for new allocations) at any de-allocated (i.e., made available for new allocations) at any
time after it has been deprecated if there is a shortage of time after it has been deprecated if there is a shortage of
unallocated code points in the registry. unallocated code points in the registry.
 End of changes. 13 change blocks. 
15 lines changed or deleted 12 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/