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.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
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プロトコルでは、その役割は、Internet Assigned Numbers Authority（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 [IPSEC]のための変換）。このようなフィールドが異なる実装で一貫した値との解釈を持っていることを確認するには、その割り当ては中央の権威によって投与しなければなりません。 IETFプロトコルについて、その役割は、Internet Assigned Numbers Authority（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）は、委任[ASSIGNED]れます。 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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。この文書では、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:
名前空間を管理する際に考慮すべき問題の一つは、そのサイズです。スペースのサイズが小さく、限られている場合は、割り当てが空間の枯渇を防ぐために慎重になされなければなりません。スペースは基本的に無制限である場合は、他の一方で、潜在的な枯渇は、おそらくすべての実用的な関心事ではありません。スペースは基本的に無制限である場合でも、しかし、ために割り当てに先立って、少なくとも最低限のレビューを持っていることが通常望ましいです。
- 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.
第二の考慮事項は、それが何らかの方法で名前空間を委任することは理にかなっているかどうかです。それは割り当てに対処するための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].
第三に、そしておそらく最も重要な、考慮事項は、未審査の拡張機能の相互運用性への潜在的な影響を懸念します。提案されたプロトコルの拡張機能は、一般的にコミュニティレビューの恩恵を受ける。確かに、レビューは、将来の相互運用性の問題[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が割り当てポリシー自体を作成したり、定義していないことに留意すべきです。むしろ、それは他の人によって定義され、RFCで公開されている政策を実行します。 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）が相談されるべきであると思うかもしれません。しかし実際には、各WGは結局解散ので、彼らは永久的な評価者とみなすことはできません。名前空間が何のWGがこれまでに形成されていないため、個々の提出書類、を介して作成することも可能です。
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.
将来の割り当てのコミュニティレビューを確保するための一つの方法は、要求者が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への単一の明確な勧告を行うために、これらの専門家の責任です。 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.
専門家のプールが要求を評価ところレジストリでは、プールはリクエストがに割り当てられ、専門家によって審査される方法を定義する責任単一の椅子を持っている必要があります。いくつかのケースでは、専門家のプールは、プライマリの専門家が利用できないときにのみ関与バックアップで、プライマリおよびバックアップから構成されてもよいです。他の例では、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.
- 指定された専門家は、より複雑なもののために数週間に、単純な要求のために、通常は一週間以内に、タイムリーに応答しなければなりません。不合理な遅延はこのような製品を出荷するコードポイントを必要とする場合など、これらの必要の割り当てのための重大な問題を引き起こす可能性があります。これはすべての口コミをしっかり締め切りの下で完了することができますが、それらが開始されなければならない、と答えはすぐに与えることができない場合は、リクエスタと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定期的なイベントである場合（例えば、いくつかの要求が特に複雑でもよい）、および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].
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].
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は、他の政策の一つに記載のネームスペースのより高いレベルを制御します。
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].
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].
エキスパートレビュー（または指定エキスパート） - 指定専門家の承認が必要です。レジストリを定義するときに指定エキスパートで使用するための必要書類と審査基準が提供されるべきです。例えば、[RFC3748]のセクション6及び7.2を参照。
Examples: EAP Method Types [RFC3748], HTTP Digest AKA
algorithm versions [RFC4169], URI schemes [RFC4395], GEOPRIV
Location Types [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.
仕様が必要 - 独立した実装の間の相互運用が可能になるような値とその意味は十分に詳細に、恒久的かつ容易に利用可能な公開された仕様に文書化されなければなりません。使用する場合、仕様が必要でも公開された仕様を検討し、相互運用可能な実装を可能にするために十分に明確であるかどうかを評価する指定エキスパートの使用を意味します。 「恒久的かつ容易に利用可能な」背後にある意図は、文書が合理的に長い要求された値のIANAの割り当ての後に発見できると検索可能であることを期待することができるということです。 RFCの出版物は、この要件を達成するための理想的な手段であるが、仕様が必要でも、RFC路の外側に公開された文書の場合をカバーすることを意図しています。 RFCの公表については、通常のRFCレビュープロセスは、指定専門家は、このような審査を行うために特によく資格者かもしれないが、相互運用性のために必要な見直しを提供することが期待されます。
Examples: Diffserv-aware TE Bandwidth Constraints Model
Identifiers [RFC4124], TLS ClientCertificateType Identifiers
[RFC4346], ROHC Profile Identifiers [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-考察]に「IETFコンセンサス」と呼ばれる）新しい値のみAD-スポンサーやIETF WGドキュメント[RFC3932] [RFC3978]としてIESGによって牧されているのRFCによって割り当てられます。意図は、提案された割り当てが負の相互運用性に影響を与えるか、さもなければ不適切にIETFプロトコルを拡張しないことを保証するために（適切なワーキンググループがもはや存在している場合、または専門家）文書及び提案割当がIESG、適切なIETFのWGによって見直されないことですまたは有害な方法。
To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.
Examples: IPSECKEY Algorithm Types [RFC4025], Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS Handshake Hello Extensions [RFC4366].
例：IPSECKEYのアルゴリズムタイプ[RFC4025]、DIAMETER会計-auth-methodのAVP値[RFC4005]、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].
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).
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]、エッジエミュレーションに疑似エッジ（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:
新しい名前空間を作成（または既存のスペースの定義を変更）し、それはIANAがそのスペースを維持する役割を果たしていることを期待する（例えば、登録された値のリポジトリとして機能する）名前空間の詳細に明確な指示を提供しなければならない書類。具体的には、命令が含まれている必要があります
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から削除されます。例えば、文書が含まれている可能性があり：[除去することが：この登録は、次の場所で行わなければならない：http://www.iana.org/assignments/foobar-registry]
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.
将来の割り当てを行うためのプロセスを指定する場合、セクション4.1に記載されている例の方針の1つ（またはそれ以上）を選択し、名前で参照することは非常に許容可能です。実際、これは、サンプルポリシーはレビューの所望のレベルを提供するような場合に好適な機構です。上記のいずれかのポリシーを引用し、レビュープロセスで考慮されるべき注意事項の種類のための追加のガイドラインを含めることも可能です。たとえば、RADIUS [RFC3575]は指定エキスパートの使用を指定しますが、指定の専門家が従うべき具体的な追加の基準を含んでいます。
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-IANA]：
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のオプションは、IANAがFooBarのオプションの下に新しいサブレジストリ名称「FooType値」を作成し、維持することであるため、8ビットのFooTypeフィールドを定義します。 DHCP FooBarのFooTypeレジストリの初期値は以下の通りです。将来の割り当ては、専門家レビュー[IANA-検討事項]を介して行われるべきです。割り当ては、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に詳細なガイダンスを提供する文書の例については、[RFC3968]、[RFC3575]、[RFC2929]に相談し、[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].
（明示的または暗黙的に作成されたかどうか）既存の（すなわち、以前に作成された）名前空間の登録プロセスを更新する新しい名前空間を作成する際に使用されるものと同様のプロセスをたどります。つまり、文書は、既存の名前空間への参照を行い、その後、個々の名前空間に割り当てを処理するための詳細なガイドラインを提供しますが生成されます。このような文書は、通常、ベストプラクティス現在（のBCP）[IETF-PROCESS]として処理されます。
Example documents that updated the guidelines for managing (then) pre-existing registries include: [RFC2929], [RFC3228], and [RFC3575].
（当時）既存のレジストリを管理するためのガイドラインを更新例ドキュメントが含まれます：[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によって作成された1）。そのような場合：
- 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]
一例として、文書が含まれている可能性があり：[除去することが：この登録は、次の場所で行わなければならない：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.
- 要求された各値は一意の参照を与えられるべきです。 「TBDx」表記を使用し、実際のIANAによって割り当てられた値が充填されるべき文書を通してTBD1、TBD2、等：値が数値である場合、表記法を使用します。これは、最終的な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のウェブサイト上で表示される、このテーブルが同じ形式であることがさらに便利です。例えば：
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:
一例として、以下のテキストは、DHCPv6のオプション番号の割り当てを要求するために使用することができます。
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.
IANAは、RFC 3315のセクション24.3で定義されたDHCPオプションコード空間からのドメイン検索リストオプションにDNS再帰ネームサーバオプションとTBD2のオプションコード値にTBD1のオプションコード値が割り当てられています。
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:
登録は要求を評価し、文書化するために必要な関連情報を含む新しい値を割り当てるための要求です。番号が割り当てられた後でも、登録のいくつかの種類が時間をかけて更新する必要があり、追加の情報が含まれています。たとえば、MIMEメディアタイプ、文字セット、および言語タグなどが一般的にだけで登録された値そのものよりも多くの情報が含まれています。例の情報は、ポイント・オブ・連絡先情報を含めることができ、セキュリティ上の問題は、などの更新、参考文献へのポインタこのような場合には、名前空間を定義する文書が明確に登録を維持し、更新するための責任者を述べなければなりません。異なる場合には、以下の一つ以上を指定することが適切であり得ます。
- 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.
foobarのパラメータの値は、Rabfooフォーラムに代わってBarfooレジストリによって割り当てられます。したがって、このドキュメントには、IANAのアクションを持っていません。
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
いくつかのケースでは、IANAによって割り当てられた値が存在しないことは、将来の読者のための貴重な情報とみなすことができます。他の例においては、文書が承認されており、およびアーカイブ出版する前に除去することができる一度無価値と見なすことができます。この選択は、例えば、のような文を含めることによって、草案で明らかにされるべきです
[RFC Editor: please remove this section prior to publication.]
[RFC Editorは：出版する前に、このセクションを削除してください。]
or
または
[RFC Editor: please do not remove this section.]
[RFC Editorは：このセクションを削除しないでください。]
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.
明示的または暗黙的に（IESGと協議の）正確な評価の方針、IANAを指定せずに割り当てを評価するために、IANAに依存するすべての既存のRFCのポリシーが適切であるかを決定していきます。既存のポリシーの変更は、常に通常の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.
[IETF-PROCESS]のセクション6.5に記載されるようにIANAによって作ら登録決定の控訴は、通常IETF控訴プロセスを用いて製造することができます。具体的には、控訴は、IABにアピールすることによって（必要な場合）等に従った、IESGに向けられるべきです
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は、公表されたRFCでと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
セキュリティ問題の分析は、一般パラメータ（データ・タイプ、操作コード、キーワード、等）IETFプロトコルで使用またはIANAによって登録を利用するすべてのプロトコルのために必要とされます。このようなセキュリティ上の考慮事項は、通常、プロトコルドキュメント[RFC3552]に含まれています。これは、IANAの考慮の責任であります
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.
セキュリティの考慮事項は、新しい値を割り当てるときに提供され、そのような特許請求の範囲を検討するための処理されなければならないもの（もしあれば）を指定する特定のレジストリに関連付けられています。
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".
- 多くのより明確な方向性と「RFCで何を入れてする」の例。
- "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.
この文書では、ヤリArkko、マルセロBagnuloブラウン、ブライアン・カーペンター、ミシェルコットン、スペンサードーキンス、バーバラ・デニー、ミゲル・ガルシア、ポール・ホフマン、ラスHousley、ジョン・クレンシン、アリソンマンキン、ブレイクRamsdell、マークTownsley、マグヌスウェスターからの具体的なフィードバックの恩恵を受けています、およびバートWijnen。
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].
ジョン・ポステルとジョイスレイノルズは、IANAが効率的に割り当てを管理するために必要なものについて詳細な説明を提供し、辛抱強くこのドキュメントの複数のバージョンのコメントを提供しました。ブライアン・カーペンターは、ドキュメントの以前のバージョンで役に立つコメントを提供しました。 Security Considerations部で一つの段落は、[MIME-REG]から借りました。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
[ASSIGNED]レイノルズ、J.、エド、。：、RFC 3232、2002年1月 "割り当て番号RFC 1700は、オンラインデータベースで置き換えられます"。
[DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[DHCP-OPTIONS]アレクサンダー、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-IANA] Droms、R.、BCP 43、RFC 2939、2000年9月 "新しいDHCPオプションとメッセージタイプの定義のための手順とIANAガイドライン"。
[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-考察] 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]大工、B.、ベイカー、F.、およびM.ロバーツ、RFC 2860、2000年6月 "インターネット割り当て番号機関の技術的な仕事に関する覚書"。
[IETF-PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[IETF-PROCESS]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IP]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPSEC]ケント、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]フリード、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]大工、B.および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]イーストレーク3、D.、ブルンナー - ウィリアムズ、E.、およびB.マニング、 "ドメインネームシステム（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.、マイヤー、D.、およびM.シッパー、 "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]フェナー、B.、BCP 57、RFC 3228、2002年2月 "IPv4インターネットグループ管理プロトコル（IGMP）のためのIANAの考慮事項"。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.コーバー、BCP 72、RFC 3552、2003年7月、 "セキュリティ上の考慮事項の書き方RFCテキストのためのガイドライン"。
[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.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、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 Editorのドキュメント：プロシージャ"、BCP 92、RFC 3932、2004年10月。
[RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options", RFC 3942, November 2004.
[RFC3942]フォルツ、B.、RFC 3942 "動的ホスト構成プロトコルバージョン4（DHCPv4の）オプションを再分類"、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]キャマリロ、G.、BCP 98、RFC 3968、2004年12月 "インターネットは、セッション開始プロトコル（SIP）のための番号機関（IANA）ヘッダーフィールドパラメータレジストリを割り当てられました"。
[RFC3978] Bradner, S., Ed., "IETF Rights in Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978]ブラドナーの、S.、エド。、 "質問の投稿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]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、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]ルFaucheur、F.、エド。、 "Diffservの認識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.
[RFC4169] Torvinen、V.、Arkko、J.、およびM. Naslund、RFC 4169、2005年11月 "認証および鍵合意（AKA）バージョン2を使用したハイパーテキスト転送プロトコル（HTTP）ダイジェスト認証"。
[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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6（MIPv6の）のためのモバイルノード識別子オプション"、RFC 4283、2005年11月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.1"、RFC 4346、2006年4月。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[RFC4366]ブレイク・ウィルソン、S.、Nystrom、M.、ホップウッド、D.、ミケルセン、J.、およびT.ライト、 "トランスポート層セキュリティ（TLS）拡張機能"、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]ハンセン、T.、ハーディ、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]メルニコフ、A.編、およびK. Zeilenga、エド。、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[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.、 "IANA（Internet Assigned Numbers Authority）のライトウェイトディレクトリアクセスプロトコル（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、 "場所の種類レジストリ"、RFC 4589、2006年7月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]フェナー、B.、RFC 4727、2006年11月 "のIPv4、IPv6の、ICMPv4の、ICMPv6の、UDP、およびTCPヘッダには実験値"。
[RFC4995] Jonsson, L-E., Pelletier, G., and K. Sandlund, "The RObust Header Compression (ROHC) Framework", RFC 4995, July 2007.
[RFC4995]ジョンソン、L-E。、ペルティエ、G.、及びK. Sandlund、 "ロバストヘッダ圧縮（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
トーマスNarten氏IBMコーポレーション3039コーンウォリスアベニュー。私書箱12195 - BRQA / 502リサーチトライアングルパーク、ノースカロライナ州27709から2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
電話：919-254-7798 Eメール：narten@us.ibm.com
Harald Tveit Alvestrand Google Beddingen 10 Trondheim, 7014 Norway
ハラルド・トバイット・アルベストランドグーグルBeddingen 10トロンハイムノルウェー7014
EMail: Harald@Alvestrand.no
メールアドレス：Harald@Alvestrand.no
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。