[要約] RFC 7370は、IS-IS TLVコードポイントレジストリの更新に関するものであり、IS-ISプロトコルで使用されるTLVコードポイントの割り当てと管理を改善することを目的としています。
Internet Engineering Task Force (IETF) L. Ginsberg
Request for Comments: 7370 Cisco Systems
Category: Standards Track September 2014
ISSN: 2070-1721
Updates to the IS-IS TLV Codepoints Registry
IS-IS TLVコードポイントレジストリの更新
Abstract
概要
This document recommends some editorial changes to the IANA "IS-IS TLV Codepoints" registry to more accurately document the state of the protocol. It also sets out new guidelines for Designated Experts to apply when reviewing allocations from the registry.
このドキュメントでは、プロトコルの状態をより正確に文書化するために、IANAの「IS-IS TLVコードポイント」レジストリに編集上の変更を加えることを推奨しています。また、指定された専門家がレジストリからの割り当てを確認するときに適用する新しいガイドラインも設定します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7370.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7370で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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トラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. IS Neighbor Sub-TLV Registry . . . . . . . . . . . . . . . . 4
3. Prefix Reachability Sub-TLV Registry . . . . . . . . . . . . 4
4. Guidance for Designated Experts . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
The "IS-IS TLV Codepoints" registry was created by [RFC3563] and extended by [RFC6233]. The assignment policy for the registry is "Expert Review" as defined in [RFC5226]. As documents related to IS-IS are developed, the codepoints required for the protocol extensions are reviewed by the Designated Experts and added to the IANA-managed registry. As these documents are published as RFCs, the registries are updated to reference the relevant RFC.
「IS-IS TLVコードポイント」レジストリは、[RFC3563]によって作成され、[RFC6233]によって拡張されました。レジストリの割り当てポリシーは、[RFC5226]で定義されている「エキスパートレビュー」です。 IS-ISに関連するドキュメントが開発されると、プロトコル拡張に必要なコードポイントがDesignated Expertsによってレビューされ、IANA管理のレジストリに追加されます。これらのドキュメントはRFCとして公開されるため、レジストリは関連するRFCを参照するように更新されます。
In the case of TLVs supporting prefix advertisement, currently separate sub-TLV registries are maintained for each TLV. These registries need to be combined into a common sub-TLV registry similar to what has been done for neighbor advertisement TLVs.
プレフィックスアドバタイズメントをサポートするTLVの場合、現在別々のサブTLVレジストリが各TLVに対して維持されます。これらのレジストリは、ネイバーアドバタイズメントTLVに対して行われたものと同様の共通のサブTLVレジストリに組み合わせる必要があります。
In some cases, there is a need to allocate codepoints defined in Internet-Drafts (I-Ds) that seem likely to eventually gain Working Group approval, without waiting for those I-Ds to be published as RFCs. This can be achieved using Expert Review, and this document sets out guidance for the Designated Experts to apply when reviewing allocations from the registry.
場合によっては、I-DがRFCとして公開されるのを待たずに、最終的にワーキンググループの承認を得る可能性があるインターネットドラフト（I-D）で定義されたコードポイントを割り当てる必要があります。これは、エキスパートレビューを使用して達成できます。このドキュメントでは、指定されたエキスパートがレジストリから割り当てをレビューするときに適用するガイダンスを示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
There was an existing common sub-TLV registry named "Sub-TLVs for TLVs 22, 141, and 222". [RFC5311] defines the IS Neighbor Attribute TLV (23) and the MT IS Neighbor Attribute TLV (223). The format of these TLVs is identical to TLVs 22 and 222, respectively. The IS Neighbor sub-TLV registry has been extended to include these two TLVs. Settings for inclusion of each sub-TLV are identical to the settings for TLVs 22 and 222, respectively.
「TLV 22、141、222のサブTLV」という名前の既存の共通サブTLVレジストリがありました。 [RFC5311]は、ISネイバー属性TLV（23）とMT ISネイバー属性TLV（223）を定義しています。これらのTLVのフォーマットは、それぞれTLV 22および222と同じです。 IS NeighborサブTLVレジストリは、これら2つのTLVを含むように拡張されています。各サブTLVを含めるための設定は、TLV 22および222の設定とそれぞれ同じです。
Previously, there existed separate sub-TLV registries for TLVs 135, 235, 236, and 237. As in the case of the IS Neighbor TLVs discussed in the previous section, assignment of sub-TLVs applicable to one or more of these TLVs is intended to be common. Therefore, the existing separate sub-TLV registries have been combined into a single registry entitled "Sub-TLVs for TLVs 135, 235, 236, and 237". As existing sub-TLV assignments are common to all the TLVs, this represents no change to the protocol -- only a clearer representation of the intended sub-TLV allocation strategy. The format of the registry is as shown below:
以前は、TLV 135、235、236、および237に対して個別のサブTLVレジストリが存在していました。前のセクションで説明したISネイバーTLVの場合と同様に、これらのTLVの1つ以上に適用可能なサブTLVの割り当てが意図されています一般的になります。したがって、既存の個別のサブTLVレジストリは、「TLV 135、235、236、および237のサブTLV」という名前の単一のレジストリに結合されています。既存のサブTLV割り当てはすべてのTLVに共通であるため、これはプロトコルへの変更ではなく、意図されたサブTLV割り当て戦略のより明確な表現のみを表します。レジストリの形式は次のとおりです。
Type Description 135 235 236 237 Reference
---- ------------ --- --- --- --- ---------
0 Unassigned
1 32-bit Administrative Tag Sub-TLV y y y y [RFC5130]
2 64-bit Administrative Tag Sub-TLV y y y y [RFC5130]
3-255 Unassigned
When new I-Ds are introduced requiring new codepoints, it is advantageous to be able to allocate codepoints without waiting for them to progress to RFC. The reasons this is advantageous are described in [RFC7120]. However, the procedures in [RFC7120] for early allocation do not apply to registries, such as the "IS-IS TLV Codepoints" registry, that utilize the "Expert Review" allocation policy. In such cases, what is required is that a request be made to the Designated Experts who MAY approve the assignments according to the guidance that has been established for the registry concerned.
新しいコードポイントを必要とする新しいI-Dが導入された場合、それらがRFCに進むのを待たずにコードポイントを割り当てることができると有利です。これが有利である理由は[RFC7120]で説明されています。ただし、[RFC7120]の早期割り当ての手順は、「エキスパートレビュー」割り当てポリシーを利用する「IS-IS TLVコードポイント」レジストリなどのレジストリには適用されません。そのような場合に必要なことは、関係するレジストリのために確立されたガイダンスに従って割り当てを承認してもよい指定された専門家に要求がなされることです。
The following guidance applies specifically to the "IS-IS TLV Codepoints" registry.
次のガイダンスは、特に「IS-IS TLVコードポイント」レジストリに適用されます。
1. Application for a codepoint allocation MAY be made to the Designated Experts at any time.
1. コードポイント割り当ての申請は、指定専門家にいつでも行うことができます。
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.
2. Designated Expertsは、すでにワーキンググループドキュメントとして受け入れられているI-Dから発生したリクエスト、または適切にチャーターされたワーキンググループがない場合にADスポンサードキュメントとしての進行が計画されているリクエストのみを考慮する必要があります。
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.
3. 作業部会の文書の場合、指定専門家は、現時点で作業部会内で割り当てを行うことに合意があることを作業部会の議長に確認する必要があります。 ADスポンサー付きドキュメントの場合、指定専門家は、現時点で割り当てを行うための承認についてADに確認する必要があります。
4. 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.
4. 指定された専門家は、技術的メリットに基づいて割り当てリクエストを確認する必要があります。指定専門家は、IETFの合意を却下しようとするべきではありませんが、割り当てを行う前に、さらなる検討のために問題を提起することができます。
5. Once the Designated Experts have granted approval, IANA will update the registry by marking the allocated codepoints with a reference to the associated document as normal.
5. Designated Expertsが承認を与えると、IANAは割り当てられたコードポイントに関連ドキュメントへの参照を通常どおりマークすることにより、レジストリを更新します。
6. In the event that the document fails to progress to RFC, the Expiry and deallocation process defined in [RFC7120] MUST be followed for the relevant codepoints -- noting that the Designated Experts perform the role assigned to Working Group chairs.
6. ドキュメントがRFCに進まない場合は、[RFC7120]で定義されている有効期限と割り当て解除のプロセスに従って、指定されたエキスパートがワーキンググループの議長に割り当てられた役割を実行することに注意してください。
This document provides guidance to the Designated Experts appointed to manage allocation requests in the "IS-IS TLV Codepoints" registry.
このドキュメントは、「IS-IS TLVコードポイント」レジストリで割り当てリクエストを管理するよう任命された指定エキスパートへのガイダンスを提供します。
IANA has updated the registry that was specified as "Sub-TLVs for TLVs 22, 141, and 222" to be named "Sub-TLVs for TLVs 22, 23, 141, 222, and 223".
IANAは、「TLV 22、141、および222のサブTLV」として指定されたレジストリを「TLV 22、23、141、222、および223のサブTLV」という名前に更新しました。
Per this document, the existing sub-TLV registries for TLVs 135, 235, 236, and 237 have been combined into a single registry -- the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry -- as described in Section 3.
このドキュメントに従って、TLV 135、235、236、および237の既存のサブTLVレジストリは、説明されているように、「TLV 135、235、236、および237のサブTLV」レジストリに統合されました。セクション3で。
This document introduces no new security issues.
このドキュメントでは、新しいセキュリティの問題は紹介されていません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, February 2008, <http://www.rfc-editor.org/info/rfc5130>.
[RFC5130] Previdi、S.、Shand、M。、およびC. Martin、「管理タグを使用したIS-ISのポリシー制御メカニズム」、RFC 5130、2008年2月、<http://www.rfc-editor.org / info / rfc5130>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, "Simplified Extension of Link State PDU (LSP) Space for IS-IS", RFC 5311, February 2009, <http://www.rfc-editor.org/info/rfc5311>.
[RFC5311]マクファーソン、D。、ギンズバーグ、L。、プレビディ、S。、およびM.シャンド、「IS-ISのリンク状態PDU（LSP）スペースの簡略化された拡張」、RFC 5311、2009年2月、<http：/ /www.rfc-editor.org/info/rfc5311>。
[RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for Purges", RFC 6233, May 2011, <http://www.rfc-editor.org/info/rfc6233>.
[RFC6233] Li、T。およびL. Ginsberg、「IS-IS Registry Extension for Purges」、RFC 6233、2011年5月、<http://www.rfc-editor.org/info/rfc6233>。
[RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.
[RFC7120] Cotton、M。、「Early IANA Allocation of Standards Track Code Points」、BCP 100、RFC 7120、2014年1月、<http://www.rfc-editor.org/info/rfc7120>。
[RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol Development", RFC 3563, July 2003, <http://www.rfc-editor.org/info/rfc3563>.
[RFC3563] Zinin、A。、「IS-ISルーティングプロトコル開発に関するISOC / IETFとISO / IECジョイントテクニカルコミッティ1 /サブコミッティ6（JTC1 / SC6）の間の協力協定」、RFC 3563、2003年7月、<http ：//www.rfc-editor.org/info/rfc3563>。
Acknowledgements
謝辞
The author wishes to thank Alia Atlas and Amanda Baber for their input in defining the correct process to follow to get these changes implemented. Special thanks to Adrian Farrel for crafting the text in Section 4.
著者は、Alia AtlasとAmanda Baberに、これらの変更を実装するために従うべき正しいプロセスを定義する際の情報提供に感謝したいと思います。セクション4のテキストを作成してくれたAdrian Farrelに特に感謝します。
Author's Address
著者のアドレス
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, CA 95035 United States
Les Ginsberg Cisco Systems 510 McCarthy Blvd.ミルピタス、CA 95035アメリカ合衆国
EMail: ginsberg@cisco.com