[要約] RFC 7120は、標準トラックのコードポイントの早期IANA割り当てに関するガイドラインです。その目的は、コードポイントの割り当てプロセスを効率化し、標準化プロトコルの開発と展開を促進することです。
Internet Engineering Task Force (IETF) M. Cotton
Request for Comments: 7120 ICANN
BCP: 100 January 2014
Obsoletes: 4020
Category: Best Current Practice
ISSN: 2070-1721
Early IANA Allocation of Standards Track Code Points
標準トラックコードポイントの初期IANA割り当て
Abstract
概要
This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents.
このメモは、「仕様が必要」、「RFCが必要」、「IETFレビュー」、または「標準アクション」ポリシーが適用されるレジストリからIANAがコードポイントを早期に割り当てるプロセスを説明しています。このプロセスは、RFCの公開前にコードポイントの割り当てが必要となる問題を軽減するために使用でき、通常はコードポイントの割り当てをトリガーするRFCの公開前に、実装または展開のエクスペリエンスを促進します。このドキュメントの手順は、IETF Streamドキュメントにのみ適用されることを意図しています。
This document obsoletes RFC 4020.
このドキュメントはRFC 4020を廃止します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc7120.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7120で入手できます。
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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conditions for Early Allocation . . . . . . . . . . . . . . . . 4
3. Process for Early Allocation . . . . . . . . . . . . . . . . . 4
3.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Follow-Up . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Expiry . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
In protocol specifications documented in RFCs, there is often a need to allocate code points for various objects, messages, or other protocol entities so that implementations can interoperate. Many of these code point spaces have registries handled by the Internet Assigned Number Authority (IANA). Several IETF policies for IANA allocation of protocol parameters are described in RFC 5226 [RFC5226]. Some of them, such as "First Come First Served" or "Expert Review", do not require a formal IETF action before the IANA performs allocation. However, in situations where code points are a scarce resource and/or the IETF community has consensus to retain tight control of the registry content, policies such as "IETF Review" (formerly "IETF Consensus"), or "Standards Action" have been used. Such allocation policies present a problem in situations where implementation and/or deployment experience are desired or required before the document becomes an RFC.
RFCで文書化されているプロトコル仕様では、実装が相互運用できるように、さまざまなオブジェクト、メッセージ、またはその他のプロトコルエンティティにコードポイントを割り当てる必要があることがよくあります。これらのコードポイントスペースの多くには、Internet Assigned Number Authority（IANA）によって処理されるレジストリがあります。プロトコルパラメータのIANA割り当てに関するいくつかのIETFポリシーは、RFC 5226 [RFC5226]で説明されています。 「先着順」や「エキスパートレビュー」など、IANAが割り当てを実行する前に正式なIETFアクションを必要としないものもあります。ただし、コードポイントが不十分なリソースである場合や、IETFコミュニティがレジストリコンテンツの厳格な管理を維持することに合意している場合、「IETFレビュー」（以前の「IETFコンセンサス」）や「標準アクション」などのポリシーが中古。このような割り当てポリシーは、ドキュメントがRFCになる前に実装や展開の経験が望まれる、または必要とされる状況で問題を提起します。
To break the deadlock, document authors often choose some "seemingly unused" code points, often by selecting the next available value from the registry; this is problematic because these may turn out to be different from those later assigned by IANA. To make this problem worse, "pre-RFC" implementations are often developed and deployed based on these code point selections. This creates several potential interoperability problems between early implementations and implementations of the final standard, as described below:
デッドロックを打開するために、ドキュメントの作成者は、多くの場合、レジストリから次の使用可能な値を選択することにより、「一見使用されていない」コードポイントを選択します。これらは後でIANAによって割り当てられたものと異なる場合があるため、これには問題があります。この問題をさらに悪化させるために、「RFC以前」の実装は、これらのコードポイントの選択に基づいて開発および展開されることがよくあります。これにより、以下に説明するように、初期の実装と最終的な標準の実装との間にいくつかの潜在的な相互運用性の問題が生じます。
1. IANA allocates code points different from those that early implementations assumed would be allocated. Early implementations won't interoperate with standard ones.
1. IANAは、初期の実装が想定されるコードポイントとは異なるコードポイントを割り当てます。初期の実装は標準の実装と相互運用できません。
2. IANA allocates code points for one extension while a "pre-RFC" implementation of a different extension chooses the same code point. The different extensions will collide on the same code point in the field.
2. IANAは1つの拡張にコードポイントを割り当て、別の拡張の「RFC以前」の実装は同じコードポイントを選択します。さまざまな拡張機能がフィールド内の同じコードポイントで衝突します。
This gets in the way of the main purpose of standards; namely, to facilitate interoperable implementations.
これは、標準の主な目的を妨げます。つまり、相互運用可能な実装を容易にするためです。
It is easy to say that pre-RFC implementations should be kept private and should not be deployed; however, both the length of the standards process and the immense value of early implementations and early deployments suggest that finding a better solution is worthwhile. As an example, in the case of documents produced by Working Groups in the Routing Area, a pre-RFC implementation is highly desirable and sometimes even required [RFC4794], and early deployments provide useful feedback on the technical and operational quality of the specification.
RFC以前の実装は非公開にしておく必要があり、展開しないでください。ただし、標準プロセスの長さと初期実装および初期導入の計り知れない価値の両方から、より良いソリューションを見つけることは価値があることが示唆されています。例として、ルーティングエリアのワーキンググループによって作成されたドキュメントの場合、RFC以前の実装が非常に望ましく、場合によっては[RFC4794]でさえ必要であり、初期の展開は、仕様の技術的および運用上の品質に関する有用なフィードバックを提供します。
This memo addresses the early allocation of code points so that reservations are made in the IANA registries before the publication of an RFC. The early allocation mechanisms are applied only to spaces whose allocation policy is "Specification Required" (where an RFC is used as the stable reference), "RFC Required", "IETF Review", or "Standards Action". For an explanation of these allocation policies, see [RFC5226].
このメモは、RFCの公開前にIANAレジストリで予約が行われるように、コードポイントの早期割り当てを扱います。初期の割り当てメカニズムは、割り当てポリシーが「Specification Required」（RFCが安定した参照として使用されている）、「RFC Required」、「IETF Review」、または「Standards Action」であるスペースにのみ適用されます。これらの割り当てポリシーの説明については、[RFC5226]を参照してください。
A policy for IANA early allocations was previously described in [RFC4020]. This document obsoletes RFC 4020 and includes other registration procedures regarding the types of registries that can qualify for early allocation. The procedures in this document are intended to apply only to IETF Stream documents.
IANAの早期割り当てのポリシーは、以前[RFC4020]で説明されていました。このドキュメントはRFC 4020を廃止し、早期割り当ての対象となるレジストリのタイプに関する他の登録手順を含みます。このドキュメントの手順は、IETF Streamドキュメントにのみ適用されることを意図しています。
The following conditions must hold before a request for early allocation of code points will be considered by IANA:
コードポイントの早期割り当てのリクエストがIANAによって検討される前に、次の条件が満たされている必要があります。
a. The code points must be from a space designated as "RFC Required", "IETF Review", or "Standards Action". Additionally, requests for early assignment of code points from a "Specification Required" registry are allowed if the specification will be published as an RFC.
a. コードポイントは、「RFC必須」、「IETFレビュー」、または「標準アクション」として指定されたスペースからのものでなければなりません。さらに、仕様がRFCとして公開される場合は、「Specification Required」レジストリからのコードポイントの早期割り当てのリクエストが許可されます。
b. The format, semantics, processing, and other rules related to handling the protocol entities defined by the code points (henceforth called "specifications") must be adequately described in an Internet-Draft.
b. コードポイントによって定義されたプロトコルエンティティの処理に関連する形式、セマンティクス、処理、およびその他のルール（以降、「仕様」と呼びます）は、インターネットドラフトで適切に説明する必要があります。
c. The specifications of these code points must be stable; i.e., if there is a change, implementations based on the earlier and later specifications must be seamlessly interoperable.
c. これらのコードポイントの仕様は安定している必要があります。つまり、変更があった場合、以前と以降の仕様に基づく実装はシームレスに相互運用できる必要があります。
d. The Working Group chairs and Area Directors (ADs) judge that there is sufficient interest in the community for early (pre-RFC) implementation and deployment, or that failure to make an early allocation might lead to contention for the code point in the field.
d. ワーキンググループの議長とエリアディレクター（AD）は、早期（RFC以前）の実装と展開についてコミュニティに十分な関心があると判断します。または、早期の割り当てを行わないと、フィールドのコードポイントの競合につながる可能性があると判断します。
There are three processes associated with early allocation: making the request for code points; following up on the request; and revoking an early allocation. It cannot be emphasized enough that these processes must have a minimal impact on IANA itself, or they will not be feasible.
早期割り当てに関連するプロセスは3つあります。コードポイントを要求します。リクエストのフォローアップ;早期割り当てを取り消す。これらのプロセスがIANA自体に最小限の影響を与える必要があることを強調することはできません。そうしないと、実現できません。
The processes described below assume that the document in question is the product of an IETF Working Group (WG). If this is not the case, replace "WG chairs" below with "Shepherding Area Director".
以下で説明するプロセスは、問題のドキュメントがIETFワーキンググループ（WG）の製品であることを前提としています。そうでない場合は、以下の「WG議長」を「シェパーディングエリアディレクター」に置き換えてください。
The process for requesting and obtaining early allocation of code points is as follows:
コードポイントの早期割り当てを要求および取得するプロセスは次のとおりです。
1. The authors (editors) of the document submit a request for early allocation to the Working Group chairs, specifying which code points require early allocation and to which document they should be assigned.
1. ドキュメントの作成者（編集者）は、ワーキンググループの議長に早期割り当てのリクエストを送信し、どのコードポイントに早期割り当てが必要か、どのドキュメントに割り当てるかを指定します。
2. The WG chairs determine whether the conditions for early allocations described in Section 2 are met, particularly conditions (c) and (d).
2. WGの議長は、セクション2で説明されている早期割り当ての条件、特に条件（c）と（d）が満たされているかどうかを判断します。
3. The WG chairs gauge whether there is consensus within the WG that early allocation is appropriate for the given document.
3. WGの議長は、WG内で、所定のドキュメントに早期割り当てが適切であるというコンセンサスがあるかどうかを判断します。
4. If steps 2) and 3) are satisfied, the WG chairs request approval from the Area Director(s). The Area Director(s) may apply judgement to the request, especially if there is a risk of registry depletion.
4. ステップ2）および3）が満たされると、WGの議長はエリアディレクターに承認を要求します。エリアディレクターは、特にレジストリの枯渇のリスクがある場合、リクエストに判断を下すことがあります。
5. If the Area Directors approve step 4), the WG chairs request IANA to make an early allocation.
5. エリアディレクターがステップ4）を承認した場合、WG議長はIANAに早期の割り当てを要求します。
6. IANA makes an allocation from the appropriate registry, marking it as "Temporary", valid for a period of one year from the date of allocation. The date of first allocation and the date of expiry are also recorded in the registry and made visible to the public.
6. IANAは適切なレジストリから割り当てを行い、割り当て日から1年間有効な「一時的」としてマークします。最初の割り当て日と有効期限日もレジストリに記録され、一般に公開されます。
Note that Internet-Drafts should not include a specific value of a code point until IANA has completed the early allocation for this value.
IANAがこの値の早期割り当てを完了するまで、インターネットドラフトにコードポイントの特定の値を含めないでください。
It is the responsibility of the document authors and the Working Group chairs to review changes in the document, and especially in the specifications of the code points for which early allocation was requested, to ensure that the changes are backward compatible.
文書の変更、特に早期の割り当てが要求されたコードポイントの仕様を確認して、変更に下位互換性があることを確認するのは、文書の作成者とワーキンググループの議長の責任です。
If at some point changes that are not backward compatible are nonetheless required, a decision needs to be made as to whether previously allocated code points must be deprecated (see Section 3.3 for more information on code point deprecation). The considerations include aspects such as the possibility of existing deployments of the older implementations and, hence, the possibility for a collision between older and newer implementations in the field.
それでも下位互換性のない変更が必要な場合は、以前に割り当てられたコードポイントを廃止する必要があるかどうかを決定する必要があります（コードポイントの廃止の詳細については、セクション3.3を参照）。考慮事項には、古い実装の既存のデプロイメントの可能性、したがって、フィールドでの古い実装と新しい実装の衝突の可能性などの側面が含まれます。
If the document progresses to the point at which IANA normally makes code point allocations, it is the responsibility of the authors and the WG chairs to remind IANA that there were early allocations and of the code point values allocated in the IANA Considerations section of the RFC-to-be. Allocation is then just a matter of removing the "Temporary" tag from the allocation description.
IANAが通常コードポイントの割り当てを行うポイントまでドキュメントが進行する場合、早期の割り当てとRFCのIANAの考慮事項セクションで割り当てられたコードポイント値をIANAに通知するのは、作成者とWG議長の責任です。 -することが。割り当ては、割り当ての説明から「一時」タグを削除するだけです。
As described in Section 3.1, each temporary assignment is recorded in the registry with the date of expiry of the assignment. If an early allocation expires before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may repeat the process described in Section 3.1 to request renewal of the code points. At most, one renewal request may be made; thus, authors should choose carefully when the original request is to be made.
セクション3.1で説明したように、一時的な割り当てはそれぞれ、割り当ての有効期限と共にレジストリに記録されます。 IANAが通常割り当てを行うポイントまでドキュメントが進行する前に早期割り当てが期限切れになる場合、著者とWG議長は、セクション3.1で説明されているプロセスを繰り返してコードポイントの更新を要求できます。せいぜい、1つの更新要求しかできません。したがって、作成者は元のリクエストをいつ行うかを慎重に選択する必要があります。
As an exception to the above rule, under rare circumstances, more than one allocation renewal may be justified. All such further renewal requests must be reviewed by the IESG. The renewal request to the IESG must include the reasons why such further renewal is necessary and the WG's plans regarding the specification.
上記のルールの例外として、まれな状況で、複数の割り当ての更新が正当化される場合があります。そのような追加の更新要求はすべて、IESGによって確認される必要があります。 IESGへの更新要求には、そのような更なる更新が必要な理由と、仕様に関するWGの計画を含める必要があります。
If a follow-up request is not made, or the document fails to progress to an RFC, the assignment will remain visible in the registry, but the temporary assignment will be shown to have expired as indicated by the expiry date. The WG chairs are responsible for informing IANA that the expired assignments are not required and that the code points are to be marked "deprecated".
フォローアップリクエストが行われなかった場合、またはドキュメントがRFCに進まなかった場合、割り当てはレジストリに表示されたままになりますが、一時的な割り当ては有効期限が示すように期限切れになったことが示されます。 WG議長は、期限切れの割り当ては不要であり、コードポイントは「非推奨」とマークされることをIANAに通知する責任があります。
A deprecated code point is not marked as allocated for use as described in any document (that is, it is not allocated) and is not available for allocation in a future document. The WG chairs may inform IANA that a deprecated code point can be completely de-allocated (i.e., made available for new allocations) at any time after it has been deprecated. Factors influencing this decision will include whether there may be implementations using the previous temporary allocation and the availability of other unallocated code points in the registry.
非推奨のコードポイントは、ドキュメントで説明されているように割り当て済みとしてマークされていません（つまり、割り当てられていません）。今後のドキュメントでの割り当てには使用できません。 WGの議長は、非推奨になった後いつでも、非推奨のコードポイントの割り当てを完全に解除できる（つまり、新しい割り当てに利用できるようにする）ことをIANAに通知する場合があります。この決定に影響を与える要因には、以前の一時的な割り当てを使用した実装が存在するかどうか、およびレジストリ内の他の未割り当てコードポイントの可用性があるかどうかが含まれます。
Implementers and deployers need to be aware that deprecation and de-allocation could take place at any time after expiry; therefore, an expired early allocation is best considered as deprecated.
インプリメンターとデプロイヤーは、サポート終了と割り当て解除が満了後いつでも行われる可能性があることを認識する必要があります。したがって、期限切れの早期割り当ては非推奨と見なすのが最適です。
It is not IANA's responsibility to track the status of allocations, their expirations, or when they may be re-allocated.
割り当てのステータス、有効期限、またはいつ再割り当てされるかを追跡することは、IANAの責任ではありません。
Note that if a document is submitted for review to the IESG, and at the time of submission some early allocations are valid (not expired), these allocations must not be considered to have expired while the document is under IESG consideration or is awaiting publication in the RFC Editor's queue after approval by the IESG.
文書がIESGにレビューのために提出され、提出時にいくつかの早期割り当てが有効（期限切れではない）である場合、これらの割り当ては、文書がIESGの検討中または発行を待っている間に期限切れであると見なしてはならないことに注意してください。 IESGによる承認後のRFCエディターのキュー。
This document defines procedures for early allocation of code points in the registries with the "Specification Required", "RFC Required", "IETF Review", and "Standards Action" policies and as such directly affects IANA. This document removes the need for registries to be marked as specifically allowing early allocation. IANA has updated impacted registries by removing any such markings.
このドキュメントでは、「Specification Required」、「RFC Required」、「IETF Review」、および「Standards Action」ポリシーを持つレジストリでコードポイントを早期に割り当てる手順を定義し、IANAに直接影響します。このドキュメントでは、レジストリを特に早期に割り当てることができるものとしてマークを付ける必要がなくなります。 IANAは、そのようなマーキングを削除することにより、影響を受けるレジストリを更新しました。
It is important to keep in mind that denial-of-service attacks on IANA are possible as a result of the processes defined in this memo. There are two that are immediately obvious: depletion of code space by early allocations and process overloading of IANA itself. The processes described here attempt to alleviate both of these potential attacks, but they are subject to scrutiny by IANA to ensure that they work. IANA may at any time request that the IESG suspend the procedures described in this document.
このメモで定義されているプロセスの結果として、IANAに対するサービス拒否攻撃が可能であることに留意することが重要です。すぐにわかる2つがあります。早期割り当てによるコード空間の枯渇とIANA自体のプロセス過負荷です。ここで説明するプロセスは、これらの潜在的な攻撃の両方を緩和しようとしますが、それらが機能することを確認するために、IANAによる調査の対象となります。 IANAはいつでも、この文書に記載されている手順をIESGに一時停止するよう要求できます。
There is a significant concern that the procedures in this document could be used as an end-run on the IETF process to achieve code point allocation when an RFC will not be published. For example, a WG or a WG chair might be pressured to obtain an early allocation for a protocol extension for a particular company or for another Standards Development Organization even though it might be predicted that an IETF LC or IESG Evaluation would reject the approach that is documented. The requirement for AD consent of early review is an important safeguard, and ADs with any concern are strongly recommended to escalate the issue for IESG-wide discussion.
このドキュメントの手順は、RFCが公開されないときにコードポイントの割り当てを達成するためのIETFプロセスの最終段階として使用できるという大きな懸念があります。たとえば、WGまたはWGの議長は、IETF LCまたはIESG評価で、次のようなアプローチが拒否されると予測されている場合でも、特定の企業または別の標準開発組織のプロトコル拡張の早期割り当てを取得するように圧力を受ける場合があります。文書化。早期レビューのAD同意の要件は重要な保護手段であり、懸念があるADは、IESG全体の議論のために問題をエスカレーションすることを強くお勧めします。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of Standards Track Code Points", BCP 100, RFC 4020, February 2005.
[RFC4020] Kompella、K。およびA. Zinin、「Early IANA Allocation of Standards Track Code Points」、BCP 100、RFC 4020、2005年2月。
[RFC4794] Fenner, B., "RFC 1264 Is Obsolete", RFC 4794, December 2006.
[RFC4794] Fenner、B。、「RFC 1264 Is Obsolete」、RFC 4794、2006年12月。
Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their input on RFC 4020. Thank you to Kireeti Kompella and Alex Zinin for authoring RFC 4020. Thank you to Adrian Farrel, Stewart Bryant, Leo Vegoda, John Klensin, Subramanian Moonesamy, Loa Andersson, Tom Petch, Robert Sparks, Eric Rosen, Amanda Baber, and Pearl Liang for their reviews of this document.
RFC 4020への情報提供については、バートウィネン、エイドリアンファレル、およびビルフェナーに感謝します。RFC4020を作成してくれたキリーティコンペラとアレックスジニンに感謝します。このドキュメントのレビューに対するLoa Andersson、Tom Petch、Robert Sparks、Eric Rosen、Amanda Baber、Pearl Liangの各氏。
Author's Address
著者のアドレス
Michelle Cotton Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536 United States of America
Michelle Cotton Internet Corporation for Assigned Names and Numbers 12025 Waterfront Drive、Suite 300 Los Angeles、CA 90094-2536 United States of America
Phone: +1-310-823-5800
EMail: michelle.cotton@icann.org
URI: http://www.icann.org/