[要約] RFC 4020は、標準トラックのコードポイントの早期IANA割り当てに関するガイドラインです。その目的は、コードポイントの効率的な割り当てと管理を確保することです。
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
標準の初期のIANAの割り当ては、コードポイントを追跡します
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).
Copyright（c）The Internet Society（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.
RFCを追跡する標準では、実装が相互運用できるように、さまざまなオブジェクト、メッセージ、またはその他のプロトコルエンティティにコードポイントを割り当てる必要があることがよくあります。これらのコードポイントスペースの多くには、インターネットが割り当てられた番号当局（IANA）が処理するレジストリがあります。いくつかのIANA割り当てポリシーは、RFC 2434 [2434]で説明されています。First Come First Severや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:
デッドロックを破るために、「Pre-RFC」の実装は、「一見未使用の」コードポイントを単に選択することがあります。これらは、後にIANAによって割り当てられたものとは異なることが判明するかもしれません。さらに悪いことに、これらの「Pre-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.
PRE-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は、指定されたドキュメントの場合に早期割り当てが適切であるというコンセンサスがあるかどうかを測定します。
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に早期配分があることを思い出させるのは著者とWG椅子の責任であり、IANAの考慮事項セクションでは、そのように割り当てられたコードポイント値の責任です。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.
ドキュメントが通常割り当てを行うポイントに進む前に早期割り当てが期限切れになった場合、著者と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).
フォローアップリクエストが行われない場合、またはドキュメントが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へのレビューのためにドキュメントが送信され、提出時にいくつかの早期割り当てが有効である場合（期限切れにならない）、承認後のRFCエディターのキューでIESGの検討中または待機中にこれらの割り当てが期限切れにされるべきではないことに注意してください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、「RFCSで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
Alex Zinin Alcatel 701 E Middlefield Rd Mountain View, CA 94043
アレックス・ジニン・アルカテル701 E Middlefield Rd Mountain View、CA 94043
EMail: zinin@psg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。