RFC 8810 - Revision to Capability Codes Registration Procedures 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8810.html
タイトル : RFC 8810 - 機能コード登録手順への改訂
翻訳編集 : 自動生成

[要約] RFC 8810は、Capability Codes Registration Proceduresの改訂を提案しています。このRFCの目的は、新しい機能コードの登録手順を明確化し、効率的な管理を促進することです。

Internet Engineering Task Force (IETF)                        J. Scudder
Request for Comments: 8810                              Juniper Networks
Updates: 5492                                                August 2020
Category: Standards Track
ISSN: 2070-1721

Revision to Capability Codes Registration Procedures

機能コード登録手順への改訂

Abstract

概要

This document updates RFC 5492 by making a change to the registration procedures for BGP Capability Codes. Specifically, the range formerly designated "Private Use" is divided into three new ranges: "First Come First Served", "Experimental Use", and "Reserved".

この文書は、BGP能力コードの登録手順を変更することによってRFC 5492を更新します。具体的には、以前に指定された「プライベートユース」の範囲は、「最初に最初にサービス」、「実験的な使用」、「予約」という3つの新しい範囲に分けられます。

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/rfc8810.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8810で入手できます。

著作権表示

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
   2.  Discussion
   3.  IANA Considerations
   4.  Security Considerations
   5.  References
     5.1.  Normative References
     5.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

The Border Gateway Protocol uses a mechanism called "Capability Advertisement" [RFC5492] to enable BGP peers to tell one another about their optional protocol extensions. These so-called "Capabilities" are signaled using code points called "Capability Codes".

Border Gatewayプロトコルは、BGPピアがオプションのプロトコル拡張機能について互いに伝えることを可能にするために、「機能広告」[RFC5492]というメカニズムを使用します。これらのいわゆる「機能」は、「能力コード」と呼ばれるコードポイントを使用してシグナリングされます。

[RFC5492] designates the range of Capability Codes 128-255 as "Private Use". Subsequent experience has shown this to be not only useless, but actively confusing to implementors.

[RFC5492]「プライベート使用」としての能力コード128~255の範囲を指定します。その後の経験は、これだけでなく、積極的に実装者を混乱させるためにこれを示しました。

Accordingly, this document revises the registration procedures for the range 128-255, as follows, using the terminology defined in [RFC8126]:

したがって、この文書は、[RFC8126]で定義されている用語を使用して、次のように、次のように128-255の範囲の登録手順を修正します。

128-238: First Come First Served 239-254: Experimental Use 255: Reserved

128-238：最初に最初に発売された239-254：実験的な使用255：予約済み

The procedures for the ranges 1-63 and 64-127 are unchanged, remaining "IETF Review" and "First Come First Served", respectively. The full range for "First Come First Served" is now 64-238.

1~63および64-127の手順は変更されず、残りの「IETFレビュー」および「最初は最初にサービスを提供」します。「最初に最初にサービス提供される」のフルレンジは64-238です。

2. Discussion

2. 討論

The reason for providing an "Experimental Use" range is to preserve a range for use during early development. Although there are few practical differences between "Experimental Use" and "Private Use", the change both makes it clear that code points from this space should not be used long term or in shipping products and reduces the consumption of the scarce Capability Codes space expended for this purpose. Once classified as "Experimental Use", it should be considered difficult to reclassify the space for some other purpose in the future.

「実験用途」範囲を提供する理由は、初期の発展中に使用するための範囲を保存することです。「実験用途」と「プライベート使用」の間には実用的な違いがありますが、この変化は、このスペースからのコードポイントを長期的または出荷商品に使用しないでください。この目的のために。「実験的な使用」として分類されると、将来的には他の目的のためにスペースを再分類することは困難であると考えられるべきです。

The reason for reserving the maximum value is that it may be useful in the future if extension of the number space is needed.

最大値を予約する理由は、数スペースの拡張が必要な場合は、将来有用である可能性があります。

Since the range 128-255 was formerly designated "Private Use", implementors may have chosen to use code points within that range prior to publication of this document. For this reason, a survey was conducted beginning August 14, 2015 (version 01 of the individual draft [SCUDDER]) to find any such uses. A number were contributed and were used to seed Table 2. Of course, there can be no guarantee that all uses were discovered; however, the likelihood seems high that remaining uses, if any, genuinely do fall under the intended use of "Private Use" and are restricted to some special deployment and are not in wide use. Furthermore, any remaining uses would be no worse than any other code point collision, such as occasionally occurs with code point "squatting", and could be dealt with in the same manner.

