[要約] RFC 9029は、Border Gateway Protocol - Link State (BGP-LS)パラメータレジストリの割り当てポリシーを更新します。この文書の目的は、より柔軟な管理と将来の拡張性を確保することです。利用場面としては、ネットワーク管理者がBGP-LSデータをより効率的に扱い、ネットワークの最適化と拡張を支援することが挙げられます。
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
Border Gatewayプロトコル（BGP-LS）パラメータレジストリの割り当てポリシーの更新
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.
RFC 7752は、ボーダーゲートウェイプロトコルリンク状態（BGP-LS）を定義します。IANAは、「Border Gateway Protocol - Link State（BGP-LS）パラメータ」という文書と一致するレジストリをいくつかのサブレジストリに作成しました。RFC 8126で定義されているように、IANAによって適用される割り当て方針は「仕様必須」です。
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.
このドキュメントは、すべてのレジストリの割り当てポリシーを "エキスパートレビュー"に変更し、指定された専門家へのガイダンスを更新することによって、RFC 7752を更新します。
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.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
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.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、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.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
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
"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].
"BGPを使用したリンク状態とトラフィックエンジニアリング（TE）情報のノースバインド分散" [RFC7752]は、いくつかのサブレジストリを持つ "Border Gatewayプロトコル - リンク状態（BGP-LS）パラメータ"と呼ばれるレジストリを作成しました。[RFC8126]で定義されているように、IANAによって適用された割り当てポリシーは、「指定必須」です。
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].
「指定された」ポリシーでは、「指定されたエキスパート」による割り当て要求の評価が必要であり、そのような専門家のガイドラインは[RFC7752]のセクション5.1に示されています。さらに、この方針は「値とその意味を十分に詳細に文書化する必要があります。これにより、独立した実装間の相互運用性が可能です。[RFC8126]。さらに、「永久的で容易に入手可能に入手可能」の背後にある意図は、「要求された値のIANA割り当ての後に想定される長さと回収可能であると想定される可能性がある」ことである。
Another allocation policy called "Expert Review" is defined in [RFC8126]. This policy also requires Expert Review but has no requirement for a formal document.
[Expert Review]という別の割り当てポリシーは[RFC8126]で定義されています。このポリシーにはエキスパートレビューも必要ですが、正式な文書を必要としません。
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.
このドキュメントは、すべてのレジストリの割り当てポリシーを「エキスパートレビュー」に変更し、指定された専門家へのガイダンスを更新することで、[RFC7752]を更新します。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
IANA maintains a registry called "Border Gateway Protocol - Link State (BGP-LS) Parameters". This registry contains four subregistries:
IANAは、「境界ゲートウェイプロトコル - リンク状態（BGP-LS）パラメータ」と呼ばれるレジストリを管理しています。このレジストリには4つのサブレジストリが含まれています。
* BGP-LS NLRI-Types
* BGP-LS NLRIタイプ
* BGP-LS Protocol-IDs
* BGP-LSプロトコルIDS
* BGP-LS Well-Known Instance-IDs
* BGP-LSの有名なインスタンスIDS
* BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs
* BGP-LSノード記述子、リンク記述子、プレフィックス記述子、および属性TLVS
IANA has changed the assignment policy for each of these registries to "Expert Review".
IANAは、これらのレジストリのそれぞれの代入ポリシーを「エキスパートレビュー」に変更しました。
IANA has also added this document as a reference for the registries mentioned above.
IANAは、この文書を上記のレジストリの参照として追加しました。
Section 5.1 of [RFC7752] gives guidance to designated experts. This section replaces that guidance.
[RFC7752]のセクション5.1は、指定された専門家へのガイダンスを与えます。このセクションはそのガイダンスを置き換えます。
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.
1. コードポイント割り当てのためのアプリケーションは、指定された専門家にいつでも作成され、コードポイントの使用を説明する技術文書を伴う必要があります。そのような文書はインターネットドラフトの形で提示されるべきであるが、レビューアから検討および交換することができるあらゆる形態で到着するかもしれない。
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.
2. 指定された専門家は、既に作業グループの文書として受け入れられている、または適切にチャーターされたワーキンググループがない場合には、広告スポンサードキュメントとしての進行のために計画されているインターネットドラフトから生じるリクエストを検討する必要があります。
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.
3. ワーキンググループの文書の場合、指定された専門家は、現時点で割り当てをするためにワーキンググループ内にコンセンサスがあるというワーキンググループの議長にチェックする必要があります。広告スポンサードキュメントの場合、指定された専門家はこの時点で割り当てをするために承認を承認するために広告に確認する必要があります。
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.
4. 文書がIDRワーキンググループ（またはその後継）によって採用されていない場合、指定されたエキスパートは、要求のIDRメーリングリスト（またはその後継）に通知し、その文書へのアクセスを提供する必要があります。指定されたエキスパートは、何らかの対応で2週間を許可しなければなりません。受信したコメントは、その後のステップの一部として指定されたエキスパートによって考慮されなければなりません。
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.
5. 指定された専門家たちは、その技術的メリットに対する割り当て要求を検討する必要があります。指定された専門家は、譲渡が行われる前に、著者とIDR（または後継者）メーリングリストに関する割り当て要求に関連する問題を提起することができる。
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.
6. 指定されたエキスパートは、コードポイントに対する要求が、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.
7. 指定された専門家が承認を与えられたら、IANAは割り当てられたコードポイントを関連文書への参照でマークすることによってレジストリを更新します。
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.
8. 文書がワーキンググループの文書であるか、または広告されている場合、その文書はRFCとして出版することが失敗し、ワーキンググループの椅子または広告は、コードポイントのマーキングを推奨されているとおりに調整するためにIANAに連絡する必要があります。廃止予定のコードポイントは、使用するように割り当てられているとマークされず、将来の文書での割り当てには使用できません。WGチェアは、レジストリ内に未割り当てコードポイントが不足している場合、廃止予定のコードポイントを完全に割り当て解除することができる（すなわち、新しい割り当てのために利用可能にする）ことをIANAに通知することができる。
The security considerations described in Section 8 of [RFC7752] still apply.
[RFC7752]のセクション8で説明されているセキュリティ上の考慮事項はまだ適用されます。
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.
エキスパートレビューガイドラインへの変更は、登録職務と指定された専門家が、コードポイントに対する過剰および偽の要求を通じてサービス拒否攻撃に対して少し脆弱になります。指定された専門家が最初にそのような攻撃に落ちるので、レジストリは効果的に攻撃できないことが予想されます。指定された専門家は、IDRワーキンググループチェアと責任あるエリアディレクターに報告することが期待されており、攻撃を進めており、すぐに割り当てに対するすべての要求を停止する必要があります。これは、軽減がされているまで、すべての正当な要求を一時的にブロックすることがあります。
[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>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<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>.
[RFC7752] Gredler、H.、Ed。、Medved、J.、Previdi、S.、Farrel、A.、およびS. Ray、「BGPを使用したリンク状態およびトラフィックエンジニアリングの北部分布」、RFC 7752、DOI 10.17487 / RFC7752、2016年3月、<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>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<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>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<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.
この作業は[RFC7752]の第5節で説明されているIANAの考慮事項に基づいています。著者はその文書に取り組んだ人々に感謝します。
The author would like to thank John Scudder for suggesting the need for this document.
著者はこの文書の必要性を提案するためにJohn Scudderに感謝します。
Thanks to John Scudder, Donald Eastlake 3rd, Ketan Talaulikar, and Alvaro Retana for their review, comments, and discussion.
John Scudder、Donald Eastlake 3rd、Ketan Talaulikar、およびAlvaro Retanaのレビュー、コメント、およびディスカッションに感謝します。
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.
Gyan Mishra、Acee Lindem、Ketan Talaulikar、Les Ginsberg、Bruno Decraene、Benjamin Kaduk、Benjamin Kaduk、およびMartin Vigoueuxのおかげで、この作品の詳細について説明します。
Author's Address
著者の住所
Adrian Farrel Old Dog Consulting
エイドリアンファーレルオールドドッグコンサルティング
Email: adrian@olddog.co.uk