[要約] RFC 5226は、RFCのIANA考慮セクションの作成に関するガイドラインです。その目的は、IANAに関連する情報を明確かつ一貫した方法で提供し、プロトコルの運用と管理を支援することです。
Network Working Group T. Narten
Request for Comments: 5226 IBM
BCP: 26 H. Alvestrand
Obsoletes: 2434 Google
Category: Best Current Practice May 2008
Guidelines for Writing an IANA Considerations Section in RFCs
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.
Abstract
概要
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).
多くのプロトコルは、定数およびその他のよく知られた値で構成される識別子を使用しています。プロトコルが定義されて展開が開始された後でも、新しい値を割り当てる必要がある場合があります（たとえば、DHCPの新しいオプションタイプ、またはIPSECの新しい暗号化または認証変換）。そのような数量がすべての実装にわたって一貫した値と解釈を確保するために、その割り当ては中央当局によって管理されなければなりません。IETFプロトコルの場合、その役割はインターネットに割り当てられた数字の権限（IANA）によって提供されます。
In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.
IANAが特定の名前空間を慎重に管理するためには、新しい値を割り当てることができる条件、または既存の値の変更を行うことができる条件を説明するガイドラインが必要です。IANAが名前空間の管理に役割を果たすことが期待されている場合、IANAにその役割を説明する明確で簡潔な指示が与えられなければなりません。このドキュメントでは、値を名前空間に割り当てるためのポリシーを策定する際に考慮すべき問題について説明し、IANAに需要を置く文書に含まれなければならない特定のテキストの著者のガイドラインを提供します。
This document obsoletes RFC 2434.
このドキュメントは、RFC 2434を廃止します。
Table of Contents
目次
1. Introduction ....................................................2
2. Why Management of a Namespace May Be Necessary ..................3
3. Designated Experts ..............................................4
3.1. The Motivation for Designated Experts ......................4
3.2. The Role of the Designated Expert ..........................5
3.3. Designated Expert Reviews ..................................7
4. Creating a Registry .............................................8
4.1. Well-Known IANA Policy Definitions .........................9
4.2. What to Put in Documents That Create a Registry ...........12
4.3. Updating IANA Guidelines for Existing Registries ..........15
5. Registering New Values in an Existing Registry .................15
5.1. What to Put in Documents When Registering Values ..........15
5.2. Updating Registrations ....................................17
5.3. Overriding Registration Procedures ........................17
6. Miscellaneous Issues ...........................................18
6.1. When There Are No IANA Actions ............................18
6.2. Namespaces Lacking Documented Guidance ....................19
6.3. After-the-Fact Registrations ..............................19
6.4. Reclaiming Assigned Values ................................19
7. Appeals ........................................................20
8. Mailing Lists ..................................................20
9. Security Considerations ........................................20
10. Changes Relative to RFC 2434 ..................................21
11. Acknowledgments ...............................................22
12. References ....................................................22
12.1. Normative References .....................................22
12.2. Informative References ...................................22
Many protocols make use of fields that contain constants and other well-known values (e.g., the Protocol field in the IP header [IP] or MIME media types [MIME-REG]). Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., a new option type in DHCP [DHCP-OPTIONS] or a new encryption or authentication transform for IPsec [IPSEC]). To ensure that such fields have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA) [IANA-MOU].
多くのプロトコルは、定数やその他のよく知られた値を含むフィールドを使用しています（たとえば、IPヘッダー[IP]またはMIMEメディアタイプ[Mime-Reg]のプロトコルフィールド）。プロトコルが定義され、展開が開始された後でも、新しい値を割り当てる必要がある場合があります（たとえば、DHCP [DHCP-Options]の新しいオプションタイプまたはIPSECの新しい暗号化または認証変換）。そのような分野が異なる実装で一貫した値と解釈を持っていることを確認するには、その割り当ては中央当局によって管理されなければなりません。IETFプロトコルの場合、その役割はインターネットが割り当てられた数字局（IANA）[IANA-MOU]によって提供されます。
In this document, we call the set of possible values for such a field a "namespace"; its actual value may be a text string, a number, or another kind of value. The binding or association of a specific value with a particular purpose within a namespace is called an assigned number (or assigned value, or sometimes a "code point",
このドキュメントでは、そのようなフィールドの可能な値のセットを「名前空間」と呼びます。その実際の値は、テキスト文字列、数値、または別の種類の値です。特定の値と名前空間内の特定の目的との結合または関連付けは、割り当てられた番号（または割り当てられた値、または「コードポイント」と呼ばれます。
"protocol constant", or "protocol parameter"). Each assignment of a value in a namespace is called a registration.
「プロトコル定数」、または「プロトコルパラメーター」）。名前空間内の値の各割り当ては、登録と呼ばれます。
In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values should be assigned or when (and how) modifications to existing values can be made. This document provides guidelines to authors on what sort of text should be added to their documents in order to provide IANA clear guidelines, and it reviews issues that should be considered in formulating an appropriate policy for assigning numbers to name spaces.
IANAが特定の名前空間を慎重に管理するためには、新しい値を割り当てる条件、または既存の値の変更をいつ（どのように）変更できるかを説明するガイドラインが必要です。このドキュメントは、IANAの明確なガイドラインを提供するために、どのようなテキストをドキュメントに追加すべきかについて著者にガイドラインを提供し、スペースに名前を付けるために番号を割り当てるための適切なポリシーを策定する際に考慮すべき問題を確認します。
Not all namespaces require centralized administration. In some cases, it is possible to delegate a namespace in such a way that further assignments can be made independently and with no further (central) coordination. In the Domain Name System, for example, IANA only deals with assignments at the higher levels, while subdomains are administered by the organization to which the space has been delegated. As another example, Object Identifiers (OIDs) as defined by the ITU are also delegated [ASSIGNED]; IANA manages the subtree rooted at "iso.org.dod.internet" (1.3.6.1) . When a namespace is delegated, the scope of IANA is limited to the parts of the namespace where IANA has authority.
すべての名前空間が集中管理を必要とするわけではありません。場合によっては、さらなる割り当てを独立して（中央）調整なしで行うことができるように、名前空間を委任することが可能です。たとえば、ドメイン名システムでは、IANAはより高いレベルでの割り当てのみを扱いますが、サブドメインはスペースが委任された組織によって管理されます。別の例として、ITUで定義されているオブジェクト識別子（OID）も委任されます[割り当て]。IANAは、「iso.org.dod.internet」（1.3.6.1）にルート化されたサブツリーを管理します。名前空間が委任されると、IANAの範囲はIANAが権限を持っている名前空間の部分に限定されます。
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 [KEYWORDS]. For this document, "the specification" as used by RFC 2119 refers to the processing of protocol documents within the IETF standards process.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [キーワード]に記載されているとおりに解釈されます。このドキュメントでは、RFC 2119が使用する「仕様」は、IETF標準プロセス内のプロトコルドキュメントの処理を指します。
One issue to consider in managing a namespace is its size. If the space is small and limited in size, assignments must be made carefully to prevent exhaustion of the space. If the space is essentially unlimited, on the other hand, potential exhaustion will probably not be a practical concern at all. Even when the space is essentially unlimited, however, it is usually desirable to have at least a minimal review prior to assignment in order to:
名前空間を管理する際に考慮すべき問題の1つは、そのサイズです。スペースが小さく、サイズが制限されている場合、スペースの疲労を防ぐために割り当てを慎重に行う必要があります。一方、スペースが本質的に無制限である場合、潜在的な疲労はおそらく実際的な懸念事項ではないでしょう。ただし、スペースが本質的に無制限であっても、通常、課題の前に少なくとも最小限のレビューを行うことが望ましいです。
- prevent the hoarding of or unnecessary wasting of values. For example, if the space consists of text strings, it may be desirable to prevent entities from obtaining large sets of strings that correspond to desirable names (e.g., existing company names).
- 値の貯蔵または不必要な無駄を防ぎます。たとえば、スペースがテキスト文字列で構成されている場合、エンティティが望ましい名前（既存の会社名など）に対応する大きな文字列セットを取得できないようにすることが望ましい場合があります。
- provide a sanity check that the request actually makes sense and is necessary. Experience has shown that some level of minimal review from a subject matter expert is useful to prevent assignments in cases where the request is malformed or not actually needed (i.e., an existing assignment for an essentially equivalent service already exists).
- リクエストが実際に理にかなっており、必要であるという正気のチェックを提供します。経験によると、主題の専門家からのある程度の最小限のレビューは、要求が実際に必要でない場合（つまり、本質的に同等のサービスの既存の割り当てが既に存在する場合）の場合の割り当てを防ぐのに役立つことが示されています。
A second consideration is whether it makes sense to delegate the namespace in some manner. This route should be pursued when appropriate, as it lessens the burden on IANA for dealing with assignments.
2番目の考慮事項は、名前空間を何らかの方法で委任することが理にかなっているかどうかです。このルートは、課題に対処するためのIANAの負担を軽減するため、必要に応じて追求する必要があります。
A third, and perhaps most important, consideration concerns potential impact on the interoperability of unreviewed extensions. Proposed protocol extensions generally benefit from community review; indeed, review is often essential to avoid future interoperability problems [PROTOCOL-EXT].
3番目の、そしておそらく最も重要な考慮事項は、未確認の拡張機能の相互運用性への潜在的な影響に関するものです。提案されたプロトコル拡張は一般に、コミュニティのレビューの恩恵を受けます。実際、将来の相互運用性の問題を回避するためには、レビューがしばしば不可欠です[Protocol-Ext]。
When the namespace is essentially unlimited and there are no potential interoperability issues, assigned numbers can safely be given out to anyone without any subjective review. In such cases, IANA can make assignments directly, provided that IANA is given specific instructions on what types of requests it should grant, and what information must be provided as part of a well-formed request for an assigned number.
名前空間が本質的に無制限であり、潜在的な相互運用性の問題がない場合、割り当てられた数値は、主観的なレビューなしで誰にでも安全に配信できます。そのような場合、IANAは、どのタイプのリクエストを許可するか、および割り当てられた番号の適切に形成されたリクエストの一部として提供されなければならない情報の特定の指示が与えられている場合、IANAは直接割り当てを行うことができます。
It should be noted that IANA does not create or define assignment policy itself; rather, it carries out policies that have been defined by others and published in RFCs. IANA must be given a set of guidelines that allow it to make allocation decisions with minimal subjectivity and without requiring any technical expertise with respect to the protocols that make use of a registry.
IANAは割り当てポリシー自体を作成または定義しないことに注意する必要があります。むしろ、他の人によって定義され、RFCSで公開されたポリシーを実行します。IANAには、主観性を最小限に抑え、レジストリを使用するプロトコルに関して技術的な専門知識を必要とせずに、割り当て決定を行うことを可能にする一連のガイドラインを与えなければなりません。
In many cases, some review of prospective allocations is appropriate, and the question becomes who should perform the review and what is the purpose of the review. One might think that an IETF working group (WG) familiar with the namespace at hand should be consulted. In practice, however, WGs eventually disband, so they cannot be considered a permanent evaluator. It is also possible for namespaces to be created through individual submission documents, for which no WG is ever formed.
多くの場合、将来の割り当てのいくつかのレビューが適切であり、質問は誰がレビューを実行するべきであり、レビューの目的は何ですか。手元の名前空間に精通しているIETFワーキンググループ（WG）に相談する必要があると思うかもしれません。ただし、実際には、WGSは最終的に解散するため、恒久的な評価者と見なすことはできません。また、個々の提出書類を介して名前空間を作成することも可能です。
One way to ensure community review of prospective assignments is to have the requester submit a document for publication as an RFC. Such an action helps ensure that the specification is publicly and permanently available, and it allows some review of the specification prior to publication and assignment of the requested code points. This is the preferred way of ensuring review, and is particularly important if any potential interoperability issues can arise. For example, some assignments are not just assignments, but also involve an element of protocol specification. A new option may define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols on which they are built.
将来の割り当てのコミュニティレビューを確実に確認する1つの方法は、RequesterにRFCとして公開のためにドキュメントを提出させることです。このようなアクションは、仕様が公開かつ永続的に利用可能であることを確認するのに役立ち、要求されたコードポイントの公開と割り当ての前に仕様のある程度のレビューを可能にします。これは、レビューを確保するための好ましい方法であり、潜在的な相互運用性の問題が発生する可能性がある場合に特に重要です。たとえば、一部の割り当ては単なる割り当てではなく、プロトコル仕様の要素も含まれます。新しいオプションは、解析して作用する必要があるフィールドを定義する場合があります。これは、（指定が不十分な場合）他のオプションのアーキテクチャや構築されたベースプロトコルにきれいに適合しない場合があります。
In some cases, however, the burden of publishing an RFC in order to get an assignment is excessive. However, it is generally still useful (and sometimes necessary) to discuss proposed additions on a mailing list dedicated to the purpose (e.g., the ietf-types@iana.org for media types) or on a more general mailing list (e.g., that of a current or former IETF WG). Such a mailing list provides a way for new registrations to be publicly reviewed prior to getting assigned, or gives advice to persons wanting help in understanding what a proper registration should contain.
ただし、場合によっては、割り当てを取得するためのRFCを公開する負担は過剰です。ただし、目的（メディアタイプのIETF-Types@iana.orgなど）またはより一般的なメーリングリスト（例えば、そのことに専念しているメーリングリストで提案された追加を議論することは、一般的に有用です（また必要な場合もあります）現在または以前のIETF WGの）。このようなメーリングリストは、割り当てられる前に新しい登録を公開する方法を提供します。または、適切な登録が何を含めるべきかを理解するために助けを求めている人にアドバイスを提供します。
While discussion on a mailing list can provide valuable technical feedback, opinions may vary and discussions may continue for some time without clear resolution. In addition, IANA cannot participate in all of these mailing lists and cannot determine if or when such discussions reach consensus. Therefore, IANA relies on a "designated expert" for advice regarding the specific question of whether an assignment should be made. The designated expert is an individual who is responsible for carrying out an appropriate evaluation and returning a recommendation to IANA.
メーリングリストでの議論は貴重な技術的フィードバックを提供できますが、意見は異なる場合があり、議論は明確な解決なしにしばらく続くことがあります。さらに、IANAはこれらのメーリングリストのすべてに参加することができず、そのような議論がコンセンサスに達するかどうか、いついつか到達するかを判断することはできません。したがって、IANAは、割り当てを行うべきかどうかの特定の質問に関するアドバイスについて、「指定された専門家」に依存しています。指定された専門家は、適切な評価を実施し、IANAへの勧告を返す責任がある個人です。
It should be noted that a key motivation for having designated experts is for the IETF to provide IANA with a subject matter expert to whom the evaluation process can be delegated. IANA forwards requests for an assignment to the expert for evaluation, and the expert (after performing the evaluation) informs IANA as to whether or not to make the assignment or registration.
指定された専門家を持つための重要な動機は、IETFがIANAに評価プロセスを委任できる主題の専門家に提供することであることに注意する必要があります。IANAは評価のために専門家への割り当ての要求を転送し、専門家（評価を実行した後）は、IANAに割り当てまたは登録を行うかどうかについて通知します。
The designated expert is responsible for initiating and coordinating the appropriate review of an assignment request. The review may be wide or narrow, depending on the situation and the judgment of the designated expert. This may involve consultation with a set of technology experts, discussion on a public mailing list, consultation with a working group (or its mailing list if the working group has disbanded), etc. Ideally, the designated expert follows specific review criteria as documented with the protocol that creates or uses the namespace. (See the IANA Considerations sections of [RFC3748] and [RFC3575] for examples that have been done for specific namespaces.)
指定された専門家は、割り当てリクエストの適切なレビューを開始および調整する責任があります。レビューは、指定された専門家の状況と判断に応じて、広くまたは狭い場合があります。これには、一連のテクノロジーの専門家との協議、公開メーリングリストに関する議論、ワーキンググループとの相談（またはワーキンググループが解散した場合のメーリングリスト）などが含まれる場合があります。理想的には、指定された専門家は、名前空間を作成または使用するプロトコル。（特定の名前空間に対して行われた例については、[RFC3748]および[RFC3575]のIANAに関する考慮事項セクションを参照してください。）
Designated experts are expected to be able to defend their decisions to the IETF community, and the evaluation process is not intended to be secretive or bestow unquestioned power on the expert. Experts are expected to apply applicable documented review or vetting procedures, or in the absence of documented criteria, follow generally accepted norms, e.g., those in Section 3.3.
指定された専門家は、IETFコミュニティに意思決定を守ることができると予想されており、評価プロセスは、専門家に秘密主義または疑いのない力を授与することを意図していません。専門家は、適用可能な文書化されたレビューまたは審査手順を適用することが期待されています。または、文書化された基準がない場合、一般に受け入れられた基準、例えばセクション3.3の規範に従います。
Section 5.2 discusses disputes and appeals in more detail.
セクション5.2では、紛争と控訴についてより詳細に説明します。
Designated experts are appointed by the IESG (normally upon recommendation by the relevant Area Director). They are typically named at the time a document creating or updating a namespace is approved by the IESG, but as experts originally appointed may later become unavailable, the IESG will appoint replacements if necessary.
指定された専門家は、IESGによって任命されます（通常、関連するエリアディレクターによる勧告に応じて）。それらは通常、名前空間の作成または更新のドキュメントがIESGによって承認された時点で名前が付けられていますが、元々任命された専門家が後に利用できなくなる可能性があるため、IESGは必要に応じて交換を任命します。
For some registries, it has proven useful to have multiple designated experts. Sometimes those experts work together in evaluating a request, while in other cases additional experts serve as backups. In cases of disagreement among those experts, it is the responsibility of those experts to make a single clear recommendation to IANA. It is not appropriate for IANA to resolve disputes among experts. In extreme situations (e.g., deadlock), the IESG may need to step in to resolve the problem.
一部のレジストリでは、複数の指定された専門家を持つことが有用であることが証明されています。これらの専門家がリクエストの評価に協力している間、他のケースでは追加の専門家がバックアップとして機能する場合があります。これらの専門家の間で意見の相違がある場合、IANAに1つの明確な推奨を行うことは、これらの専門家の責任です。IANAが専門家間の紛争を解決することは適切ではありません。極端な状況（デッドロックなど）では、IESGは問題を解決するために介入する必要がある場合があります。
In registries where a pool of experts evaluates requests, the pool should have a single chair responsible for defining how requests are to be assigned to and reviewed by experts. In some cases, the expert pool may consist of a primary and backups, with the backups involved only when the primary expert is unavailable. In other cases, IANA might assign requests to individual members in sequential or approximate random order. In the event that IANA finds itself having received conflicting advice from its experts, it is the responsibility of the pool's chair to resolve the issue and provide IANA with clear instructions.
専門家のプールがリクエストを評価するレジストリでは、プールには、専門家がリクエストをどのように割り当て、レビューするかを定義する責任者の椅子を1つ持っている必要があります。場合によっては、エキスパートプールはプライマリとバックアップで構成され、バックアップはプライマリエキスパートが利用できない場合にのみ関与します。それ以外の場合、IANAは、順次または概算のランダムな順序で個々のメンバーにリクエストを割り当てる場合があります。Ianaが専門家から矛盾するアドバイスを受けたと感じた場合、問題を解決し、IANAに明確な指示を提供することはプールの椅子の責任です。
Since the designated experts are appointed by the IESG, they may be removed by the IESG.
指定された専門家はIESGによって任命されるため、IESGによって削除される場合があります。
In the eight years since RFC 2434 was published and has been put to use, experience has led to the following observations:
RFC 2434が公開され、使用されてから8年間で、経験は次の観察につながりました。
- A designated expert must respond in a timely fashion, normally within a week for simple requests to a few weeks for more complex ones. Unreasonable delays can cause significant problems for those needing assignments, such as when products need code points to ship. This is not to say that all reviews can be completed under a firm deadline, but they must be started, and the requester and IANA should have some transparency into the process if an answer cannot be given quickly.
- 指定された専門家は、通常、1週間以内に数週間にわたってより複雑なものを求めて1週間以内に対応する必要があります。不合理な遅延は、製品が出荷するためにコードポイントが必要な場合など、割り当てを必要とする人に重大な問題を引き起こす可能性があります。これは、すべてのレビューをしっかりとした締め切りで完了できると言うことではありませんが、それらを開始する必要があり、要求者とIANAは、回答を迅速に与えられない場合、プロセスにある程度の透明性を持つ必要があります。
- If a designated expert does not respond to IANA's requests within a reasonable period of time, either with a response or with a reasonable explanation for the delay (e.g., some requests may be particularly complex), and if this is a recurring event, IANA must raise the issue with the IESG. Because of the problems caused by delayed evaluations and assignments, the IESG should take appropriate actions to ensure that the expert understands and accepts his or her responsibilities, or appoint a new expert.
- 指定された専門家が、応答または遅延の合理的な説明（例えば、一部の要求が特に複雑な場合がある場合）のいずれかで、合理的な期間内にIANAの要求に応答しない場合、これが繰り返しのイベントである場合、IANAはIANAが必要とする必要があります。IESGで問題を提起します。評価と割り当ての遅れによって引き起こされる問題のため、IESGは、専門家が自分の責任を理解して受け入れることを保証するために、または新しい専門家を任命するために適切な措置を講じる必要があります。
- The designated expert is not required to personally bear the burden of evaluating and deciding all requests, but acts as a shepherd for the request, enlisting the help of others as appropriate. In the case that a request is denied, and rejecting the request is likely to be controversial, the expert should have the support of other subject matter experts. That is, the expert must be able to defend a decision to the community as a whole.
- 指定された専門家は、すべての要求を評価して決定するという負担を個人的に負担する必要はありませんが、要求の羊飼いとして行動し、必要に応じて他の人の助けを求めます。要求が拒否され、リクエストを拒否することが議論の余地がある可能性が高い場合、専門家は他の主題の専門家のサポートを受ける必要があります。つまり、専門家はコミュニティ全体への決定を守ることができなければなりません。
In the case where a designated expert is used, but there are no specific documented criteria for performing an evaluation, the presumption should be that a code point should be granted, unless there is a compelling reason to the contrary. Possible reasons to deny a request include:
指定された専門家が使用されているが、評価を実行するための特定の文書化された基準はない場合、反対の理由がない限り、コードポイントが付与されるべきであると推定されるべきです。リクエストを拒否する考えられる理由は次のとおりです。
- scarcity of code points, where the finite remaining code points should be prudently managed, or when a request for a large number of code points is made, when a single code point is the norm.
- 有限の残りのコードポイントを慎重に管理する必要があるコードポイントの不足、または単一のコードポイントが標準である場合、多数のコードポイントのリクエストが作成された場合。
- documentation is not of sufficient clarity to evaluate or ensure interoperability.
- ドキュメントは、相互運用性を評価または確保するのに十分な明確さではありません。
- the code point is needed for a protocol extension, but the extension is not consistent with the documented (or generally understood) architecture of the base protocol being extended, and would be harmful to the protocol if widely deployed. It is not the intent that "inconsistencies" refer to minor differences "of a personal preference nature". Instead, they refer to significant differences such as inconsistencies with the underlying security model, implying a change to the semantics of an existing message type or operation, requiring unwarranted changes in deployed systems (compared with alternate ways of achieving a similar result), etc.
- コードポイントはプロトコル拡張に必要ですが、拡張機能は、拡張されているベースプロトコルの文書化された（または一般的に理解されている）アーキテクチャと一致しておらず、広く展開された場合、プロトコルに有害です。「矛盾」が「個人的な好みの性質の小さな違いを指す」という意図ではありません。代わりに、基礎となるセキュリティモデルとの矛盾などの大きな違いを指し、既存のメッセージタイプまたは操作のセマンティクスの変更を意味し、展開システムの不当な変更が必要です（同様の結果を達成する代替方法と比較）。
- the extension would cause problems with existing deployed systems.
- 拡張機能は、既存の展開されたシステムに問題を引き起こします。
- the extension would conflict with one under active development by the IETF, and having both would harm rather than foster interoperability.
- この拡張は、IETFによるアクティブな開発中のものと競合し、両方を持つことは相互運用性を促進するのではなく、害を及ぼすでしょう。
Creating a registry involves describing the namespaces to be created, an initial set of assignments (if appropriate), and guidelines on how future assignments are to be made.
レジストリを作成するには、作成する名前空間、割り当ての初期セット（必要に応じて）、および将来の割り当ての作成方法に関するガイドラインを説明することが含まれます。
Once a registry has been created, IANA records assignments that have been made. The following labels describe the status of an individual (or range) of assignments:
レジストリが作成されると、IANAは行われた割り当てを記録します。次のラベルは、課題の個人（または範囲）のステータスを説明しています。
Private Use: Private use only (not assigned), as described in Section 4.1.
個人用：セクション4.1で説明されているように、プライベート使用のみ（割り当てられていません）。
Experimental: Available for experimental use as described in [EXPERIMENTATION]. IANA does not record specific assignments for any particular use.
実験：[実験]で説明されているように実験的に使用できます。IANAは、特定の使用に関する特定の割り当てを記録していません。
Unassigned: Unused and available for assignment via documented procedures.
未割り当て：未使用で、文書化された手順を介して割り当て可能。
Reserved: Not to be assigned. Reserved values are held for special uses, such as to extend the namespace when it become exhausted. Reserved values are not available for general assignment.
予約済み：割り当てられない。予約済みの値は、名前空間が使い果たされたときに拡張するなど、特別な用途のために保持されます。一般的な割り当てには予約済みの値は利用できません。
The following are some defined policies, some of which are in use today. These cover a range of typical policies that have been used to date to describe the procedure for assigning new values in a namespace. It is not required that documents use these terms; the actual requirement is that the instructions to IANA are clear and unambiguous. However, use of these terms is RECOMMENDED where possible, since their meaning is widely understood.
以下は、いくつかの定義されたポリシーであり、その一部は今日使用されています。これらは、名前空間で新しい値を割り当てる手順を説明するためにこれまで使用されているさまざまな典型的なポリシーをカバーしています。ドキュメントがこれらの用語を使用することは必須ではありません。実際の要件は、IANAへの指示が明確で明確であることです。ただし、その意味は広く理解されているため、これらの用語の使用が可能な場合は推奨されます。
Private Use - For private or local use only, with the type and purpose defined by the local site. No attempt is made to prevent multiple sites from using the same value in different (and incompatible) ways. There is no need for IANA to review such assignments (since IANA does not record them) and assignments are not generally useful for broad interoperability. It is the responsibility of the sites making use of the Private Use range to ensure that no conflicts occur (within the intended scope of use).
プライベート使用 - プライベートまたはローカル使用のみ、ローカルサイトで定義されているタイプと目的。複数のサイトが異なる（および互換性のない）方法で同じ値を使用するのを防ぐ試みは行われません。IANAがそのような割り当てをレビューする必要はありません（IANAはそれらを記録していないため）、割り当ては一般的に幅広い相互運用性に役立ちません。プライベート使用範囲を利用して、競合が発生しないようにするサイトの責任です（意図した使用範囲内）。
Examples: Site-specific options in DHCP [DHCP-IANA], Fibre Channel Port Type Registry [RFC4044], Exchange Types in the IKEv2 header [RFC4306].
例：DHCP [DHCP-AINA]のサイト固有のオプション、ファイバーチャネルポートタイプレジストリ[RFC4044]、IKEV2ヘッダー[RFC4306]の交換タイプ。
Experimental Use - Similar to private or local use only, with the purpose being to facilitate experimentation. See [EXPERIMENTATION] for details.
実験的使用 - プライベートまたはローカルの使用のみに似ており、目的は実験を促進することです。詳細については、[実験]を参照してください。
Example: Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers [RFC4727].
例：IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダー[RFC4727]の実験値。
Hierarchical Allocation - Delegated managers can assign values provided they have been given control over that part of the namespace. IANA controls the higher levels of the namespace according to one of the other policies.
階層的な割り当て - 委任されたマネージャーは、名前空間のその部分を制御されている場合、値を割り当てることができます。IANAは、他のポリシーの1つに従って、名前空間のより高いレベルを制御します。
Examples: DNS names, Object Identifiers, IP addresses.
例：DNS名、オブジェクト識別子、IPアドレス。
First Come First Served - Assignments are made to anyone on a first come, first served basis. There is no substantive review of the request, other than to ensure that it is well-formed and doesn't duplicate an existing assignment. However, requests must include a minimal amount of clerical information, such as a point of contact (including an email address) and a brief description of how the value will be used. Additional information specific to the type of value requested may also need to be provided, as defined by the namespace. For numbers, the exact value is generally assigned by IANA; with names, specific text strings can usually be requested.
最初に来る - 先着順で課題が行われます。リクエストの実質的なレビューは、既存の割り当てを整理し、複製しないようにする以外にはありません。ただし、リクエストには、連絡先（電子メールアドレスを含む）などの最小限の事務情報や、値の使用方法の簡単な説明を含める必要があります。名前空間で定義されているように、要求された値のタイプに固有の追加情報も提供する必要があります。数値の場合、正確な値は一般にIANAによって割り当てられます。名前を使用すると、通常、特定のテキスト文字列を要求できます。
Examples: SASL mechanism names [RFC4422], LDAP Protocol Mechanisms, and LDAP Syntax [RFC4520].
例：SASLメカニズム名[RFC4422]、LDAPプロトコルメカニズム、およびLDAP構文[RFC4520]。
Expert Review (or Designated Expert) - approval by a Designated Expert is required. The required documentation and review criteria for use by the Designated Expert should be provided when defining the registry. For example, see Sections 6 and 7.2 in [RFC3748].
Examples: EAP Method Types [RFC3748], HTTP Digest AKA algorithm versions [RFC4169], URI schemes [RFC4395], GEOPRIV Location Types [RFC4589].
例：EAPメソッドタイプ[RFC3748]、HTTPダイジェスト別名アルゴリズムバージョン[RFC4169]、URIスキーム[RFC4395]、Geoprivの位置タイプ[RFC4589]。
Specification Required - Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. For RFC publication, the normal RFC review process is expected to provide the necessary review for interoperability, though the Designated Expert may be a particularly well-qualified person to perform such a review.
Examples: Diffserv-aware TE Bandwidth Constraints Model Identifiers [RFC4124], TLS ClientCertificateType Identifiers [RFC4346], ROHC Profile Identifiers [RFC4995].
例：DiffServ-Aware TE帯域幅の制約モデル識別子[RFC4124]、TLS ClientCertificateType識別子[RFC4346]、ROHCプロファイル識別子[RFC4995]。
RFC Required - RFC publication (either as an IETF submission or as an RFC Editor Independent submission [RFC3932]) suffices. Unless otherwise specified, any type of RFC is sufficient (e.g., Informational, Experimental, Standards Track, etc.).
RFC要求-RFC出版物（IETF提出物として、またはRFCエディターに独立した提出[RFC3932]として）で十分です。特に指定されていない限り、あらゆるタイプのRFCで十分です（たとえば、情報、実験、標準の追跡など）。
IETF Review - (Formerly called "IETF Consensus" in [IANA-CONSIDERATIONS]) New values are assigned only through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The intention is that the document and proposed assignment will be reviewed by the IESG and appropriate IETF WGs (or experts, if suitable working groups no longer exist) to ensure that the proposed assignment will not negatively impact interoperability or otherwise extend IETF protocols in an inappropriate or damaging manner.
IETFレビュー - （以前は[IANA-Considerations]の「IETFコンセンサス」と呼ばれていた）新しい値は、IESGを介してADスポンサーまたはIETF WGドキュメント[RFC3932] [RFC3978]としてIESGを介して羊飼いされたRFCを介してのみ割り当てられます。意図は、ドキュメントと提案された割り当てがIESGおよび適切なIETF WGS（または適切なワーキンググループが存在しなくなった場合、専門家）によってレビューされることです。またはダメージマナー。
To ensure adequate community review, such documents are shepherded through the IESG as AD-sponsored (or WG) documents with an IETF Last Call.
適切なコミュニティレビューを確保するために、そのような文書は、IETFの最後の呼び出しで広告支援（またはWG）ドキュメントとしてIESGを通じて羊飼いされます。
Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake Hello Extensions [RFC4366].
例：Ipseckeyアルゴリズムタイプ[RFC4025]、直径[RFC4005]のアカウンティング-Auth-Method AVP値、TLSハンドシェイクハローエクステンション[RFC4366]。
Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG.
標準アクション - 値は、IESGによって承認されたRFCを追跡する標準にのみ割り当てられます。
Examples: BGP message types [RFC4271], Mobile Node Identifier option types [RFC4283], DCCP Packet Types [RFC4340].
例：BGPメッセージタイプ[RFC4271]、モバイルノード識別子オプションタイプ[RFC4283]、DCCPパケットタイプ[RFC4340]。
IESG Approval - New assignments may be approved by the IESG. Although there is no requirement that the request be documented in an RFC, the IESG has discretion to request documents or other supporting materials on a case-by-case basis.
IESGの承認 - 新しい割り当てはIESGによって承認される場合があります。リクエストがRFCに文書化されるという要件はありませんが、IESGには、ケースバイケースでドキュメントまたはその他のサポート資料を要求する裁量があります。
IESG Approval is not intended to be used often or as a "common case"; indeed, it has seldom been used in practice during the period RFC 2434 was in effect. Rather, it is intended to be available in conjunction with other policies as a fall-back mechanism in the case where one of the other allowable approval mechanisms cannot be employed in a timely fashion or for some other compelling reason. IESG Approval is not intended to circumvent the public review processes implied by other policies that could have been employed for a particular assignment. IESG Approval would be appropriate, however, in cases where expediency is desired and there is strong consensus for making the assignment (e.g., WG consensus).
IESGの承認は、頻繁に使用されることを意図していません。実際、RFC 2434が有効な期間中に実際に使用されることはめったにありませんでした。むしろ、他の許容承認メカニズムのいずれかがタイムリーまたは他の説得力のある理由で採用できない場合、フォールバックメカニズムとして他のポリシーと併せて利用できることを目的としています。IESGの承認は、特定の課題に採用された可能性のある他のポリシーによって暗示される公開レビュープロセスを回避することを意図していません。ただし、IESGの承認は、便宜が必要な場合に適切であり、割り当てを行うための強力なコンセンサスがあります（例：WGコンセンサス）。
The following guidelines are suggested for any evaluation under IESG Approval:
IESGの承認に基づく評価については、次のガイドラインが提案されています。
- The IESG can (and should) reject a request if another path for registration is available that is more appropriate and there is no compelling reason to use that path.
- IESGは、登録の別のパスがより適切であり、そのパスを使用する説得力のある理由がない場合、リクエストを拒否することができます（そしてすべきです）。
- Before approving a request, the community should be consulted, via a "call for comments" that provides as much information as is reasonably possible about the request.
- リクエストを承認する前に、リクエストについて合理的に可能な限り多くの情報を提供する「コメントの呼び出し」を介して、コミュニティに相談する必要があります。
Examples: IPv4 Multicast address assignments [RFC3171], IPv4 IGMP Type and Code values [RFC3228], Mobile IPv6 Mobility Header Type and Option values [RFC3775].
例：IPv4マルチキャストアドレスの割り当て[RFC3171]、IPv4 IGMPタイプとコード値[RFC3228]、モバイルIPv6モビリティヘッダータイプとオプション値[RFC3775]。
It should be noted that it often makes sense to partition a namespace into multiple categories, with assignments within each category handled differently. For example, many protocols now partition namespaces into two (or even more) parts, where one range is reserved for Private or Experimental Use, while other ranges are reserved for globally unique assignments assigned following some review process. Dividing a namespace into ranges makes it possible to have different policies in place for different ranges.
名前空間を複数のカテゴリに分割することがしばしば理にかなっていることに注意してください。各カテゴリ内の割り当ては異なる方法で処理されます。たとえば、多くのプロトコルは、1つの範囲がプライベートまたは実験的使用のために予約されている2つの（またはさらに多くの）パーツに名前空間を分割するようになりましたが、他の範囲はレビュープロセスに従って割り当てられたグローバルに一意の割り当てのために予約されています。名前空間を範囲に分割すると、さまざまな範囲に異なるポリシーを設置することができます。
Examples: LDAP [RFC4520], Pseudowire Edge to Edge Emulation (PWE3) [RFC4446].
例：LDAP [RFC4520]、Pseudowire to Edge Emulation（PWE3）[RFC4446]。
The previous sections presented some issues that should be considered in formulating a policy for assigning values in namespaces. It is the working group and/or document author's job to formulate an appropriate policy and specify it in the appropriate document. In almost all cases, having an explicit "IANA Considerations" section is appropriate. The following and later sections define what is needed for the different types of IANA actions.
前のセクションでは、名前空間に値を割り当てるためのポリシーを策定する際に考慮すべきいくつかの問題を提示しました。適切なポリシーを策定し、適切な文書で指定するのは、ワーキンググループおよび/または文書著者の仕事です。ほとんどすべての場合、明示的な「IANAの考慮事項」セクションが適切です。以下および後のセクションでは、さまざまな種類のIANAアクションに必要なものを定義します。
Documents that create a new namespace (or modify the definition of an existing space) and that expect IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST provide clear instructions on details of the namespace. In particular, instructions MUST include:
1) The name of the registry (or sub-registry) being created and/or maintained. The name will appear on the IANA web page and will be referred to in future documents that need to allocate a value from the new space. The full name (and abbreviation, if appropriate) should be provided. It is highly desirable that the chosen name not be easily confusable with the name of another registry. When creating a sub-registry, the registry that it is a part of should be clearly identified. When referring to an already existing registry, providing a URL to precisely identify the registry is helpful. All such URLs, however, will be removed from the RFC prior to final publication. For example, documents could contain: [TO BE REMOVED: This registration should take place at the following location: http://www.iana.org/assignments/foobar-registry]
1) 作成および/または維持されているレジストリ（またはサブレジストリ）の名前。名前はIANA Webページに表示され、新しいスペースから値を割り当てる必要がある将来のドキュメントで参照されます。フルネーム（および必要に応じて略語）を提供する必要があります。選択された名前が別のレジストリの名前と簡単に混乱できないことは非常に望ましいです。サブレジストリを作成する場合、それが一部であるレジストリを明確に識別する必要があります。すでに既存のレジストリを参照する場合、レジストリを正確に識別するためのURLを提供することが役立ちます。ただし、そのようなURLはすべて、最終公開前にRFCから削除されます。たとえば、ドキュメントには次のものが含まれます。
2) What information must be provided as part of a request in order to assign a new value. This information may include the need to document relevant security considerations, if any.
2) 新しい値を割り当てるために、リクエストの一部として提供されなければならない情報。この情報には、関連するセキュリティ上の考慮事項がある場合は、文書化する必要性が含まれる場合があります。
3) The review process that will apply to all future requests for a value from the namespace.
3) 名前空間からの値に対するすべての将来の要求に適用されるレビュープロセス。
Note: When a Designated Expert is used, documents MUST NOT name the Designated Expert in the document itself; instead, the name should be relayed to the appropriate Area Director at the time the document is sent to the IESG for approval.
注：指定された専門家が使用されている場合、ドキュメントはドキュメント自体の指定された専門家に名前を付けてはなりません。代わりに、ドキュメントが承認のためにIESGに送信されたときに、名前を適切なエリアディレクターに中継する必要があります。
If the request should also be reviewed on a specific public mailing list (such as the ietf-types@iana.org for media types), that mailing address should be specified. Note, however, that when mailing lists are specified, the requirement for a Designated Expert MUST also be specified (see Section 3).
リクエストを特定の公開メーリングリスト（メディアタイプのIETF-Types@iana.orgなど）でレビューする必要がある場合、その郵送先住所を指定する必要があります。ただし、メーリングリストが指定されている場合、指定された専門家の要件も指定する必要があることに注意してください（セクション3を参照）。
If IANA is expected to make assignments without requiring an outside review, sufficient guidance MUST be provided so that the requests can be evaluated with minimal subjectivity.
IANAが外部のレビューを必要とせずに割り当てを行うことが期待される場合、リクエストを最小限の主観性で評価できるように、十分なガイダンスを提供する必要があります。
4) The size, format, and syntax of registry entries. When creating a new name/number space, authors must describe any technical requirements on registry (and sub-registry) values (e.g., valid ranges for integers, length limitations on strings, etc.) as well as the exact format in which registry values should be displayed. For number assignments, one should specify whether values are to be recorded in decimal, hexadecimal, or some other format. For strings, the encoding format should be specified (e.g., ASCII, UTF8, etc.). Authors should also clearly specify what fields to record in the registry.
4) レジストリエントリのサイズ、形式、および構文。新しい名前/数字のスペースを作成する場合、著者は、レジストリ（およびサブレジストリ）値に関する技術要件（整数の有効な範囲、文字列の長さの制限など）およびレジストリ値の正確な形式を説明する必要があります。表示する必要があります。数値割り当てについては、値を10進、16進数、またはその他の形式で記録するかどうかを指定する必要があります。文字列の場合、エンコード形式を指定する必要があります（ASCII、UTF8など）。著者はまた、レジストリに記録するフィールドを明確に指定する必要があります。
5) Initial assignments and reservations. Clear instructions should be provided to identify any initial assignments or registrations. In addition, any ranges that are to be reserved for "Private Use", "Reserved", "Unassigned", etc. should be clearly indicated.
5) 初期割り当てと予約。最初の割り当てまたは登録を特定するには、明確な指示を提供する必要があります。さらに、「私的使用」、「予約済み」、「割り当てられていない」などのために予約される範囲は明確に示される必要があります。
When specifying the process for making future assignments, it is quite acceptable to pick one (or more) of the example policies listed in Section 4.1 and refer to it by name. Indeed, this is the preferred mechanism in those cases where the sample policies provide the desired level of review. It is also acceptable to cite one of the above policies and include additional guidelines for what kind of considerations should be taken into account by the review process. For example, RADIUS [RFC3575] specifies the use of a Designated Expert, but includes specific additional criteria the Designated Expert should follow.
For example, a document could say something like:
たとえば、ドキュメントは次のようなことを言うことができます。
This document defines a new DHCP option, entitled "FooBar" (see Section y), assigned a value of TBD1 from the DHCP Option space [to be removed upon publication: http://www.iana.org/assignments/bootp-dhcp-parameters] [DHCP-OPTIONS] [DHCP-IANA]:
このドキュメントでは、「Foobar」というタイトルの新しいDHCPオプション（セクションYを参照）を定義し、DHCPオプションスペースからTBD1の値を割り当てました[出版時に削除される：http：//www.iana.org/assignments/bootp-dhcp-parameters] [dhcp-options] [dhcp-aiana]：
Data
Tag Name Length Meaning
---- ---- ------ -------
TBD1 FooBar N FooBar server
The FooBar option also defines an 8-bit FooType field, for which IANA is to create and maintain a new sub-registry entitled "FooType values" under the FooBar option. Initial values for the DHCP FooBar FooType registry are given below; future assignments are to be made through Expert Review [IANA-CONSIDERATIONS]. Assignments consist of a DHCP FooBar FooType name and its associated value.
Foobarオプションは、Foobarオプションの下で「Footype Values」というタイトルの新しいサブレジストリを作成および維持する8ビットフットタイプフィールドも定義します。DHCP Foobar Footypeレジストリの初期値を以下に示します。将来の割り当ては、専門家のレビュー[IANA-Consididerations]を通じて行われます。割り当ては、DHCP Foobar Footype名とそれに関連する値で構成されています。
Value DHCP FooBar FooType Name Definition
---- ------------------------ ----------
0 Reserved
1 Frobnitz See Section y.1
2 NitzFrob See Section y.2
3-254 Unassigned
255 Reserved
For examples of documents that provide detailed guidance to IANA on the issue of assigning numbers, consult [RFC2929], [RFC3575], [RFC3968], and [RFC4520].
番号の割り当ての問題に関するIANAに詳細なガイダンスを提供するドキュメントの例については、[RFC2929]、[RFC3575]、[RFC3968]、および[RFC4520]を参照してください。
Updating the registration process for an already existing (i.e., previously created) namespace (whether created explicitly or implicitly) follows a process similar to that used when creating a new namespace. That is, a document is produced that makes reference to the existing namespace and then provides detailed guidelines for handling assignments in each individual namespace. Such documents are normally processed as Best Current Practices (BCPs) [IETF-PROCESS].
既存の（つまり、以前に作成された）名前空間（明示的または暗黙的に作成されたかどうか）の登録プロセスの更新は、新しい名前空間を作成するときに使用されるプロセスと同様のプロセスに従います。つまり、既存の名前空間を参照し、個々の名前空間で割り当てを処理するための詳細なガイドラインを提供するドキュメントが作成されます。このようなドキュメントは通常、最良の現在のプラクティス（BCPS）[IETFプロセス]として処理されます。
Example documents that updated the guidelines for managing (then) pre-existing registries include: [RFC2929], [RFC3228], and [RFC3575].
（Then）既存のレジストリの管理に関するガイドラインを更新した例には、[RFC2929]、[RFC3228]、および[RFC3575]が含まれます。
Often, documents request an assignment from an already existing namespace (i.e., one created by a previously published RFC). In such cases:
多くの場合、ドキュメントは、既存の名前空間（つまり、以前に公開されたRFCによって作成された名前）からの割り当てを要求します。そのような場合：
- Documents should clearly identify the namespace in which each value is to be registered. If the registration goes into a sub-registry, the author should clearly describe where the assignment or registration should go. It is helpful to use the exact namespace name as listed on the IANA web page (and defining RFC), and cite the RFC where the namespace is defined.
- ドキュメントは、各値を登録する名前空間を明確に識別する必要があります。登録がサブレジストリに入った場合、著者は、割り当てまたは登録がどこに行くべきかを明確に説明する必要があります。IANA Webページ（およびRFCを定義する）にリストされている正確な名前空間名を使用し、名前空間が定義されているRFCを引用すると役立ちます。
Note 1: There is no need to mention what the assignment policy for new assignments is, as that should be clear from the references.
注1：参照から明確にする必要があるため、新しい割り当ての割り当てポリシーが何であるかについて言及する必要はありません。
Note 2: When referring to an existing registry, providing a URL to precisely identify the registry is helpful. Such URLs, however, should usually be removed from the RFC prior to final publication, since IANA URLs are not guaranteed to be stable in the future. In cases where it is important to include a URL in the document, IANA should concur on its inclusion.
注2：既存のレジストリを参照する場合、レジストリを正確に識別するためのURLを提供することが役立ちます。ただし、IANA URLは将来安定することは保証されていないため、このようなURLは通常、最終公開前にRFCから削除する必要があります。ドキュメントにURLを含めることが重要である場合、IANAはその包含に同意する必要があります。
As an example, documents could contain: [TO BE REMOVED: This registration should take place at the following location: http://www.iana.org/assignments/foobar-registry]
例として、ドキュメントには次のことが含まれます。
- Each value requested should be given a unique reference. When the value is numeric, use the notation: TBD1, TBD2, etc. Throughout the document where an actual IANA-assigned value should be filled in, use the "TBDx" notation. This helps ensure that the final RFC has the correct assigned values inserted in all of the relevant places where the value is expected to appear in the final document. For values that are text strings, a specific name can be suggested. IANA will normally assign the name, unless it conflicts with a name already in use.
- 要求された各値には、一意の参照を与える必要があります。値が数値の場合は、TBD1、TBD2などを使用します。実際のIANAが割り当てられた値を記入するドキュメント全体で、「TBDX」表記を使用します。これにより、最終RFCに、値が最終文書に表示されると予想されるすべての関連するすべての場所に挿入された正しい割り当て値を確保することができます。テキスト文字列である値については、特定の名前を提案できます。IANAは通常、既に使用されている名前と競合しない限り、名前を割り当てます。
- Normally, the values to be used are chosen by IANA and documents should specify values of "TBD". However, in some cases, a value may have been used for testing or in early implementations. In such cases, it is acceptable to include text suggesting what specific value should be used (together with the reason for the choice). For example, one might include the text "the value XXX is suggested as it is used in implementations". However, it should be noted that suggested values are just that; IANA will attempt to assign them, but may find that impossible, if the proposed number has already been assigned for some other use.
- 通常、使用する値はIANAによって選択され、ドキュメントは「TBD」の値を指定する必要があります。ただし、場合によっては、テストや早期実装に値が使用されている場合があります。そのような場合、どの特定の値を使用すべきかを示唆するテキストを含めることは許容されます（選択の理由と一緒に）。たとえば、「実装で使用されている値xxxが提案されている」というテキストが含まれる場合があります。ただし、提案された値はまさにそれであることに注意する必要があります。IANAはそれらを割り当てようとしますが、提案された番号が他の使用のためにすでに割り当てられている場合、その不可能に感じるかもしれません。
For some registries, IANA has a long-standing policy prohibiting assignment of names or codes on a vanity or organization name basis, e.g., codes are always assigned sequentially unless there is a strong reason for making an exception. Nothing in this document is intended to change those policies or prevent their future application.
一部のレジストリの場合、IANAには、虚栄心や組織名ベースでの名前またはコードの割り当てを禁止する長年のポリシーがあります。たとえば、例外を作成する強い理由がない限り、コードは常に順次割り当てられます。このドキュメントには、これらのポリシーを変更したり、将来のアプリケーションを防ぐことを意図したものはありません。
- The IANA Considerations section should summarize all of the IANA actions, with pointers to the relevant sections elsewhere in the document as appropriate. When multiple values are requested, it is generally helpful to include a summary table. It is also helpful for this table to be in the same format as it should appear on the IANA web site. For example:
- IANAの考慮事項セクションでは、すべてのIANAアクションを要約し、必要に応じてドキュメント内の他の場所に関連するセクションへのポインターを使用します。複数の値が要求される場合、一般的にサマリーテーブルを含めることが役立ちます。また、このテーブルがIANA Webサイトに表示されるのと同じ形式であることも役立ちます。例えば：
Value Description Reference
-------- ------------------- ---------
TBD1 Foobar [RFCXXXX]
Note: In cases where authors feel that including the full table is too verbose or repetitive, authors should still include the table, but may include a note asking that the table be removed prior to publication of the final RFC.
注：著者が、完全なテーブルを含めることが冗長または反復的であると感じている場合、著者は引き続きテーブルを含める必要がありますが、最終RFCの公開前にテーブルを削除することを尋ねるメモを含めることができます。
As an example, the following text could be used to request assignment of a DHCPv6 option number:
IANA has assigned an option code value of TBD1 to the DNS Recursive Name Server option and an option code value of TBD2 to the Domain Search List option from the DHCP option code space defined in Section 24.3 of RFC 3315.
Registrations are a request to assign a new value, including the related information needed to evaluate and document the request. Even after a number has been assigned, some types of registrations contain additional information that may need to be updated over time. For example, MIME media types, character sets, and language tags, etc. typically include more information than just the registered value itself. Example information can include point-of-contact information, security issues, pointers to updates, literature references, etc. In such cases, the document defining the namespace must clearly state who is responsible for maintaining and updating a registration. In different cases, it may be appropriate to specify one or more of the following:
- Let the author update the registration, subject to the same constraints and review as with new registrations.
- 著者に、同じ制約を条件として、登録を更新し、新しい登録と同じレビューを行います。
- Allow some mechanism to attach comments to the registration, for cases where others have significant objections to claims in a registration, but the author does not agree to change the registration.
- 登録にコメントを添付するメカニズムを許可します。他のメカニズムは、登録で請求に対して重大な異議を唱えている場合ですが、著者は登録を変更することに同意しません。
- Designate the IESG, a Designated Expert, or another entity as having the right to change the registrant associated with a registration and any requirements or conditions on doing so. This is mainly to get around the problem when a registrant cannot be reached in order to make necessary updates.
- IESG、指定された専門家、または別のエンティティを指定し、登録に関連する登録者を変更する権利と、要件または条件を条件として指定します。これは主に、必要な更新を行うために登録者に到達できない場合に問題を回避するためです。
Since RFC 2434 was published, experience has shown that the documented IANA considerations for individual protocols do not always adequately cover the reality after the protocol is deployed. For example, many older routing protocols do not have documented, detailed IANA considerations. In addition, documented IANA considerations are sometimes found to be too stringent to allow even working group documents (for which there is strong consensus) to obtain code points from IANA in advance of actual RFC publication. In other cases, the documented procedures are unclear or neglected to cover all the cases. In order to allow assignments in individual cases where there is strong IETF consensus that an allocation should go forward, but the documented procedures do not support such an assignment, the IESG is granted authority to approve assignments in such cases. The intention is not to overrule properly documented procedures, or to obviate the need for protocols to properly document their IANA considerations. Instead, the intention is to permit assignments in individual cases where it is obvious that the assignment should just be made, but updating the IANA process just to assign a particular code point is viewed as too heavy a burden.
RFC 2434が公開されて以来、経験は、個々のプロトコルに関する文書化されたIANAの考慮事項が、プロトコルが展開された後、常に現実を適切にカバーするとは限らないことを示しています。たとえば、多くの古いルーティングプロトコルには、文書化された詳細なIANAの考慮事項がありません。さらに、文書化されたIANAの考慮事項は、実際のRFC出版物の前にIANAからコードポイントを取得するために、ワーキンググループドキュメント（強力なコンセンサスがある）でさえ許可するには厳しすぎることがわかります。それ以外の場合、文書化された手順は、すべてのケースをカバーするために不明確または無視されています。割り当てが進むべきであるが、文書化された手順はそのような割り当てをサポートしていないという強いIETFコンセンサスがある個々のケースでの割り当てを許可するために、IESGはそのような場合に割り当てを承認する権限を与えられます。意図は、適切に文書化された手順を却下したり、プロトコルがIANAの考慮事項を適切に文書化する必要性を取り除くことではありません。代わりに、意図は、割り当てが行われるべきであることが明らかであることが明らかな個々のケースでの割り当てを許可することですが、特定のコードポイントを割り当てるためだけにIANAプロセスを更新することは、重い負担と見なされます。
In general, the IETF would like to see deficient IANA registration procedures for a namespace revised through the IETF standards process, but not at the cost of unreasonable delay for needed assignments. If the IESG has had to take the action in this section, it is a strong indicator that the IANA registration procedures should be updated, possibly in parallel with ongoing protocol work.
一般に、IETFは、IETF標準プロセスを通じて改訂された名前空間のIANA登録手順が不足していることを望んでいますが、必要な割り当てに不当な遅延を犠牲にしません。このセクションでIESGがアクションを実行しなければならなかった場合、IANA登録手順を更新する必要があることを強く指標としています。おそらく進行中のプロトコル作業と並行して。
Before an Internet-Draft can be published as an RFC, IANA needs to know what actions (if any) it needs to perform. Experience has shown that it is not always immediately obvious whether a document has no IANA actions, without reviewing the document in some detail. In order to make it clear to IANA that it has no actions to perform (and that the author has consciously made such a determination), such documents should include an IANA Considerations section that states:
インターネットドラフトをRFCとして公開する前に、IANAは実行する必要があるアクション（もしあれば）を知る必要があります。経験は、ドキュメントを詳細にレビューせずに、ドキュメントにIANAアクションがないかどうかは常にすぐに明らかではないことを示しています。IANAに、実行するアクションがないこと（および著者が意識的にそのような決定を下したことを明確にするために、そのような文書には、次のようなIANAの考慮事項セクションを含める必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
This statement, or an equivalent, must only be inserted after the WG or individual submitter has carefully verified it to be true. Using such wording as a matter of "boilerplate" or without careful consideration can lead to incomplete or incorrect IANA actions being performed.
この声明、または同等の声明は、WGまたは個々の提出者がそれが真実であることを慎重に検証した後にのみ挿入する必要があります。このような言葉遣いを「ボイラープレート」の問題として使用するか、慎重に検討することなく、実行される不完全または誤ったIANAアクションにつながる可能性があります。
If a specification makes use of values from a namespace that is not managed by IANA, it may be useful to note this fact, e.g., with wording such as:
仕様がIANAによって管理されていない名前空間からの値を使用している場合、この事実に注意すると便利かもしれません。
The values of the Foobar parameter are assigned by the Barfoo registry on behalf of the Rabfoo Forum. Therefore, this document has no IANA actions.
In some cases, the absence of IANA-assigned values may be considered valuable information for future readers; in other cases, it may be considered of no value once the document has been approved, and may be removed before archival publication. This choice should be made clear in the draft, for example, by including a sentence such as
[RFC Editor: please remove this section prior to publication.]
[RFCエディター：公開前にこのセクションを削除してください。]
or
また
[RFC Editor: please do not remove this section.]
[RFCエディター：このセクションを削除しないでください。]
For all existing RFCs that either explicitly or implicitly rely on IANA to evaluate assignments without specifying a precise evaluation policy, IANA (in consultation with the IESG) will continue to decide what policy is appropriate. Changes to existing policies can always be initiated through the normal IETF consensus process.
正確な評価ポリシーを指定せずに課題を評価するためにIANAに明示的または暗黙的に依存しているすべての既存のRFCについて、IANA（IESGとの相談）は、どのポリシーが適切かを引き続き決定します。既存のポリシーの変更は、通常のIETFコンセンサスプロセスを通じて常に開始できます。
All future RFCs that either explicitly or implicitly rely on IANA to register or otherwise manage namespace assignments MUST provide guidelines for managing the namespace.
IANAに明示的または暗黙的に依存して名前空間の割り当てを登録または管理するすべての将来のRFCは、名前空間を管理するためのガイドラインを提供する必要があります。
Occasionally, IANA becomes aware that an unassigned value from a managed namespace is in use on the Internet or that an assigned value is being used for a different purpose than originally registered. IANA will not condone such misuse; i.e., procedures of the type described in this document MUST be applied to such cases. In the absence of specifications to the contrary, values may only be reassigned for a different purpose with the consent of the original assignee (when possible) and with due consideration of the impact of such a reassignment. In cases of likely controversy, consultation with the IESG is advised.
時折、IANAは、マネージドネームスペースからの割り当てのない値がインターネットで使用されていること、または割り当てられた値が最初に登録されたものとは異なる目的で使用されていることを認識するようになります。IANAはそのような誤用を容認しません。つまり、このドキュメントに記載されているタイプの手順は、そのような場合に適用する必要があります。反対の仕様がない場合、価値は、元の譲受人の同意（可能な場合）およびそのような再割り当ての影響を十分に考慮して、異なる目的のためにのみ再割り当てされる場合があります。論争の可能性がある場合は、IESGとの協議をお勧めします。
Reclaiming previously assigned values for reuse is tricky, because doing so can lead to interoperability problems with deployed systems still using the assigned values. Moreover, it can be extremely difficult to determine the extent of deployment of systems making use of a particular value. However, in cases where the namespace is running out of unassigned values and additional ones are needed, it may be desirable to attempt to reclaim unused values. When reclaiming unused values, the following (at a minimum) should be considered:
以前に割り当てられた値を再利用するために再生することは難しいです。なぜなら、そうすることで、割り当てられた値を使用して展開されたシステムで相互運用性の問題につながる可能性があるからです。さらに、特定の価値を利用するシステムの展開の範囲を判断することは非常に困難です。ただし、名前空間が未割り当ての値と追加の値が不足している場合、未使用の値を取り戻そうとすることが望ましい場合があります。未使用の値を取り戻す場合、次の（少なくとも）考慮する必要があります。
- Attempts should be made to contact the original party to which a value is assigned, to determine if the value was ever used, and if so, the extent of deployment. (In some cases, products were never shipped or have long ceased being used. In other cases, it may be known that a value was never actually used at all.)
- 値が割り当てられている元の当事者に連絡し、値が使用されたかどうか、もしそうなら展開の範囲を決定する試みを試みる必要があります。（場合によっては、製品が出荷されることはなく、使用されていることを長く停止することはありません。他の場合、値が実際に使用されたことはまったくないことがわかっている場合があります。）
- Reassignments should not normally be made without the concurrence of the original requester. Reclamation under such conditions should only take place where there is strong evidence that a value is not widely used, and the need to reclaim the value outweighs the cost of a hostile reclamation. In any case, IESG Approval is needed in this case.
- 通常、元の要求者の同意なしに再割り当てを行うべきではありません。そのような条件下での再生は、価値が広く使用されていないという強力な証拠があり、価値を取り戻す必要性が敵対的な埋め立てのコストを上回るという強力な証拠がある場合にのみ行われるべきです。いずれにせよ、この場合にはIESGの承認が必要です。
- It may be appropriate to write up the proposed action and solicit comments from relevant user communities. In some cases, it may be appropriate to write an RFC that goes through a formal IETF process (including IETF Last Call) as was done when DHCP reclaimed some of its "Private Use" options [RFC3942].
- 提案されたアクションを作成し、関連するユーザーコミュニティからのコメントを求めることが適切かもしれません。場合によっては、DHCPが「プライベート使用」オプション[RFC3942]の一部を再生したときに行われたように、正式なIETFプロセス（IETF最終呼び出しを含む）を通過するRFCを記述することが適切かもしれません。
Appeals of registration decisions made by IANA can be made using the normal IETF appeals process as described in Section 6.5 of [IETF-PROCESS]. Specifically, appeals should be directed to the IESG, followed (if necessary) by an appeal to the IAB, etc.
IANAによって行われた登録決定の控訴は、[IETFプロセス]のセクション6.5で説明されているように、通常のIETFアピールプロセスを使用して行うことができます。具体的には、控訴はIESGに送られるべきであり、IABへの控訴などが続きます（必要に応じて）。
All IETF mailing lists associated with evaluating or discussing assignment requests as described in this document are subject to whatever rules of conduct and methods of list management are currently defined by Best Current Practices or by IESG decision.
このドキュメントで説明されているように、割り当てリクエストの評価または議論に関連するすべてのIETFメーリングリストは、行動の規則とリスト管理の方法の対象となります。現在、最新の慣行またはIESGの決定によって定義されています。
Information that creates or updates a registration needs to be authenticated and authorized. IANA updates registries according to instructions in published RFCs and from the IESG. It also may accept clarifications from document authors, relevant WG chairs, Designated Experts, and mail list participants, too.
登録を作成または更新する情報は、認証および承認される必要があります。IANAは、公開されたRFCSおよびIESGからの指示に従ってレジストリを更新します。また、ドキュメント著者、関連するWG椅子、指定された専門家、およびメールリストの参加者からの説明を受け入れることもあります。
Information concerning possible security vulnerabilities of a protocol may change over time. Likewise, security vulnerabilities related to how an assigned number is used (e.g., if it identifies a protocol) may change as well. As new vulnerabilities are discovered, information about such vulnerabilities may need to be attached to existing registrations, so that users are not misled as to the true security issues surrounding the use of a registered number.
プロトコルのセキュリティの脆弱性の可能性に関する情報は、時間とともに変化する可能性があります。同様に、割り当てられた番号の使用方法に関連するセキュリティの脆弱性（たとえば、プロトコルを識別する場合）も変更される可能性があります。新しい脆弱性が発見されているため、このような脆弱性に関する情報を既存の登録に添付する必要があるため、登録番号の使用を取り巻く真のセキュリティ問題についてユーザーが誤解されていません。
An analysis of security issues is generally required for all protocols that make use of parameters (data types, operation codes, keywords, etc.) used in IETF protocols or registered by IANA. Such security considerations are usually included in the protocol document [RFC3552]. It is the responsibility of the IANA considerations associated with a particular registry to specify what (if any) security considerations must be provided when assigning new values, and the process for reviewing such claims.
一般に、IETFプロトコルで使用されている、またはIANAが登録したパラメーター（データ型、操作コード、キーワードなど）を使用するすべてのプロトコルには、一般的にセキュリティ問題の分析が必要です。このようなセキュリティ上の考慮事項は、通常、プロトコルドキュメント[RFC3552]に含まれています。特定のレジストリに関連するIANAの考慮事項の責任は、新しい値を割り当てるときにセキュリティ上の考慮事項を提供する必要がある（もしあれば）何が提供される必要があるか、およびそのようなクレームをレビューするプロセスを指定する必要があります。
Changes include:
変更は次のとおりです。
- Major reordering of text to expand descriptions and to better group topics such as "updating registries" vs. "creating new registries", in order to make it easier for authors to find the text most applicable to their needs.
- 説明を拡張し、「レジストリの更新」と「新しいレジストリの作成」などのグループトピックを改善するためのテキストの主要な並べ替え。著者がニーズに最も適用できるテキストを簡単に見つけることができるようにします。
- Numerous editorial changes to improve readability.
- 読みやすさを向上させるための多数の編集上の変更。
- Changed the term "IETF Consensus" to "IETF Review" and added more clarifications. History has shown that people see the words "IETF Consensus" (without consulting the actual definition) and are quick to make incorrect assumptions about what the term means in the context of IANA Considerations.
- 「IETFコンセンサス」という用語を「IETFレビュー」に変更し、さらに明確に追加しました。歴史は、人々が「IETFコンセンサス」という言葉を（実際の定義に相談することなく）見ており、IANAの考慮事項の文脈で用語が何を意味するかについて誤った仮定を迅速に行うことを示しています。
- Added "RFC Required" to list of defined policies.
- 定義されたポリシーのリストに「RFCが必要」を追加しました。
- Much more explicit directions and examples of "what to put in RFCs".
- 「RFCSに入れられるもの」のはるかに明確な方向と例。
- "Specification Required" now implies use of a Designated Expert to evaluate specs for sufficient clarity.
- 「仕様が必要」とは、指定された専門家を使用して、十分な明確さのために仕様を評価することを意味します。
- Significantly changed the wording in Section 3. Main purpose is to make clear that Expert Reviewers are accountable to the community, and to provide some guidance for review criteria in the default case.
- セクション3の文言を大幅に変更しました。主な目的は、専門家のレビュアーがコミュニティに責任を負うことを明確にし、デフォルトのケースでレビュー基準のガイダンスを提供することです。
- Changed wording to remove any special appeals path. The normal RFC 2026 appeals path is used.
- 文言を変更して、特別なアピールパスを削除しました。通常のRFC 2026アピールパスが使用されます。
- Added a section about reclaiming unused value.
- 未使用の価値の回収に関するセクションを追加しました。
- Added a section on after-the-fact registrations.
- 事後登録に関するセクションを追加しました。
- Added a section indicating that mailing lists used to evaluate possible assignments (e.g., by a Designated Expert) are subject to normal IETF rules.
- 可能な割り当てを評価するために使用されるメーリングリスト（例：指定された専門家による）が通常のIETFルールの対象となることを示すセクションを追加しました。
This document has benefited from specific feedback from Jari Arkko, Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus Westerlund, and Bert Wijnen.
この文書は、Jari Arkko、Marcelo Bagnulo Braun、Brian Carpenter、Michelle Cotton、Spencer Dawkins、Barbara Denny、Miguel Garcia、Paul Hoffman、Russ Housley、John Klensin、Allison Mankin、Blake Ramsdell、Margus Westerlundlundleyからの具体的なフィードバックの恩恵を受けています。、そしてバート・ウィジネン。
The original acknowledgments section in RFC 2434 was:
RFC 2434の元の謝辞セクションは、次のとおりです。
Jon Postel and Joyce Reynolds provided a detailed explanation on what IANA needs in order to manage assignments efficiently, and patiently provided comments on multiple versions of this document. Brian Carpenter provided helpful comments on earlier versions of the document. One paragraph in the Security Considerations section was borrowed from [MIME-REG].
Jon PostelとJoyce Reynoldsは、課題を効率的に管理するためにIANAが必要とするものについて詳細な説明を提供し、このドキュメントの複数のバージョンに関するコメントを辛抱強く提供しました。ブライアン・カーペンターは、ドキュメントの以前のバージョンについて有益なコメントを提供しました。セキュリティ上の考慮事項セクションの1つの段落は、[Mime-Reg]から借用されました。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[ASSIGNED] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002.
[割り当て] Reynolds、J.、ed。、「割り当てられた番号：RFC 1700はオンラインデータベースに置き換えられます」、RFC 3232、2002年1月。
[DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[DHCP-Options] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張機能」、RFC 2132、1997年3月。
[DHCP-IANA] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[DHCP-AINA] DROMS、R。、「新しいDHCPオプションとメッセージタイプの定義に関する手順とIANAガイドライン」、BCP 43、RFC 2939、2000年9月。
[EXPERIMENTATION] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[実験] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、2004年1月。
[IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-Consididerations] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IANA-MOU] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, June 2000.
[Iana-Mou] Carpenter、B.、Baker、F。、およびM. Roberts、「インターネットが割り当てられた番号当局の技術作業に関する覚書」、RFC 2860、2000年6月。
[IETF-PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[IETF-Process] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[MIME-REG] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[Mime-Reg] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[PROTOCOL-EXT] Carpenter, B. and B. Aboba, "Design Considerations for Protocol Extensions", Work in Progress, December 2007.
[Protocol-Ext] Carpenter、B。and B. Aboba、「プロトコル拡張の設計上の考慮事項」、2007年12月、進行中の作業。
[RFC2929] Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 2929, September 2000.
[RFC2929] Eastlake 3rd、D.、Brunner-Williams、E.、およびB. Manning、「ドメイン名システム（DNS）IANAの考慮事項」、BCP 42、RFC 2929、2000年9月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171] Albanna、Z.、Almeroth、K.、Meyer、D。、およびM. Schipper、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 3171、2001年8月。
[RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)", BCP 57, RFC 3228, February 2002.
[RFC3228] Fenner、B。、「IPv4 Internet Group Management Protocol（IGMP）に対するIANAの考慮事項」、BCP 57、RFC 3228、2002年2月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、2003年7月。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC3575] Aboba、B。、「RADIUS（ユーザーサービスのリモート認証ダイヤル）のIANAの考慮事項」、RFC 3575、2003年7月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（EAP）」、RFC 3748、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、C。、およびJ. Arkko、「IPv6のモビリティサポート」、RFC 3775、2004年6月。
[RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004.
[RFC3932] Alvestrand、H。、「IESGおよびRFCエディタードキュメント：手順」、BCP 92、RFC 3932、2004年10月。
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC3942] Volz、B。、「動的ホスト構成プロトコルバージョン4（DHCPV4）オプションの再分類」、RFC 3942、2004年11月。
[RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[RFC3968] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）の番号が割り当てられたヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978] Bradner、S.、ed。、「貢献におけるIETFの権利」、BCP 78、RFC 3978、2005年3月。
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.
[RFC4005] Calhoun、P.、Zorn、G.、Spence、D。、およびD. Mitton、「Diameter Network Access Server Application」、RFC 4005、2005年8月。
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]リチャードソン、M。、「DNSにIPSECキーイング材料を保存する方法」、RFC 4025、2005年3月。
[RFC4044] McCloghrie, K., "Fibre Channel Management MIB", RFC 4044, May 2005.
[RFC4044] McCloghrie、K。、「ファイバーチャネル管理MIB」、RFC 4044、2005年5月。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering", RFC 4124, June 2005.
[RFC4124] Le Faucheur、F.、ed。、「Diffserv-Aware MPLSトラフィックエンジニアリングのサポートのためのプロトコル拡張」、RFC 4124、2005年6月。
[RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", RFC 4169, November 2005.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[RFC4283] Patel、A.、Leung、K.、Khalil、M.、Akhtar、H。、およびK. Chowdhury、「モバイルIPv6（MIPV6）のモバイルノード識別子オプション」、RFC 4283、2005年11月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagramうっ血制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 4366、2006年4月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 115, RFC 4395, February 2006.
[RFC4395] Hansen、T.、Hardie、T.、およびL. Masinter、「新しいURIスキームのガイドラインと登録手順」、BCP 115、RFC 4395、2006年2月。
[RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A.、ed。、およびK. Zeilenga、ed。、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）へのIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520] Zeilenga、K。、「Internet Assigned Numbers Authority（IANA）Lightwight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 4520、2006年6月。
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", RFC 4589, July 2006.
[RFC4589] Schulzrinne、H。およびH. Tschofenig、「Location Types Registry」、RFC 4589、2006年7月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727] Fenner、B。、「IPv4、IPv6、ICMPV4、ICMPV6、UDP、およびTCPヘッダーの実験値」、RFC 4727、2006年11月。
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995] Jonsson、L-E。、Pelletier、G。、およびK. Sandlund、「The Robust Header Compression（ROHC）フレームワーク」、RFC 4995、2007年7月。
Authors' Addresses
著者のアドレス
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 -BRQA/502 Research Triangle Park、NC 27709-2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
電話：919-254-7798メール：narten@us.ibm.com
Harald Tveit Alvestrand Google Beddingen 10 Trondheim, 7014 Norway
EMail: Harald@Alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、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への情報をお問い合わせください。