128-255の範囲は以前は「プライベートユース」と呼ばれていたので、この文書の公開の前にその範囲内のコードポイントを使用するように選択された可能性があります。このため、2015年8月14日から調査が行われ、そのような用途を見つけるために（個々のドラフトのバージョン01）。数値が寄与され、表2をシードするために使用された。もちろん、すべての用途が発見されたことを保証することはできません。しかし、尤度は、「プライベート使用」の意図された使用の下にある、あれば、その残りの使用が高いと思われるように見え、いくつかの特別な展開に制限されており、広く使用されていない。さらに、任意の任意の用途は、コードポイント「カットティング」とは時には発生するような他のコード点衝突よりも悪いことであり、同じ方法で対処することができる。

3. IANA Considerations

3. IANAの考慮事項

IANA has revised the "Capability Codes" registry as follows.

IANAは以下のように「機能コード」レジストリを修正しました。

Reference: [RFC5492] and this document.

参照：[RFC5492]とこの文書。

Note: The IETF will be the Change Controller for all future registrations.

注：IETFはすべての将来の登録の変更コントローラになります。

Registration procedures:

登録手順：

                   +=========+=========================+
                   |  Range  | Registration Procedures |
                   +=========+=========================+
                   |   1-63  | IETF Review             |
                   +---------+-------------------------+
                   |  64-238 | First Come First Served |
                   +---------+-------------------------+
                   | 239-254 | Experimental Use        |
                   +---------+-------------------------+

Table 1

表1

IANA has made the following new allocations within the "Capability Codes" registry:

IANAは、「機能コード」レジストリ内に次の新しい割り当てを行いました。

      +=======+============================+===========+============+
      | Value | Description                | Reference | Change     |
      |       |                            |           | Controller |
      +=======+============================+===========+============+
      |  128  | Prestandard Route Refresh  | RFC 8810  | IETF       |
      |       | (deprecated)               |           |            |
      +-------+----------------------------+-----------+------------+
      |  129  | Prestandard Outbound Route | RFC 8810  | IETF       |
      |       | Filtering (deprecated),    |           |            |
      |       | prestandard Routing Policy |           |            |
      |       | Distribution (deprecated)  |           |            |
      +-------+----------------------------+-----------+------------+
      |  130  | Prestandard Outbound Route | RFC 8810  | IETF       |
      |       | Filtering (deprecated)     |           |            |
      +-------+----------------------------+-----------+------------+
      |  131  | Prestandard Multisession   | RFC 8810  | IETF       |
      |       | (deprecated)               |           |            |
      +-------+----------------------------+-----------+------------+
      |  184  | Prestandard FQDN           | RFC 8810  | IETF       |
      |       | (deprecated)               |           |            |
      +-------+----------------------------+-----------+------------+
      |  185  | Prestandard OPERATIONAL    | RFC 8810  | IETF       |
      |       | message (deprecated)       |           |            |
      +-------+----------------------------+-----------+------------+
      |  255  | Reserved                   | RFC 8810  | IETF       |
      +-------+----------------------------+-----------+------------+

Table 2

表2.

4. Security Considerations

4. セキュリティに関する考慮事項

This revision to registration procedures does not change the underlying security issues inherent in the existing [RFC5492] and [RFC4271].

登録手順のこの改訂は、既存の[RFC5492]および[RFC4271]に固有の基礎となるセキュリティ問題を変更しません。

5. References

5. 参考文献

5.1. Normative References

5.1. 引用文献

[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 2009, <https://www.rfc-editor.org/info/rfc5492>.

[RFC5492] Scudder、J.およびR.Chandra、「BGP-4による機能広告」、RFC 5492、DOI 10.17487 / RFC5492、2009年2月、<https：//www.rfc-editor.org/info/rfc5492>。

[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>。

5.2. Informative References

5.2. 参考引用

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.

[RFC4271]、y、ed。、Li、T.、Ed。、S. Hares、Ed。、「ボーダーゲートウェイプロトコル4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月<https://www.rfc-editor.org/info/rfc4271>。

[SCUDDER] Scudder, J., "Revision to Capability Codes Registration Procedures", Work in Progress, Internet-Draft, draft-scudder-idr-capabilities-registry-change-01, 14 August 2015, <https://tools.ietf.org/html/draft-scudder-idr-capabilities-registry-change-01>.

[Scudder] Scudder、J.、「機能コード登録手順への改訂」、進行中の作業、インターネットドラフト、Draft-Scudder-IDR機能 - レジストリチェンジ-01,14月14日、<https：//ツール。ietf.org/html/draft-scudder-idr-capabilities-registry-change-01>。

Acknowledgements

謝辞

Thanks to Alia Atlas, Bruno Decraene, Martin Djernaes, Jie Dong, Jeff Haas, Sue Hares, Acee Lindem, Thomas Mangin, and Tom Petch for their reviews and comments.

Alia Atlas、Bruno Decraene、Martin Djernaes、Jie Dong、Jeff Haas、Sue Hares、Acee Lindem、Thomas Mangin、およびTom Petchのレビューやコメントのおかげで。

Author's Address

著者の住所

John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America

John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089アメリカ合衆国

   Email: jgs@juniper.net