Network Working Group K. Kompella
Request for Comments: 4020 Juniper Networks
BCP: 100 A. Zinin
Category: Best Current Practice Alcatel
February 2005
Early IANA Allocation of Standards Track Code Points
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティのインターネットの最新のベストプラクティスを指定し、改善のための議論と提案を求めています。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
This memo discusses earlier allocation of code points by IANA as a remedy to the problem created by the "Standards Action" IANA policy for protocols for which, by the IETF process, implementation and deployment experience is desired or required prior to publication.
このメモは、IETFプロセスによって、公開前に実装および展開の経験が望まれるか、または必要とされるプロトコルの「標準アクション」IANAポリシーによって作成された問題の解決策として、IANAによるコードポイントの以前の割り当てについて説明します。
In Standards Track 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 IANA allocation policies are described in RFC 2434 [2434]. 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 is willing to retain tight control of the protocol, policies such as IESG Approval, IETF Consensus, or Standards Action have been used. The Standards Action policy represents a problem in situations where implementation and/or deployment experience are desired or required for the Standards Action.
Standards Track RFCでは、実装が相互運用できるように、さまざまなオブジェクト、メッセージ、またはその他のプロトコルエンティティにコードポイントを割り当てる必要がしばしばあります。 これらのコードポイントスペースの多くには、Internet Assigned Number Authority（IANA）によって処理されるレジストリがあります。 いくつかのIANA割り当てポリシーは、RFC 2434 [2434]で説明されています。 First Come First ServedやExpert Reviewなど、それらの一部は、IANAが割り当てを実行する前に正式なIETFアクションを必要としません。 ただし、コードポイントが不足している場合、および/またはIETFコミュニティがプロトコルの厳密な制御を維持する意思がある場合、IESG承認、IETFコンセンサス、または標準アクションなどのポリシーが使用されています。 標準アクションポリシーは、標準アクションに実装および/または展開の経験が望ましいまたは必要な状況での問題を表します。
To break the deadlock, "pre-RFC" implementations have sometimes simply chosen some "seemingly unused" code points; these may turn out to be different from those later assigned by IANA. To make matters worse, these "pre-RFC" implementations are often deployed. This creates several potential interoperability problems between early implementations and implementations of the final standard, as described below:
デッドロックを解消するために、「RFC導入前」の実装では、「未使用の」コードポイントを選択することがあります。 これらは、後に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 used silently for other extensions. Different extensions will collide.
2. IANAは、他の拡張機能にサイレントで使用されるコードポイントを割り当てます。 異なる拡張機能が衝突します。
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 finding a better solution. 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, and early deployments provide useful feedback on the technical and operational quality of the specification.
RFC以前の実装は非公開にしておくべきであり、展開すべきではないと言うのは簡単です。 ただし、標準化プロセスの長さと、早期実装と早期展開の莫大な価値の両方が、より良いソリューションを見つけることを示唆しています。 例として、ルーティングエリアのワーキンググループが作成したドキュメントの場合、RFC以前の実装が非常に望ましく、場合によっては必要になることもあります。また、早期展開により、仕様の技術的および運用上の品質に関する有用なフィードバックが提供されます。
This memo proposes that, under strictly controlled circumstances, IANA make an early allocation of code points. The memo lays out the conditions for early allocation, as well as the process to be followed; it also says how these allocations are dealt with in the event of a failure in the process (such as the RFC not being published).
このメモは、厳しく管理された状況下で、IANAがコードポイントの早期割り当てを行うことを提案しています。 このメモには、早期の割り当ての条件と、従うべきプロセスが記載されています。 また、プロセスで障害が発生した場合（RFCが公開されていないなど）、これらの割り当てがどのように処理されるかについても説明しています。
This memo only addresses the early allocation of code points from spaces whose allocation policy is "Standards Action" [2434] AND that have been amended to permit early allocation. This permission must be granted by the IESG, and code spaces with permission for early allocation must be marked as such in the IANA registry.
このメモは、割り当てポリシーが「標準アクション」[2434]であり、早期割り当てを許可するように修正されたスペースからのコードポイントの早期割り当てのみを扱っています。 この許可はIESGによって付与される必要があり、早期割り当ての許可を持つコードスペースは、IANAレジストリでそのようにマークされる必要があります。
The following conditions must hold before a request may be made for early allocation of code points:
コードポイントの早期割り当てを要求する前に、次の条件が満たされている必要があります。
a) The code points must be from a space designated as "Standards Action", amended by IESG approval to permit Early Allocation.
a）コードポイントは、早期割り当てを許可するためにIESGの承認により修正された「標準アクション」として指定されたスペースからのものでなければなりません。
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 that is proposed as Standards Track.
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) There is sufficient interest in early (pre-RFC) implementation and deployment in the community.
d）コミュニティでの早期（RFC以前）の実装と展開に十分な関心があります。
If conditions (a) or (b) are not met, then the processes in this memo do not apply.
条件（a）または（b）が満たされない場合、このメモのプロセスは適用されません。
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. If this is not the case, replace "WG chairs" below with "shepherding Area Director".
以下で説明するプロセスは、問題の文書がIETFワーキンググループの成果物であることを前提としています。 そうでない場合は、以下の「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 which document they should be assigned to.
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 in the case of the given document.
3）WGの議長は、与えられた文書の場合、早期の配分が適切であるというWG内のコンセンサスがあるかどうかを評価します。
4) If it is, with the approval of the Area Director(s), the WG chairs request IANA to make an early allocation.
4）エリアディレクターの承認を得た場合、WG議長はIANAに早期配分を要請します。
5) 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 allocation should also be recorded in the registry and made visible to the public.
5）IANAは適切なレジストリから割り当てを行い、割り当ての日付から1年間有効な「一時的」としてマークします。 割り当ての日付もレジストリに記録し、一般に公開する必要があります。
Note that Internet Drafts should not include a specific value of a code point until this value has been formally allocated by IANA.
インターネットドラフトは、この値が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 so 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が通常コードポイントの割り当てを行うポイントまで進む場合、IANAの考慮事項セクションで、早期の割り当てがあったこと、およびそのように割り当てられたコードポイント値をIANAに思い出させるのは、作成者とWG議長の責任です。 RFCの予定。 割り当ては、割り当ての説明から「一時的な」タグを削除するだけです。
If early allocations expire before the document progresses to the point where IANA normally makes allocations, the authors and WG chairs may follow an abbreviated version of the process 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.
ドキュメントが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 renewal requests must be reviewed by the IESG. The renewal request to the IESG must include the reasons why such 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 a Standards Track RFC, the WG chairs are responsible for informing IANA that the code points are to be marked "deprecated" (and are not to be allocated). The WG chairs are further responsible for informing IANA when the deprecated code points can be completely de-allocated (i.e., made available for new allocations).
フォローアップリクエストが行われない場合、またはドキュメントがStandards Track RFCに進まない場合、WG議長はIANAにコードポイントに「非推奨」のマークを付けること（および割り当てないこと）を通知する責任があります。 WGの議長は、廃止されたコードポイントを完全に割り当て解除できる（つまり、新しい割り当てに使用できるようになった）場合に、IANAに通知する責任をさらに負います。
In particular, it is not IANA's responsibility to track the status of allocations, their expiration, 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 should not be expired while the document is under IESG consideration or waiting in the RFC Editor's queue after approval by the IESG.
ドキュメントがIESGへのレビューのために送信され、送信時にいくつかの初期割り当てが有効である（期限切れではない）場合、ドキュメントがIESGの検討中または承認後にRFCエディターのキューで待機している間、これらの割り当ては期限切れにならないことに注意してください IESGによって。
This document defines procedures for early allocation of code points in the registries with the Standards Action policy and as such directly affects IANA functions.
このドキュメントは、レジストリのコードポイントを標準アクションポリシーで早期に割り当てる手順を定義しているため、IANA機能に直接影響します。
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2434] Narten、T。、およびH. Alvestrand、「RFCでIANA考慮事項セクションを記述するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
It is important to keep in mind 'denial of service' attacks on IANA as a result of the processes 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, but they should be subject to scrutiny to ensure this.
このメモのプロセスの結果として、IANAに対する「サービス拒否」攻撃に留意することが重要です。 すぐに明らかになる2つがあります。早期の割り当てによるコードスペースの枯渇と、IANA自体のプロセスのオーバーロードです。 ここで説明するプロセスは、これらの両方を軽減しようとしますが、これを確認するには精査の対象とする必要があります。
Many thanks to Bert Wijnen, Adrian Farrel, and Bill Fenner for their input.
Bert Wijnen、Adrian Farrel、Bill Fennerに感謝します。
Authors' Addresses
著者のアドレス
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale、CA 94089 USA
EMail: kireeti@juniper.net
メール：kireeti@juniper.net
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
アレックスZininアルカテル701 Eミドルフィールドロードマウンテンビュー、カリフォルニア州94043
EMail: zinin@psg.com
メール：zinin@psg.com
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、制限の対象となります。また、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本書および本書に含まれる情報は「現状のまま」提供され、寄稿者、代表者または代表者（もしあれば）、インターネット協会、インターネットエンジニアリングタスクフォースはすべての保証を放棄します 黙示的であるが、ここに記載されている情報の使用が商品性または特定の目的への適合性の黙示的保証を侵害しないという保証に限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書に記載されている技術の実装または使用に関連すると主張される可能性のある知的財産権またはその他の権利の有効性または範囲、またはそのような権利の下でのライセンスの有無に関して、立場をとりません。 利用可能 また、そのような権利を特定するための独立した努力を行ったことを表すものでもありません。 IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーおよび利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用許可の取得を試みた結果を取得できます。 IETFオンラインIPRリポジトリ（http://www.ietf.org/ipr）から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この標準を実装するために必要な技術を対象とする著作権、特許、特許出願、またはその他の所有権に関心を寄せるよう、あらゆる利害関係者を招待します。 IETFのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在インターネット協会によって提供されています。