[要約] RFC 2434は、RFCにおけるIANAの考慮事項セクションの書き方に関するガイドラインです。その目的は、IANAに関連する情報を明確かつ一貫した方法で提供し、プロトコルの運用と管理を支援することです。
Network Working Group T. Narten
Request for Comments: 2434 IBM
BCP: 26 H. Alvestrand
Category: Best Current Practice Maxware
October 1998
Guidelines for Writing an IANA Considerations Section in RFCs
RFCのIANA考慮事項セクションを作成するためのガイドライン
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティのためのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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 algorithm for IPSec). To insure that such quantities 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).
多くのプロトコルは、定数やその他の既知の値で構成される識別子を利用しています。プロトコルが定義され、展開が開始された後でも、新しい値を割り当てる必要がある場合があります（DHCPの新しいオプションタイプ、またはIPSecの新しい暗号化または認証アルゴリズムなど）。そのような量が異なる実装で一貫した値と解釈を持っていることを保証するために、それらの割り当ては中央当局によって管理されなければなりません。 IETFプロトコルの場合、その役割はInternet Assigned Numbers Authority（IANA）によって提供されます。
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the 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 name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.
IANAが所定の名前空間を慎重に管理するためには、新しい値を割り当てることができる条件を説明するガイドラインが必要です。 IANAが名前空間の管理に役割を果たすことが予想される場合、IANAはその役割を説明する明確で簡潔な指示を与えられる必要があります。このドキュメントでは、名前空間に値を割り当てるためのポリシーを策定する際に考慮すべき問題について説明し、IANAを要求するドキュメントに含める必要がある特定のテキストについてドキュメント作成者にガイドラインを提供します。
Table of Contents
目次
Status of this Memo.......................................... 1
1. Introduction............................................. 2
2. Issues To Consider....................................... 3
3. Registration maintenance................................. 6
4. What To Put In Documents................................. 7
5. Applicability to Past and Future RFCs.................... 8
6. Security Considerations.................................. 8
7. Acknowledgments.......................................... 9
8. References............................................... 9
9. Authors' Addresses....................................... 10
10. Full Copyright Statement................................. 11
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 types in mail messages [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] or a new encryption or authentication algorithm for IPSec [IPSEC]). To insure 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).
多くのプロトコルは、定数やその他の既知の値を含むフィールドを使用します（たとえば、IPヘッダーのプロトコルフィールド[IP]またはメールメッセージのMIMEタイプ[MIME-REG]）。プロトコルが定義され、展開が開始された後でも、新しい値を割り当てる必要がある場合があります（たとえば、DHCPの新しいオプションタイプ[DHCP]またはIPSecの新しい暗号化または認証アルゴリズム[IPSEC]）。そのようなフィールドが異なる実装で一貫した値と解釈を持つことを保証するために、それらの割り当ては中央当局によって管理されなければなりません。 IETFプロトコルの場合、その役割はInternet Assigned Numbers Authority（IANA）によって提供されます。
In this document, we call the set of possible values for such a field a "name space"; its actual content may be a name, a number or another kind of value. The assignment of a specific value to a name space is called an assigned number (or assigned value). Each assignment of a number in a name space is called a registration.
このドキュメントでは、そのようなフィールドの可能な値のセットを「名前空間」と呼びます。実際のコンテンツは、名前、番号、または別の種類の値です。名前空間への特定の値の割り当ては、割り当て番号（または割り当て値）と呼ばれます。名前空間での番号の各割り当ては、登録と呼ばれます。
In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values should be assigned. This document provides guidelines to authors on what sort of text should be added to their documents, and reviews issues that should be considered in formulating an appropriate policy for assigning numbers to name spaces.
IANAが所定の名前空間を慎重に管理するためには、新しい値が割り当てられる条件を説明するガイドラインが必要です。このドキュメントは、どのような種類のテキストをドキュメントに追加するかについて作成者にガイドラインを提供し、名前空間に番号を割り当てるための適切なポリシーを策定する際に考慮すべき問題をレビューします。
Not all name spaces require centralized administration. In some cases, it is possible to delegate a name space in such a way that further assignments can be made independently and with no further (central) coordination. In the Domain Name System, for example, the 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]. When a name space
すべての名前空間に集中管理が必要なわけではありません。場合によっては、追加の割り当てを独立して、さらに（中央の）調整なしで行うことができるように、名前空間を委任することができます。たとえば、ドメインネームシステムでは、IANAは上位レベルの割り当てのみを処理しますが、サブドメインはスペースが委任された組織によって管理されます。別の例として、ITUによって定義されたオブジェクト識別子（OID）も[ASSIGNED]に委任されます。名前空間
can be delegated, the IANA only deals with assignments at the top level.
委任することができ、IANAは最上位の割り当てのみを扱います。
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [KEYWORDS]. In this case, "the specification" as used by RFC 2119 refers to the processing of protocols being submitted to the IETF standards process.
このドキュメントでは、RFC 2119 [KEYWORDS]で説明されている方法で、「必須」、「SHOULD」、「MAY」、およびそれらの否定語を使用しています。この場合、RFC 2119で使用される「仕様」は、IETF標準プロセスに提出されるプロトコルの処理を指します。
The primary issue to consider in managing a name space is its size. If the space is small and limited in size, assignments must be made carefully to insure that the space doesn't become exhausted. If the space is essentially unlimited, on the other hand, it may be perfectly reasonable to hand out new values to anyone that wants one. Even when the space is essentially unlimited, however, it is usually desirable to have a minimal review to prevent the hoarding of or unnecessary wasting of a space. For example, if the space consists of text strings, it may be desirable to prevent organizations from obtaining large sets of strings that correspond to the "best" names (e.g., existing company names).
名前空間の管理で考慮すべき主な問題は、そのサイズです。スペースが小さく、サイズに制限がある場合は、スペースが使い果たされないように、割り当てを慎重に行う必要があります。一方、スペースが本質的に無制限である場合、新しい値を必要とする人に新しい値を渡すことは完全に合理的かもしれません。ただし、スペースが本質的に無制限である場合でも、スペースの買いだめや不要な無駄を防ぐために、最小限のレビューを行うことが通常望ましいです。たとえば、スペースがテキスト文字列で構成されている場合、組織が「最適な」名前（既存の会社名など）に対応する文字列の大きなセットを取得しないようにすることが望ましい場合があります。
A second consideration is whether it makes sense to delegate the name space in some manner. This route should be pursued when appropriate, as it lessens the burden on the IANA for dealing with assignments.
2番目の考慮事項は、名前空間を何らかの方法で委任することが理にかなっているかどうかです。このルートは、割り当てを処理するためのIANAの負担を軽減するため、必要に応じて追跡する必要があります。
In some cases, the name space is essentially unlimited, and assigned numbers can safely be given out to anyone. When no subjective review is needed, the IANA can make assignments directly, provided that the IANA is given specific instructions on what types of requests it should grant, and what information must be provided before a request for an assigned number will be considered. Note that the IANA will not define an assignment policy; it should be given a set of guidelines that allow it to make allocation decisions with little subjectivity.
場合によっては、名前空間は基本的に無制限であり、割り当てられた番号は誰にでも安全に配布できます。主観的なレビューが必要ない場合、IANAは割り当てを直接行うことができます。ただし、IANAが付与する必要のある要求のタイプ、および割り当てられた番号の要求を検討する前に提供する必要がある情報についての具体的な指示が与えられます。 IANAは割り当てポリシーを定義しないことに注意してください。主観性をほとんど持たない割り当ての決定を可能にする一連のガイドラインを与える必要があります。
In most cases, some review of prospective allocations is appropriate, and the question becomes who should perform the review and how rigorous the review needs to be. In many cases, one might think that an IETF Working Group (WG) familiar with the name space at hand should be consulted. In practice, however, WGs eventually disband, so they cannot be considered a permanent evaluator. It is also possible for name spaces to be created through individual submission documents, for which no WG is ever formed.
ほとんどの場合、予想される割り当てのレビューが適切であり、問題は、誰がレビューを実行する必要があるか、そしてレビューがどれほど厳密である必要があるかということになります。多くの場合、当面の名前空間に精通しているIETFワーキンググループ（WG）に相談する必要があると考えるかもしれません。ただし、実際にはWGは最終的に解散するため、恒久的な評価者とは見なされません。名前空間は、WGがこれまでに形成されていない個別の提出ドキュメントを通じて作成することも可能です。
One way to insure community review of prospective assignments is to have the requester submit a document for publication as an RFC. Such an action insures that the IESG and relevant WGs review the assignment. This is the preferred way of insuring review, and is particularly important if any potential interoperability issues can arise. For example, many 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つの方法は、RFCとして公開するドキュメントを要求者に提出させることです。そのような行動は、IESGおよび関連するWGが割り当てをレビューすることを保証します。これは、レビューを保証するための推奨される方法であり、潜在的な相互運用性の問題が発生する可能性がある場合は特に重要です。たとえば、多くの割り当ては単なる割り当てではなく、プロトコル仕様の要素も含みます。新しいオプションは、解析および処理が必要なフィールドを定義する可能性があります。（不十分に指定されている場合）他のオプションのアーキテクチャまたはそれらが構築されている基本プロトコルに完全に適合しない場合があります。
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 to give advice for persons who want 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 expertise, opinions may vary and discussions may continue for some time without resolution. In addition, the IANA cannot participate in all of these mailing lists and cannot determine if or when such discussions reach consensus. Therefore, the IANA cannot allow general mailing lists to fill the role of providing definitive recommendations regarding a registration question. Instead, the IANA will use a designated subject matter expert. The IANA will rely on a "designated expert" to advise it in assignment matters. That is, the IANA forwards the requests it receives to a specific point-of-contact (one or a small number of individuals) and acts upon the returned recommendation from the designated expert. The designated expert can initiate and coordinate as wide a review of an assignment request as may be necessary to evaluate it properly.
メーリングリストでの議論は貴重な技術的専門知識を提供することができますが、意見はさまざまで、議論は解決せずにしばらく続く場合があります。さらに、IANAはこれらのメーリングリストのすべてに参加することはできず、そのような議論が合意に達したかどうか、またはいつ合意に達したかを判断できません。したがって、IANAは、一般的なメーリングリストが登録の質問に関する決定的な推奨事項を提供する役割を果たすことを許可できません。代わりに、IANAは指定された主題の専門家を使用します。 IANAは、「指定された専門家」に依頼して、課題についてアドバイスします。つまり、IANAは受け取った要求を特定の連絡先（1人または少数の個人）に転送し、指定された専門家から返された推奨事項に基づいて行動します。指定された専門家は、適切に評価するために必要となる可能性がある限り、割り当て要求のレビューを開始して調整することができます。
Designated experts are appointed by the relevant Area Director of the IESG. They are typically named at the time a document that creates a new numbering space is published as an RFC, but as experts originally appointed may later become unavailable, the relevant Area Director will appoint replacements if necessary.
指定された専門家は、IESGの関連するエリアディレクターによって任命されます。これらは通常、新しい番号付けスペースを作成するドキュメントがRFCとして公開されるときに名前が付けられますが、当初任命された専門家が後で利用できなくなる可能性があるため、関連するエリアディレクターが必要に応じて代わりを任命します。
Any decisions made by the designated expert can be appealed using the normal IETF appeals process as outlined in Section 6.5 of [IETF-PROCESS]. Since the designated experts are appointed by the IESG, they may be removed by the IESG.
指定された専門家による決定は、[IETF-PROCESS]のセクション6.5で概説されている通常のIETF上訴プロセスを使用して上訴することができます。指定された専門家はIESGによって任命されるため、それらはIESGによって削除される場合があります。
The following are example policies, some of which are in use today:
以下はポリシーの例であり、その一部は現在使用されています。
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 and assignments are not generally useful for interoperability.
私的使用-ローカルサイトで定義されたタイプと目的で、私的またはローカルでのみ使用します。複数のサイトが同じ値を異なる（互換性のない）方法で使用することを防ぐ試みは行われません。 IANAがそのような割り当てを確認する必要はなく、割り当ては一般に相互運用性に役立ちません。
Examples: Site-specific options in DHCP [DHCP] have significance only within a single site. "X-foo:" header lines in email messages.
例：DHCPのサイト固有のオプション[DHCP]は、単一のサイト内でのみ意味があります。電子メールメッセージの「X-foo：」ヘッダー行。
Hierarchical allocation - Delegated managers can assign values provided they have been given control over that part of the name space. IANA controls the higher levels of the namespace according to one of the other policies.
階層的な割り当て-委任されたマネージャーは、名前空間のその部分に対する制御が与えられていれば、値を割り当てることができます。 IANAは、他のポリシーの1つに従って名前空間の上位レベルを制御します。
Examples: DNS names, Object Identifiers
例：DNS名、オブジェクト識別子
First Come First Served - Anyone can obtain an assigned number, so long as they provide a point of contact and a brief description of what the value would be used for. For numbers, the exact value is generally assigned by the IANA; with names, specific names are usually requested.
先着順-連絡先と値の使用目的の簡単な説明を提供する限り、誰でも割り当てられた番号を取得できます。数値の場合、正確な値は通常IANAによって割り当てられます。名前では、通常、特定の名前が要求されます。
Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP and UDP port numbers.
例：vnd。 （ベンダー割り当て）MIMEタイプ[MIME-REG]、TCPおよびUDPポート番号。
Expert Review - approval by a Designated Expert is required.
専門家によるレビュー-指定専門家による承認が必要です。
Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible.
必要な仕様-値とその意味は、独立した実装間の相互運用性が可能になるように、RFCまたは他の永続的ですぐに利用できるリファレンスに十分詳細に文書化する必要があります。
Examples: SCSP [SCSP]
例：SCSP [SCSP]
IESG Approval - New assignments must be approved by the IESG, but there is no requirement that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis).
IESG承認-新しい割り当てはIESGによって承認される必要がありますが、要求をRFCに文書化する必要はありません（ただし、IESGはケースバイケースで文書またはその他のサポート資料を要求する裁量を持っています）。
IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists).
IETFコンセンサス-新しい値は、IETFコンセンサスプロセスを通じて割り当てられます。具体的には、新しい割り当てはIESGによって承認されたRFCを介して行われます。通常、IESGは、適切な人物（たとえば、関連するワーキンググループが存在する場合）から、将来の割り当てに関する情報を求めます。
Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address Family Identifiers [BGP4-EXT].
例：SMTP拡張[SMTP-EXT]、BGP後続アドレスファミリ識別子[BGP4-EXT]。
Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG.
標準アクション-値は、IESGによって承認された標準トラックRFCにのみ割り当てられます。
Examples: MIME top level types [MIME-REG]
例：MIMEトップレベルタイプ[MIME-REG]
It should be noted that it often makes sense to partition a name space into several categories, with assignments out of each category handled differently. For example, the DHCP option space [DHCP] is split into two parts. Option numbers in the range of 1-127 are globally unique and assigned according to the Specification Required policy described above, while options number 128-254 are "site specific", i.e., Local Use. Dividing the name space up makes it possible to allow some assignments to be made with minimal review, while simultaneously reserving some part of the space for future use.
名前空間をいくつかのカテゴリに分割し、各カテゴリからの割り当てを異なる方法で処理することはしばしば意味があることに注意してください。たとえば、DHCPオプションスペース[DHCP]は2つの部分に分かれています。 1から127の範囲のオプション番号はグローバルに一意であり、上記の仕様必須ポリシーに従って割り当てられますが、オプション番号128から254は「サイト固有」、つまりローカル使用です。名前空間を分割すると、最小限のレビューでいくつかの割り当てを行うことができると同時に、将来の使用のために空間の一部が予約されます。
Registrations are a request for an assigned number, 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 types, character sets, 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 must clearly state who is responsible for maintaining and updating a registration. It is appropriate to:
登録は、割り当てを要求するものであり、要求の評価と文書化に必要な関連情報が含まれます。番号が割り当てられた後でも、一部のタイプの登録には、時間の経過とともに更新する必要がある追加情報が含まれています。たとえば、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 or another authority as having the right to reassign ownership of a registration. This is mainly to get around the problem when some registration owner cannot be reached in order to make necessary updates.
- IESGまたは別の機関を、登録の所有権を再割り当てする権利を持つものとして指定します。これは主に、必要な更新を行うために一部の登録所有者に連絡できないときに問題を回避するためです。
The previous sections presented some issues that should be considered in formulating a policy for assigning well-known numbers and other protocol constants. It is the Working Group and/or document author's job to formulate an appropriate policy and specify it in the appropriate document. In some cases, having an "IANA Considerations" section may be appropriate. Specifically, documents that create an name space (or modify the definition of an existing space) and that expect the IANA to play a role in maintaining that space (e.g., serving as a repository for registered values) MUST document the process through which future assignments are made. Such a section MUST state clearly:
前のセクションでは、既知の番号やその他のプロトコル定数を割り当てるためのポリシーを策定する際に考慮すべきいくつかの問題を示しました。適切なポリシーを策定し、適切なドキュメントで指定するのは、ワーキンググループまたはドキュメントの作成者の仕事です。場合によっては、「IANAに関する考慮事項」セクションを設けることが適切な場合があります。特に、名前空間を作成する（または既存の空間の定義を変更する）文書、およびIANAがその空間を維持する役割を果たす（たとえば、登録された値のリポジトリとして機能する）ことを期待する文書は、今後の割り当てのプロセスを文書化する必要があります。作られています。そのようなセクションは明確に述べなければなりません：
- whether or not an application for an assigned number needs to be reviewed. If review is necessary, the review mechanism MUST be specified. 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 IESG Area Director at the time the document is sent to the IESG for approval.
- 割り当てられた番号の申請をレビューする必要があるかどうか。レビューが必要な場合は、レビューメカニズムを指定する必要があります。指定専門家が使用される場合、文書は文書自体の中で指定専門家を指名してはなりません。代わりに、承認のためにドキュメントがIESGに送信されるときに、適切な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 use of a Designated Expert MUST also be specified.
- リクエストを特定の公開メーリングリスト（メディアタイプの場合はietf-types@iana.orgなど）でもレビューする必要がある場合は、そのメーリングアドレスを指定する必要があります。ただし、Designated Expertの使用も指定する必要があることに注意してください。
- if the 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が外部のレビューを必要とせずに割り当てを行うことが期待される場合は、要求を最小限の主観性で評価できるように、十分なガイダンスを提供する必要があります。
Authors SHOULD attempt to provide guidelines that allow the IANA to assign new values directly without requiring review by a Designated Expert. This can be done easily in many cases by designating a range of values for direct assignment by the IANA while simultaneously reserving a sufficient portion of the name space for future use by requiring that assignments from that space be made only after a more stringent review.
著者は、指定された専門家によるレビューを必要とせずに、IANAが新しい値を直接割り当てることを可能にするガイドラインを提供しようとする必要があります。これは、多くの場合、IANAによる直接割り当ての値の範囲を指定することで簡単に行うことができ、同時に、より厳密なレビューの後にのみそのスペースからの割り当てを行うことを要求することにより、将来の使用のために名前空間の十分な部分を予約します。
Finally, it is quite acceptable to pick one of the example policies cited above and refer to it by name. For example, a document could say something like:
最後に、上記のポリシー例の1つを選択して、名前で参照することはまったく問題ありません。たとえば、ドキュメントは次のようになります。
Following the policies outlined in [IANA-CONSIDERATIONS], numbers in the range 0-63 are allocated as First Come First Served, numbers between 64-240 are allocated through an IETF Consensus action and values in the range 241-255 are reserved for Private Use.
[IANA-CONSIDERATIONS]で概説されているポリシーに従って、0〜63の範囲の数値は先着順で割り当てられ、64〜240の数値はIETFコンセンサスアクションによって割り当てられ、241〜255の範囲の値はプライベート用に予約されています使用する。
For examples of documents that provide good and detailed guidance to the IANA on the issue of assigning numbers, consult [MIME-REG, MIME-LANG].
番号の割り当てに関するIANAへの適切で詳細なガイダンスを提供するドキュメントの例については、[MIME-REG、MIME-LANG]を参照してください。
For all existing RFCs that either explicitly or implicitly rely on the IANA to evaluate assignments without specifying a precise evaluation policy, the IANA will continue to decide what policy is appropriate. The default policy has been first come, first served. Changes to existing policies can always be initiated through the normal IETF consensus process.
明示的または暗黙的にIANAに依存して正確な評価ポリシーを指定せずに割り当てを評価する既存のすべてのRFCについて、IANAは適切なポリシーを決定し続けます。デフォルトのポリシーは先着順です。既存のポリシーの変更は、通常のIETFコンセンサスプロセスを通じていつでも開始できます。
All future RFCs that either explicitly or implicitly rely on the IANA to register or otherwise manage assignments MUST provide guidelines for managing the name space.
明示的または暗黙的にIANAに依存して登録またはその他の方法で割り当てを管理する将来のすべてのRFCは、名前空間を管理するためのガイドラインを提供する必要があります。
Information that creates or updates a registration needs to be authenticated.
登録を作成または更新する情報は認証される必要があります。
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 mislead as to the true security issues surrounding the use of a registered number.
プロトコルの潜在的なセキュリティの脆弱性に関する情報は、時間とともに変化する可能性があります。同様に、割り当てられた番号の使用方法に関連するセキュリティの脆弱性（プロトコルを識別する場合など）も変更される可能性があります。新しい脆弱性が発見された場合、そのような脆弱性に関する情報を既存の登録に添付する必要がある場合があります。これにより、登録された番号の使用に関する真のセキュリティ問題についてユーザーが誤解を招かないようになります。
An analysis of security issues is required for all parameters (data types, operation codes, keywords, etc.) used in IETF protocols or registered by the IANA. All descriptions of security issues must be as accurate as possible regardless of level of registration. In particular, a statement that there are "no security issues associated with this type" must not given when it would be more accurate to state that "the security issues associated with this type have not been assessed".
IETFプロトコルで使用されている、またはIANAによって登録されているすべてのパラメーター（データタイプ、オペレーションコード、キーワードなど）について、セキュリティ問題の分析が必要です。セキュリティ問題のすべての説明は、登録のレベルに関係なく、可能な限り正確である必要があります。特に、「このタイプに関連するセキュリティの問題は評価されていない」と述べる方がより正確である場合、「このタイプに関連するセキュリティの問題はない」との記述は行わないでください。
Jon Postel and Joyce K. Reynolds provided a detailed explanation on what the 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 K. Reynoldsは、割り当てを効率的に管理するためにIANAが必要とするものについて詳細な説明を提供し、このドキュメントの複数のバージョンについて根気よくコメントを提供しました。ブライアンカーペンターは、ドキュメントの以前のバージョンに役立つコメントを提供しました。 「セキュリティに関する考慮事項」セクションの1つの段落は、[MIME-REG]から借用されました。
[ASSIGNED] Reynolds, J., and J. Postel, "Assigned
Numbers", STD 2, RFC 1700, October 1994. See
also: http://www.iana.org/numbers.html
[BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.
[BGP4-EXT]ベイツ。 T.、Chandra、R.、Katz、D。、およびY. Rekhter、「BGP-4のマルチプロトコル拡張機能」、RFC 2283、1998年2月。
[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月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA-CONSIDERATIONS] Alvestrand、H。およびT. Narten、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IETF-PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[IETF-PROCESS] Bradner、S。、「The Internet Standards Process-Revision 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] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
[IPSEC] Atkinson、R。、「Security Protocol for the Internet Protocol」、RFC 1825、1995年8月。
[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月。
[MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997.
[MIME-LANG] Freed、N。およびK. Moore、「MIMEパラメータ値とエンコードされたワード拡張：文字セット、言語、および継続」、RFC 2184、1997年8月。
[MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[MIME-REG] Freed、N.、Klensin、J。、およびJ. Postel、「Multipurpose Internet Mail Extension（MIME）Part Four：Registration Procedures」、RFC 2048、1996年11月。
[SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998.
[SCSP] Luciani、J.、Armitage、G。およびJ. Halpern、「Server Cache Synchronization Protocol（SCSP）」、RFC 2334、1998年4月。
[SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.
[SMTP-EXT] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。およびD. Crocker、「SMTP Service Extensions」、RFC 1869、1995年11月。
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@raleigh.ibm.com
電話：919-254-7798メール：narten@raleigh.ibm.com
Harald Tveit Alvestrand Maxware Pirsenteret N-7005 Trondheim Norway
Harald Tveit Alvestrand Maxware Pier Center N-7005 Trondheim Norway
Phone: +47 73 54 57 97
EMail: Harald@Alvestrand.no
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。