RFC5226 日本語訳
5226 Guidelines for Writing an IANA Considerations Section in RFCs. T.Narten, H. Alvestrand. May 2008. (Format: TXT=66160 bytes) (Obsoletes RFC2434) (Also BCP0026) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Narten Request for Comments: 5226 IBM BCP: 26 H. Alvestrand Obsoletes: 2434 Google Category: Best Current Practice May 2008
Nartenがコメントのために要求するワーキンググループT.をネットワークでつないでください: 5226IBM BCP: 26時間Alvestrandは以下を時代遅れにします。 2434年のGoogleカテゴリ: 最も良い現在の練習2008年5月
Guidelines for Writing an IANA Considerations Section in RFCs
RFCsに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.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネット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).
多くのプロトコルが定数から成る識別子と他の周知の値を利用します。 プロトコルが定義されて、展開が始まった後にさえ、新しい値は、割り当てられる(例えば、IPsecのためのDHCPの新しいオプションタイプ、新しい暗号化または認証変換のために)必要があるかもしれません。 そのような量がすべての実現の向こう側に一貫した値と解釈を持っているのを保証するために、主要な権威で彼らの課題を管理しなければなりません。 IETFプロトコルにおいて、その役割はインターネットAssigned民数記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.
このドキュメントはRFC2434を時代遅れにします。
Narten & Alvestrand Best Current Practice [Page 1] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[1ページ]RFC5226IANA問題部
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
1. 序論…2 2. 名前空間の管理が必要であるかもしれない理由…3 3. 専門家に指定されます…4 3.1. 指定された専門家に関する動機…4 3.2. 指定された専門家の役割…5 3.3. 指定された専門家は論評します…7 4. 登録を作成します…8 4.1. 周知のIANA方針定義…9 4.2. それを入れられるのに記録することが登録を作成します…12 4.3. 既存の登録のためのIANAガイドラインをアップデートします…15 5. 既存の登録に新しい値を示します…15 5.1. 入れるべきことは値を示しながら、いつを記録するか…15 5.2. 登録証明書をアップデートします…17 5.3. 登録手順をくつがえします…17 6. 種々雑多な問題…18 6.1. IANA動作が全くないとき…18 6.2. 記録された指導を欠いている名前空間…19 6.3. 事実の後の登録証明書…19 6.4. 開墾は値を割り当てました…19 7. 上告します…20 8. メーリングリスト…20 9. セキュリティ問題…20 10. RFC2434に比例した変化…21 11. 承認…22 12. 参照…22 12.1. 標準の参照…22 12.2. 有益な参照…22
1. Introduction
1. 序論
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プロトコルにおいて、その役割はインターネットAssigned民数記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",
本書では、私たちは、そのような分野への可能な値のセットを「名前空間」と呼びます。 実価はテキスト文字列、数、またはもう1種類の価値であるかもしれません。 または、名前空間の中に特定の目的がある特定の価値の結合か協会が規定番号と呼ばれる、(割り当てられた値、または時々「コード・ポイント」
Narten & Alvestrand Best Current Practice [Page 2] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[2ページ]RFC5226IANA問題部
"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によって定義されるObject Identifiers(OIDs)を代表として派遣します[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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか? このドキュメントについて、RFC2119によって使用される「仕様」はIETF標準化過程の中にプロトコルドキュメントの処理を示します。
2. Why Management of a Namespace May Be Necessary
2. 名前空間の管理が必要であるかもしれない理由
One issue to consider in managing a namespace is its size. If the space is small and limited in size, assignments must be made carefully to prevent exhaustion of the space. If the space is essentially unlimited, on the other hand, potential exhaustion will probably not be a practical concern at all. Even when the space is essentially unlimited, however, it is usually desirable to have at least a minimal review prior to assignment in order to:
名前空間を管理する際に考える1冊はそのサイズです。 スペースは小さくサイズが限るなら、スペースの疲労困憊を防ぐために慎重に課題をしなければなりません。 他方では、スペースが本質的には無制限であるなら、潜在的疲労困憊はたぶん実用的な関心にならないでしょう全く。 しかしながら、スペースが本質的には無制限であるときにさえ、通常、課題の前に少なくとも最小量のレビューを持っているのが望ましい、:
- prevent the hoarding of or unnecessary wasting of values. For
example, if the space consists of text strings, it may be
desirable to prevent entities from obtaining large sets of
strings that correspond to desirable names (e.g., existing
company names).
- 値の貯蔵か不要なむだになることを防いでください。 例えば、スペースがテキスト文字列から成るなら、実体が望ましい名前(例えば、既存企業名)に対応する大きいセットのストリングを入手するのを防ぐのは望ましいかもしれません。
Narten & Alvestrand Best Current Practice [Page 3] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[3ページ]RFC5226IANA問題部
- provide a sanity check that the request actually makes sense and
is necessary. Experience has shown that some level of minimal
review from a subject matter expert is useful to prevent
assignments in cases where the request is malformed or not
actually needed (i.e., an existing assignment for an essentially
equivalent service already exists).
- 必要な状態で要求は実際に理解できて、ある健全度チェックを提供してください。 経験は、内容の専門家からの何らかのレベルの最小量のレビューが要求は奇形か実際に必要でない場合における課題を防ぐために役に立つのを示しました(本質的には同等なサービスのためのすなわち、既存の課題は既に存在しています)。
A second consideration is whether it makes sense to delegate the namespace in some manner. This route should be pursued when appropriate, as it lessens the burden on IANA for dealing with assignments.
2番目の考慮は何らかの方法で名前空間を代表として派遣する意味になるかどうかということです。 適切であるときに、課題に対処するためにIANAで重荷を減らすとき、このルートは追求されるべきです。
A third, and perhaps most important, consideration concerns potential impact on the interoperability of unreviewed extensions. Proposed protocol extensions generally benefit from community review; indeed, review is often essential to avoid future interoperability problems [PROTOCOL-EXT].
3番目の、そして、恐らく最も重要な考慮すべき事柄は「非-見直」された拡大の相互運用性で可能性のある衝撃に関係があります。 一般に、提案されたプロトコル拡大は共同体レビューの利益を得ます。 本当に、レビューは、将来の相互運用性問題[プロトコル-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に与えれば。
3. Designated Experts
3. 専門家に指定されます。
3.1. The Motivation for Designated Experts
3.1. 指定された専門家に関する動機
It should be noted that IANA does not create or define assignment policy itself; rather, it carries out policies that have been defined by others and published in RFCs. IANA must be given a set of guidelines that allow it to make allocation decisions with minimal subjectivity and without requiring any technical expertise with respect to the protocols that make use of a registry.
IANAが課題方針自体を作成もしませんし、定義もしないことに注意されるべきです。 むしろ、それは他のものによって定義されて、RFCsで発行された方針を行います。 それが登録を利用するプロトコルに関して最小量の主観性と技術的専門知識を必要としないで配分決定をすることができる1セットのガイドラインをIANAに与えなければなりません。
In many cases, some review of prospective allocations is appropriate, and the question becomes who should perform the review and what is the purpose of the review. One might think that an IETF working group (WG) familiar with the namespace at hand should be consulted. In practice, however, WGs eventually disband, so they cannot be considered a permanent evaluator. It is also possible for namespaces to be created through individual submission documents, for which no WG is ever formed.
多くの場合、将来の配分の何らかのレビューが適切です、そして、質問はだれがレビューを実行するべきであるか、そして、レビューの目的であることになります。 人は、なじみ深い近い名前空間でIETFワーキンググループ(WG)が相談されるべきであると思うかもしれません。 しかしながら、実際には、WGsが結局解散するので、永久的な評価者であると彼らを考えることができません。 また、名前空間が個々の服従ドキュメントを通して作成されるのも、可能です。WGは全く今までに、ドキュメントに関して形成されません。
Narten & Alvestrand Best Current Practice [Page 4] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[4ページ]RFC5226IANA問題部
One way to ensure community review of prospective assignments is to have the requester submit a document for publication as an RFC. Such an action helps ensure that the specification is publicly and permanently available, and it allows some review of the specification prior to publication and assignment of the requested code points. This is the preferred way of ensuring review, and is particularly important if any potential interoperability issues can arise. For example, some assignments are not just assignments, but also involve an element of protocol specification. A new option may define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols on which they are built.
将来の課題の共同体レビューを確実にする1つの方法はリクエスタに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に知らせます。
3.2. The Role of the Designated Expert
3.2. 指定された専門家の役割
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
指定された専門家は課題要求の適切なレビューを開始して、調整するのに責任があります。 指定された専門家の状況と判断によって、レビューは、広いか、または狭いかもしれません。 これは1セットの技術の専門家との相談にかかわるかもしれません、公共のメーリングリストについての議論、ワーキンググループとの相談、(メーリングリスト、ワーキンググループはそうしました。
Narten & Alvestrand Best Current Practice [Page 5] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[5ページ]RFC5226IANA問題部
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 Considerations部を見てください。)
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(関連Areaディレクターによる通常、推薦での)によって任命されます。 名前空間を作成するか、またはアップデートするドキュメントが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によって取り除かれるかもしれません。
Narten & Alvestrand Best Current Practice [Page 6] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[6ページ]RFC5226IANA問題部
3.3. Designated Expert Reviews
3.3. 専門のレビューに指定されます。
In the eight years since RFC 2434 was published and has been put to use, experience has led to the following observations:
RFC2434を発行して、使用につけて以来の8年間で、経験は以下の観測につながりました:
- A designated expert must respond in a timely fashion, normally
within a week for simple requests to a few weeks for more
complex ones. Unreasonable delays can cause significant
problems for those needing assignments, such as when products
need code points to ship. This is not to say that all reviews
can be completed under a firm deadline, but they must be
started, and the requester and IANA should have some
transparency into the process if an answer cannot be given
quickly.
- 指定された専門家は直ちに応じなければなりません、簡単なより複雑なもののための数週間までの要求のための通常1週間以内に。 不当な遅延は製品が乗船するためにコード・ポイントを必要とする時などの課題を必要とするもののために重大な問題を引き起こす場合があります。 これがすべてのレビューが堅い締め切りで終了できますが、それらを始めなければならないと言わないためのものであり、すばやく答えを与えることができないなら、リクエスタと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.
- コードへの不足は指します、用心深く有限残っているコード・ポイントを管理するべきであるか、または多くのコード・ポイントを求める要求をするとき、1コード・ポイントが標準であるときに。
- documentation is not of sufficient clarity to evaluate or ensure
interoperability.
- ドキュメンテーションは、相互運用性を評価するか、または確実にするために十分明快ではありません。
Narten & Alvestrand Best Current Practice [Page 7] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[7ページ]RFC5226IANA問題部
- 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による活発な開発で1つと衝突して、里子の相互運用性より両方がむしろ害を及ぼす有と衝突するでしょう。
4. Creating a Registry
4. 登録を作成します。
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.
登録を作成するのは、作成されるべき名前空間、1人の始発の課題(適切であるなら)、およびどう作られているかに関する将来の課題がことであるガイドラインについて説明することを伴います。
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.
実験的: [EXPERIMENTATION]で説明される実験用に、利用可能です。 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.
予約される: 割り当てられないように。 予約された値は特別な用途のために保たれて、それであるときに、名前空間を広げるようなものは疲れ果てるようになります。 予約された値は一般的な課題に利用可能ではありません。
Narten & Alvestrand Best Current Practice [Page 8] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[8ページ]RFC5226IANA問題部
4.1. Well-Known IANA Policy Definitions
4.1. 周知のIANA方針定義
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への指示が明確であって、明白であるということです。 しかしながら、それらの意味が広く理解されているので、これらの用語の使用は可能であるところのRECOMMENDEDです。
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).
タイプと目的がローカル・サイトによって定義されている個人的であるか地方の使用だけのための個人的なUse。 複数のサイトが異なって(非互換)の方法で同じ値を使用するのを防ぐのを試みを全くしません。 IANAがそのような課題を見直す必要は全くありません、そして、(IANAがそれらを記録しないので)一般に、課題は広い相互運用性の役に立ちません。 闘争が全く起こらないのを(使用の意図している範囲の中で)保証するのは、サイトが兵士のUse範囲を利用する責任です。
Examples: Site-specific options in DHCP [DHCP-IANA], Fibre
Channel Port Type Registry [RFC4044], Exchange Types in the
IKEv2 header [RFC4306].
例: DHCP[DHCP-IANA]、Fibre Channel Port Type Registry[RFC4044]、IKEv2ヘッダーのExchange Types[RFC4306]のサイト特有のオプション。
Experimental Use - Similar to private or local use only, with the
purpose being to facilitate experimentation. See
[EXPERIMENTATION] for details.
実験的なUse--実験を容易にするためにある目的について個人的であるか地方の使用だけと同様です。 詳細に関して[EXPERIMENTATION]を見てください。
Example: Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6,
UDP, and TCP Headers [RFC4727].
例: IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダー[RFC4727]の実験値。
Hierarchical Allocation - Delegated managers can assign values
provided they have been given control over that part of the
namespace. IANA controls the higher levels of the namespace
according to one of the other policies.
階層的なAllocation--名前空間のその部分の支配力をそれらに与えたなら、代表として派遣されたマネージャは値を割り当てることができます。 他の方針の1つに従って、IANAは名前空間の、より高いレベルを制御します。
Examples: DNS names, Object Identifiers, IP addresses.
例: DNS名、IPが記述するObject Identifiers。
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
最初に、Come First Served--課題は先着順のベースでだれにも作られています。 要求のどんな実質的なレビューもありません、よく形成されていて、既存の課題をコピーしないのを保証するのを除いて。 しかしながら、要求は事務員の情報の最少量を含まなければなりません、連絡先(Eメールアドレスを含んでいる)や値がどう使用されるかに関する簡単な説明のように。 また、要求された値のタイプに、特定の追加情報は、名前空間によって定義されるように提供される必要があるかもしれません。 数のために、一般に、正確な値はそうです。
Narten & Alvestrand Best Current Practice [Page 9] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[9ページ]RFC5226IANA問題部
assigned by IANA; with names, specific text strings can
usually be requested.
IANAによって割り当てられます。 名前で、通常、特定のテキスト文字列を要求できます。
Examples: SASL mechanism names [RFC4422], LDAP Protocol
Mechanisms, and LDAP Syntax [RFC4520].
例: SASLメカニズムはLDAPプロトコルの[RFC4422]、Mechanisms、および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].
専門のReview(または、Designated Expert)--Designated Expertによる承認が必要です。 登録を定義するとき、Designated Expertによる使用の必要書類と実績評価基準を提供するべきです。 例えば、[RFC3748]でセクション6と7.2を見てください。
Examples: EAP Method Types [RFC3748], HTTP Digest AKA
algorithm versions [RFC4169], URI schemes [RFC4395], GEOPRIV
Location Types [RFC4589].
例: EAP Method Types[RFC3748]、HTTP Digest AKAアルゴリズムバージョンURI計画[RFC4395]、GEOPRIV Location Types[RFC4589][RFC4169]。
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.
仕様Required--永久的で容易に利用可能な公共の仕様に値とそれらの意味を記録しなければなりません、詳細に十分な独立している実現の間の相互運用性は可能です。 また、使用されると、Specification RequiredはDesignated Expertの使用を含意します。(Designated Expertは公共の仕様を再検討して、共同利用できる実現を許すのが十分明確であるかどうか評価するでしょう)。 「永久的で容易に利用可能な」後ろの意志は要求された価値のIANA課題のずっと後に「見つけ-可能」であって、ドキュメントが回収可能であると合理的に予想できるということです。 RFCの公表はこの要件を達成する理想的な手段ですが、また、Specification RequiredがRFC経路の外で発表されたドキュメントに関するケースをカバーすることを意図します。 RFC公表に関しては、正常なRFC吟味の過程が必要なレビューを相互運用性に提供すると予想されます、Designated Expertは実行するためには特に健康な適格者そのようなものがレビューであったならそうするかもしれませんが。
Examples: Diffserv-aware TE Bandwidth Constraints Model
Identifiers [RFC4124], TLS ClientCertificateType Identifiers
[RFC4346], ROHC Profile Identifiers [RFC4995].
例: Diffserv意識しているTe帯域幅規制が識別子[RFC4124]、TLS ClientCertificateType識別子[RFC4346]をモデル化するのをROHCは識別子[RFC4995]の輪郭を描きます。
RFC Required - RFC publication (either as an IETF submission or as
an RFC Editor Independent submission [RFC3932]) suffices.
Unless otherwise specified, any type of RFC is sufficient
(e.g., Informational, Experimental, Standards Track, etc.).
RFC Required--RFC公表(IETF服従とした、または、RFC Editor無党派服従[RFC3932]とした)は十分です。 別の方法で指定されない場合、RFCのどんなタイプも十分です(例えば、Informational、Experimental、Standards Trackなど)。
Narten & Alvestrand Best Current Practice [Page 10] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[10ページ]RFC5226IANA問題部
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 Review--(以前、[IANA-CONSIDERATIONS]に「IETFコンセンサス」と呼ばれます) 新しい値は後援されたADとしてIESGを通して見張られたRFCsかIETF WG Documents[RFC3932][RFC3978]だけを通して割り当てられます。 意志はドキュメントと提案された課題が提案された課題が否定的に相互運用性に影響を与えないのを確実にするか、またはそうでなければ、不適当であるかダメージが大きい方法でIETFプロトコルを広げるためにIESGと適切なIETF WGs(専門家は適当なワーキンググループであるならもう存在しない)によって再検討されるということです。
To ensure adequate community review, such documents are
shepherded through the IESG as AD-sponsored (or WG)
documents with an IETF Last Call.
適切な共同体レビューを確実にするために、そのようなドキュメントはIETF Last Callと共にADで後援された(または、WG)ドキュメントとしてIESGを通して守られます。
Examples: IPSECKEY Algorithm Types [RFC4025],
Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS
Handshake Hello Extensions [RFC4366].
例: IPSECKEY Algorithm Types[RFC4025]、Accounting-Auth-方法AVPはDIAMETERで[RFC4005]、TLS Handshake Hello Extensions[RFC4366]を評価します。
Standards Action - Values are assigned only for Standards Track
RFCs approved by the IESG.
規格Action--値はIESGによって承認されたStandards Track RFCsのためだけに割り当てられます。
Examples: BGP message types [RFC4271], Mobile Node
Identifier option types [RFC4283], DCCP Packet Types
[RFC4340].
例: DCCP Packet Types[RFC4340]、モバイルNode IdentifierオプションはBGPメッセージが[RFC4271]をタイプするのをタイプします[RFC4283]。
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 Approval--新しい課題はIESGによって承認されるかもしれません。 要求がRFCに記録されるという要件が全くありませんが、IESGは何らかのケースバイケースで材料を支える要求ドキュメントに分別があります。
IESG Approval is not intended to be used often or as a
"common case"; indeed, it has seldom been used in practice
during the period RFC 2434 was in effect. Rather, it is
intended to be available in conjunction with other policies
as a fall-back mechanism in the case where one of the other
allowable approval mechanisms cannot be employed in a timely
fashion or for some other compelling reason. IESG Approval
is not intended to circumvent the public review processes
implied by other policies that could have been employed for
a particular assignment. IESG Approval would be
appropriate, however, in cases where expediency is desired
and there is strong consensus for making the assignment
(e.g., WG consensus).
しばしばか「よくある例」としてIESG Approvalが使用されていることを意図しません。 本当に、それは実際にはRFC2434が有効であった期間、めったに使用されていません。 むしろ、後退メカニズムとしての他の方針に関連して場合で直ちに他の許容できる承認のメカニズムの1つを使うことができないところかある他のやむにやまれない理由に利用可能であるのは意図しています。 IESG Approvalが特定の課題に使われたかもしれない他の方針で含意された公開レビューの過程を回避することを意図しません。 しかしながら、IESG Approvalは便宜が望まれていて、課題を(例えば、WGコンセンサス)にすることに関する強いコンセンサスがある場合で適切でしょう。
Narten & Alvestrand Best Current Practice [Page 11] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[11ページ]RFC5226IANA問題部
The following guidelines are suggested for any evaluation
under IESG Approval:
以下のガイドラインはIESG Approvalの下のどんな評価のためにも示されます:
- 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はその経路を使用する理由を強制しない登録のための別の経路が利用可能であるならそれが、より適切であるという要求を拒絶して、ある(and should)をそうすることができます。
- 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 Multicastは課題[RFC3171]、IPv4 IGMP Type、Code値[RFC3228]、モバイルIPv6 Mobility Header Type、およびOption値[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.
しばしば複数のカテゴリへの名前空間をパーティションに理解できることに注意されるべきです、異なって扱われた各カテゴリの中に課題がある状態で。 例えば、多くのプロトコルが現在2つ(さらにさえ)の部品に名前空間を仕切ります、他の範囲は何らかの吟味の過程に従って、割り当てられたグローバルにユニークな課題のために予約されますが。(1つの範囲が兵士かExperimental Useのために部品で予約されます)。 名前空間を範囲に分割するのに、適所に異なった範囲に異なった方針を持っているのは可能になります。
Examples: LDAP [RFC4520], Pseudowire Edge to Edge Emulation (PWE3) [RFC4446].
例: LDAP[RFC4520]、Pseudowireはエミュレーション(PWE3)[RFC4446]を斜めに進ませるために斜めに進みます。
4.2. What to Put in Documents That Create a Registry
4.2. 登録を作成するドキュメントに置くべきもの
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
1) 作成される、そして/または、維持される登録(または、サブ登録)の名前。 名前は、IANAウェブページに現れて、新しいスペースから値を割り当てる必要がある将来のドキュメントに示されるでしょう。 そして、フルネーム、(略語、適切であるなら提供するべきです。 それが非常に望ましい、それ
Narten & Alvestrand Best Current Practice [Page 12] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[12ページ]RFC5226IANA問題部
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]
選ぶのは容易に別のものの名前がある「混乱させ-可能」が登録でなかったなら命名します。 サブ登録、登録をaが離れている作成するのが特定するべきであるとき、明確に特定されてください。 既に既存の登録について言及するとき、正確に登録を特定するためにURLを提供するのは役立っています。 しかしながら、最終的な公表の前にRFCからそのようなすべてのURLを取り除くでしょう。 例えば、ドキュメントは以下を含むかもしれません。 [TO BE REMOVED: この登録は以下の位置: 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.
以下に注意してください。 Designated Expertが使用されているとき、ドキュメントはドキュメント自体でDesignated Expertを命名してはいけません。 代わりに、承認のためにドキュメントをIESGに送るとき、適切なAreaディレクターに名前をリレーするべきです。
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 などの)(指定されていて、アドレスがそうするべきであるその郵送)で見直されてください。 しかしながら、また、メーリングリストが指定されるときDesignated Expertのための要件を指定しなければならないことに注意してください(セクション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) 登録エントリーのサイズ、形式、および構文。 新しい名前/数のスペースを作成するとき、作者は登録値が表示されるべきである正確な形式と同様に登録(そして、サブ登録)値(例えば、整数のための有効枠、ストリングにおける長さの制限など)に関するどんな技術的要求事項についても説明しなければなりません。 数の課題として、値が小数、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
5) 課題と予約に頭文字をつけてください。 どんな初期の課題や登録証明書も特定するために明確な指示を提供するべきです。 添加、予約されていることになっているどんな範囲でも
Narten & Alvestrand Best Current Practice [Page 13] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[13ページ]RFC5226IANA問題部
for "Private Use", "Reserved", "Unassigned", etc. should be
clearly indicated.
「私用」において、「予約され」て、「割り当てられなかった」などは明確に示されるべきです。
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つ(さらに)を選んで、名前でそれについて言及するのはかなり許容できます。 本当に、これはサンプル方針が必要なレベルのレビューを提供するそれらの場合で都合のよいメカニズムです。 また、どういう問題が吟味の過程によって考慮に入れられるべきであるかために上の方針の1つを引用して、別途ガイドラインを含んでいるのも許容できます。 例えば、RADIUS[RFC3575]はDesignated Expertの使用を指定しますが、Designated Expertが続くはずである特定の追加評価基準を含んでいます。
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]:
このドキュメントはTBD1の値がDHCP Optionスペース[公表: http://www.iana.org/assignments/bootp-dhcp-parameters で取り除く][DHCP-OPTIONS][DHCP-IANA]から割り当てられた"FooBar"(セクションyを見る)の権利を与えられた新しいDHCPオプションを定義します:
Data
Tag Name Length Meaning
---- ---- ------ -------
TBD1 FooBar N FooBar server
データタグ名前長さの意味---- ---- ------ ------- TBD1 FooBar N FooBarサーバ
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オプションは8ビットのFooType分野を定義します。(IANAはFooBarオプションで「FooType値」の権利を与えられた新しいサブ登録を、それに作成して、維持することになっています)。 DHCP FooBar FooType登録への初期の値を以下に与えます。 将来の課題はExpert Review[IANA-CONSIDERATIONS]を通して作られていることです。 課題は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
値のDHCP FooBar FooType名前定義---- ------------------------ ---------- 0 1予約されたFrobnitz Seeセクションy.1 2 NitzFrob Seeセクションy.2 3-254 Unassigned255Reserved
For examples of documents that provide detailed guidance to IANA
on the issue of assigning numbers, consult [RFC2929], [RFC3575],
[RFC3968], and [RFC4520].
割り当て番号の問題で詳細な指導をIANAに供給するドキュメントの例に関しては、[RFC2929]、[RFC3575]、[RFC3968]、および[RFC4520]に相談してください。
Narten & Alvestrand Best Current Practice [Page 14] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[14ページ]RFC5226IANA問題部
4.3. Updating IANA Guidelines for Existing Registries
4.3. 既存の登録のためのIANAガイドラインをアップデートします。
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].
既に既存(すなわち、以前に作成された)の名前空間(明らかかそれとなく作成されるか否かに関係なく)のために登録手続をアップデートすると、新しい名前空間を作成するとき使用されるそれと同様の過程は従われます。 すなわち、既存の名前空間を参照して、次に取り扱い課題のための詳細なガイドラインをそれぞれの個々の名前空間に提供するドキュメントは、製作されます。 通常、そのような文書はBest Current Practices(BCPs)[IETF-PROCESS]として処理されます。
Example documents that updated the guidelines for managing (then) pre-existing registries include: [RFC2929], [RFC3228], and [RFC3575].
(そして) 登録を先在させながら管理するためのガイドラインをアップデートした例のドキュメントは: [RFC2929]、[RFC3228]、および[RFC3575。]
5. Registering New Values in an Existing Registry
5. 既存の登録に新しい値を示します。
5.1. What to Put in Documents When Registering Values
5.1. 値を示すときドキュメントに置くべきもの
Often, documents request an assignment from an already existing namespace (i.e., one created by a previously published RFC). In such cases:
しばしば、ドキュメントは既に既存の名前空間(すなわち、以前に発行されたRFCによって作成されたもの)から課題を要求します。 そのような場合:
- Documents should clearly identify the namespace in which each
value is to be registered. If the registration goes into a
sub-registry, the author should clearly describe where the
assignment or registration should go. It is helpful to use the
exact namespace name as listed on the IANA web page (and
defining RFC), and cite the RFC where the namespace is defined.
- ドキュメントは明確に、登録されている各値がことである名前空間を特定するはずです。 登録がサブ登録に入るなら、作者は、課題か登録がどこに行くべきであるかを明確に説明するべきです。 IANAウェブページに記載されているように(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を提供するのは役立っています。 しかしながら、通常、最終的な公表の前にRFCからそのようなURLを取り除くべきです、IANA URLが将来安定しているために保証されないので。 ドキュメントに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]
例として、ドキュメントは以下を含むかもしれません。 [TO BE REMOVED: この登録は以下の位置: 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
- 要求された各値にユニークな参照を与えるべきです。 値が数値である、ときには、記法を使用してください: TBD1、TBD2など 実際のIANA-割り当てられた値が記入されるべきであるドキュメント中では、"TBDx"記法を使用してください。 力添えが確実にするこれ
Narten & Alvestrand Best Current Practice [Page 15] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[15ページ]RFC5226IANA問題部
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.
最終的な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"の値を指定するはずです。 しかしながら、いくつかの場合、値はテストするか、早めの実現に使用されたかもしれません。 そのような場合、どんな特定の値が使用されるべきであるか(選択の理由と共に)を示唆するテキストを含んでいるのは許容できます。 例えば、1つはテキストを含むかもしれません。「それが実現に使用されるとき、値の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 Considerations部は適宜ポインタによるIANA動作のすべてをドキュメントのほかの場所の関連セクションへまとめるべきです。 複数の値が要求されているとき、一般に、概要テーブルを含んでいるのは役立っています。 また、同じ形式にはこのテーブルがあるのも、IANAウェブサイトに載るべきであるように役立っています。 例えば:
Value Description Reference
-------- ------------------- ---------
TBD1 Foobar [RFCXXXX]
値の記述参照-------- ------------------- --------- 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はRFC3315のセクション24.3で定義されたDHCPオプションコードスペースからDNS Recursive Name ServerオプションへのTBD1のオプションコード値とDomain検索ListオプションへのTBD2のオプションコード値を割り当てました。
Narten & Alvestrand Best Current Practice [Page 16] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[16ページ]RFC5226IANA問題部
5.2. Updating Registrations
5.2. 登録証明書をアップデートします。
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メディアタイプ、文字の組、および言語タグなどはまさしく登録された値より多くの情報自体を通常入れます。 例の情報は連絡先情報、安全保障問題、アップデートへのポインタ、文学参照などを含むことができます。 そのような場合、名前空間を定義するドキュメントは、だれが登録を維持して、アップデートするのに責任があるかを明確に述べなければなりません。 異なった場合では、以下の1つ以上を指定するのは適切であるかもしれません:
- 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、Designated Expert、または別の実体を指定して、そうすることに関するあらゆる登録に関連している記入者と要件や状態を変えてください。 これは、記入者に必要なアップデートをするように達することができないとき主に問題を逃れるためのものです。
5.3. Overriding Registration Procedures
5.3. 登録手順をくつがえします。
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
RFC2434が発行されて以来、経験は、プロトコルが配備された後に個々のプロトコルのための記録されたIANA問題がいつも適切に現実をカバーするというわけではないのを示しています。 例えば、多くの、より古いルーティング・プロトコルには、記録されて、詳細なIANA問題がありません。 さらに、記録されたIANA問題はワーキンググループドキュメント(強いコンセンサスがある)さえ実際のRFC公表の前にIANAからコード・ポイントを得るのを許容できないくらい厳しいのが時々わかっています。 他の場合では、記録された手順は、不明瞭であり、すべてのケースをカバーするために無視されます。 配分が進むべきですが、記録された手順がそのような課題をサポートしないという強いIETFコンセンサスがある個々の場合における課題を許容するために、そのような場合課題を承認する権威をIESGに与えます。 意志は、適切に記録された手順を却下しないか、またはプロトコルが適切にそれらのIANA問題を記録する必要性を取り除くことです。 代わりに、意志は個々の場合におけるそれが明白である課題にそれを可能にすることです。
Narten & Alvestrand Best Current Practice [Page 17] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[17ページ]RFC5226IANA問題部
assignment should just be made, but updating the IANA process just to assign a particular code point is viewed as too heavy a burden.
ただ課題をするべきですが、重過ぎる負担としてただ特定のコード・ポイントを割り当てるために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は、不当な遅延の費用で見るのではなく、必要な課題に関して名前空間のための不十分なIANA登録手順が改訂されるのをIETF標準化過程で見たがっています。 IESGがこのセクションで行動を取らなければならなかったなら、それはIANA登録手順をアップデートするべきであるという強いインディケータです、ことによると進行中のプロトコル仕事と平行して。
6. Miscellaneous Issues
6. 種々雑多な問題
6.1. When There Are No IANA Actions
6.1. 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 Considerations部を含んでいるはずです。
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か個々のsubmitterが本当になるように慎重にそれについて確かめた後にこの声明、または同等物を挿入するだけでよいです。 「決まり文句」の問題も熟慮なしでそのような言葉遣いを使用するのは実行される不完全であるか不正確な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パラメタの値はBarfoo登録によってRabfoo Forumを代表して割り当てられます。 したがって、このドキュメントには、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
または
Narten & Alvestrand Best Current Practice [Page 18] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[18ページ]RFC5226IANA問題部
[RFC Editor: please do not remove this section.]
[RFC Editor: このセクションを取り外さないでください。]
6.2. Namespaces Lacking Documented Guidance
6.2. 記録された指導を欠いている名前空間
For all existing RFCs that either explicitly or implicitly rely on IANA to evaluate assignments without specifying a precise evaluation policy, IANA (in consultation with the IESG) will continue to decide what policy is appropriate. Changes to existing policies can always be initiated through the normal IETF consensus process.
的確な評価方針を指定しないで課題を評価するために明らかかそれとなくIANAを当てにするすべての既存のRFCsに関しては、IANA(IESGとの相談における)は、どんな方針が適切であるかを決め続けるでしょう。 正常なIETFコンセンサスを得るためのプロセスで既存の方針への変化をいつも起こすことができます。
All future RFCs that either explicitly or implicitly rely on IANA to register or otherwise manage namespace assignments MUST provide guidelines for managing the namespace.
名前空間課題を登録するか、またはそうでなければ、管理するために明らかかそれとなくIANAを当てにするすべての将来のRFCsが名前空間を管理するためのガイドラインを提供しなければなりません。
6.3. After-the-Fact Registrations
6.3. 事実の後の登録証明書
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との相談は教えられます。
6.4. Reclaiming Assigned Values
6.4. 割り当てられた値を取り戻します。
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.)
- そして、値が値が今までに使用されたかどうか決定するために配属されるオリジナルのパーティーに連絡するのを試みをするべきである、そうだとすれば、展開の範囲。 (いくつかの場合、製品は、決して出荷しなかったか、または長い間、使用されるのをやめています。 他の場合では、値が実際に全く決して使用されなかったのが知られているかもしれません。)
Narten & Alvestrand Best Current Practice [Page 19] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[19ページ]RFC5226IANA問題部
- 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 Approvalがこの場合必要です。
- 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 Last Callを含んでいる)を通るRFCに書くのは適切であるかもしれません。
7. Appeals
7. 上告
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で説明されるように正常なIETF上告プロセスを使用することでIANAによってされた登録決定の上告をすることができます。 明確に、上告は(必要なら)IABへの上告などがあとに続いたIESGに向けられるべきです。
8. Mailing Lists
8. メーリングリスト
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メーリングリストが行為のいかなる規則も受けることがあります、そして、リスト管理のメソッドは現在、Best Current PracticesかIESG決定で定義されます。
9. Security Considerations
9. セキュリティ問題
Information that creates or updates a registration needs to be authenticated and authorized. IANA updates registries according to instructions in published RFCs and from the IESG. It also may accept clarifications from document authors, relevant WG chairs, Designated Experts, and mail list participants, too.
登録を作成するか、またはアップデートする情報は、認証されて、認可される必要があります。 指示によると、IANAは発行されたRFCsとIESGから登録をアップデートします。 また、それはドキュメント作者と関連WGいす(Designated Experts)とメール・リスト関係者からも明確化を受け入れるかもしれません。
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問題の責任です。
Narten & Alvestrand Best Current Practice [Page 20] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[20ページ]RFC5226IANA問題部
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.
そのようなクレームを批評するために新しい値、およびプロセスを割り当てるとき、どんな(もしあれば)セキュリティ問題を提供しなければならないかを指定する特定の登録に関連しています。
10. Changes Relative to RFC 2434
10. RFC2434に比例した変化
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 Considerationsの文脈で意味することに関する不正確な仮定をするのが迅速であることが示されて、歴史は持っています。
- Added "RFC Required" to list of defined policies.
- 「RFCが必要であること」は記載する加えられた方針を定義しました。
- Much more explicit directions and examples of "what to put in
RFCs".
- 「RFCsに置くべきもの」に関するずっと多くの明快な指示と例。
- "Specification Required" now implies use of a Designated Expert
to evaluate specs for sufficient clarity.
- 「仕様Required」は、現在、十分な明快のための仕様を評価するためにDesignated Expertの使用を含意します。
- 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の言葉遣いをかなり変えました。 主な目的は、Expert Reviewersが共同体に責任があることを明らかにして、不履行格における実績評価基準のための何らかの指導を前提とすることです。
- Changed wording to remove any special appeals path. The normal
RFC 2026 appeals path is used.
- どんな特別番組も取り除く変えられた言葉遣いは経路を上告します。 正常なRFC2026上告経路は使用されています。
- 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.
- メーリングリストが以前は、よく可能な課題(例えば、Designated Expertによる)を評価していたのを示すセクションは正常なIETF規則を受けることがあると言い足しました。
Narten & Alvestrand Best Current Practice [Page 21] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[21ページ]RFC5226IANA問題部
11. Acknowledgments
11. 承認
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 Braun、ブライアンCarpenter、ミシェルCotton、スペンサー・ダウキンズ、バーバラ・デニー、ミゲル・ガルシア、ポール・ホフマン、ラスHousley、ジョンKlensin、アリソン・マンキン、ブレークRamsdell、マークTownsley、マグヌスWesterlund、およびバートWijnenから特定のフィードバックの利益を得ました。
The original acknowledgments section in RFC 2434 was:
RFC2434の元の承認部は以下の通りでした。
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が効率的に課題を管理するために必要とするものに詳説を提供して、このドキュメントの複数のバージョンで我慢強くコメントを提供しました。 ブライアンCarpenterはドキュメントの以前のバージョンで役に立つコメントを提供しました。 [MIME-REG]からSecurity Considerations部の1つのパラグラフを借りました。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
12.2. Informative References
12.2. 有益な参照
[ASSIGNED] Reynolds, J., Ed., "Assigned Numbers: RFC 1700
is Replaced by an On-line Database", RFC 3232,
January 2002.
[割り当てられます] レイノルズ、J.、エド、「数は割り当てられました」。 「RFC1700はOn-系列DatabaseによるReplacedです」、RFC3232、2002年1月。
[DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and
BOOTP Vendor Extensions", RFC 2132, March 1997.
[DHCP-オプション]アレクサンダー、S.、R.Droms、および「DHCPオプションとBOOTPベンダー拡張子」、RFC2132、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.、「新しいDHCPオプションの定義のための手順とIANAガイドラインとメッセージはタイプします」、BCP43、RFC2939、2000年9月。
[EXPERIMENTATION] Narten, T., "Assigning Experimental and Testing
Numbers Considered Useful", BCP 82, RFC 3692,
January 2004.
[実験]Narten、T.、「役に立つと考えられた実験的でテストしている数を割り当てます」、BCP82、RFC3692、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問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。
Narten & Alvestrand Best Current Practice [Page 22] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[22ページ]RFC5226IANA問題部
[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.ロバーツ、「インターネットの技術的な仕事に関する了解覚書は数の権威を割り当てました」、RFC2860、2000年6月。
[IETF-PROCESS] Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[IETF-プロセス] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[IP] Postel, J., "Internet Protocol", STD 5, RFC
791, September 1981.
[IP] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for
the Internet Protocol", RFC 4301, December
2005.
[IPSEC] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、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、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[PROTOCOL-EXT] Carpenter, B. and B. Aboba, "Design
Considerations for Protocol Extensions", Work
in Progress, December 2007.
[プロトコル-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問題」、BCP42、RFC2929、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ガイドラインは課題を扱います」、BCP51、RFC3171、2001年8月。
[RFC3228] Fenner, B., "IANA Considerations for IPv4
Internet Group Management Protocol (IGMP)", BCP
57, RFC 3228, February 2002.
[RFC3228] フェナー、B.、「IPv4インターネットグループ管理プロトコル(IGMP)のためのIANA問題」、BCP57、RFC3228、2002年2月。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for
Writing RFC Text on Security Considerations",
BCP 72, RFC 3552, July 2003.
[RFC3552]レスコラ、E.とB.Korver、「セキュリティ問題に関するテキストをRFCに書くためのガイドライン」BCP72、2003年7月のRFC3552。
[RFC3575] Aboba, B., "IANA Considerations for RADIUS
(Remote Authentication Dial In User Service)",
RFC 3575, July 2003.
[RFC3575] Aboba、B.、「半径(ユーザサービスにおけるリモート認証ダイヤル)のためのIANA問題」、RFC3575、2003年7月。
Narten & Alvestrand Best Current Practice [Page 23] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[23ページ]RFC5226IANA問題部
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson,
J., and H. Levkowetz, Ed., "Extensible
Authentication Protocol (EAP)", RFC 3748, June
2004.
[RFC3748] AbobaとB.とBlunkとL.とVollbrechtとJ.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
[RFC3775] Johnson, D., Perkins, C., and J. Arkko,
"Mobility Support in IPv6", RFC 3775, June
2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC3932] Alvestrand, H., "The IESG and RFC Editor
Documents: Procedures", BCP 92, RFC 3932,
October 2004.
[RFC3932] Alvestrand、H.、「IESGとRFCエディタは以下を記録します」。 「手順」、BCP92、RFC3932、2004年10月。
[RFC3942] Volz, B., "Reclassifying Dynamic Host
Configuration Protocol version 4 (DHCPv4)
Options", RFC 3942, November 2004.
[RFC3942] フォルツ、B.、「Dynamic Host Configuration Protocolバージョン4(DHCPv4)オプションに分類し直します」、RFC3942、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.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)ヘッダーフィールドパラメタ登録」、BCP98、RFC3968(2004年12月)。
[RFC3978] Bradner, S., Ed., "IETF Rights in
Contributions", BCP 78, RFC 3978, March 2005.
[RFC3978] ブラドナー、S.、エド、「貢献におけるIETF権利」、BCP78、RFC3978、3月2005日
[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D.
Mitton, "Diameter Network Access Server
Application", RFC 4005, August 2005.
[RFC4005] カルフーンとP.とゾルンとG.とスペンス、D.とD.ミットン、「直径ネットワークアクセス・サーバーアプリケーション」、RFC4005、2005年8月。
[RFC4025] Richardson, M., "A Method for Storing IPsec
Keying Material in DNS", RFC 4025, March 2005.
[RFC4025]リチャードソン、M.、「DNSで材料を合わせるIPsecを保存するためのメソッド」、RFC4025、2005年3月。
[RFC4044] McCloghrie, K., "Fibre Channel Management MIB",
RFC 4044, May 2005.
[RFC4044]McCloghrie(K.、「繊維チャンネル管理MIB」RFC4044)は2005がそうするかもしれません。
[RFC4124] Le Faucheur, F., Ed., "Protocol Extensions for
Support of Diffserv-aware MPLS Traffic
Engineering", RFC 4124, June 2005.
[RFC4124] Le Faucheur、F.、エド「Diffserv意識しているMPLSトラフィックのサポートのためのプロトコル拡大は設計すること」でのRFC4124、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.ジーター、「2005年11月に認証と主要な協定(通称)のバージョン2インチ、RFC4169を使用するハイパーテキスト転送プロトコル(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)について議定書の中で述べます」、RFC4271、2006年1月。
Narten & Alvestrand Best Current Practice [Page 24] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[24ページ]RFC5226IANA問題部
[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.、Akhtar、H.、およびK.チョードリ、「モバイルIPv6のためのモバイルノード識別子オプション(MIPv6)」、RFC4283(2005年11月)。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange
(IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] コーフマン、C.、エド、「インターネット・キー・エクスチェンジ(IKEv2)プロトコル」、RFC4306、12月2005日
[RFC4340] Kohler, E., Handley, M., and S. Floyd,
"Datagram Congestion Control Protocol (DCCP)",
RFC 4340, March 2006.
[RFC4340] コーラー、E.、ハンドレー、M.、およびS.フロイド、「データグラム混雑制御プロトコル(DCCP)」、RFC4340、2006年3月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport
Layer Security (TLS) Protocol Version 1.1", RFC
4346, April 2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
Mikkelsen, J., and T. Wright, "Transport Layer
Security (TLS) Extensions", RFC 4366, April
2006.
[RFC4366]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、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のためのガイドラインと登録手順は計画します」、BCP115、RFC4395、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)を層にする」RFC4422、6月2006日
[RFC4446] Martini, L., "IANA Allocations for Pseudowire
Edge to Edge Emulation (PWE3)", BCP 116, RFC
4446, April 2006.
[RFC4446] マティーニ、L.、「PseudowireのためのIANA配分はエミュレーション(PWE3)を斜めに進ませるために斜めに進む」BCP116、RFC4446、2006年4月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers
Authority (IANA) Considerations for the
Lightweight Directory Access Protocol (LDAP)",
BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC4520、2006年6月。
[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location
Types Registry", RFC 4589, July 2006.
[RFC4589] SchulzrinneとH.とH.Tschofenig、「位置は登録をタイプする」RFC4589、2006年7月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6,
ICMPv4, ICMPv6, UDP, and TCP Headers", RFC
4727, November 2006.
[RFC4727]フェナー、B.、「IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値」、RFC4727、2006年11月。
[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)フレームワーク」、RFC4995、2007年7月。
Narten & Alvestrand Best Current Practice [Page 25] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[25ページ]RFC5226IANA問題部
Authors' Addresses
作者のアドレス
Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195
トーマスNarten IBM社3039のコーンウォリスAve。 私書箱12195--BRQA/502リサーチトライアングル公園、NC27709-2195
Phone: 919-254-7798 EMail: narten@us.ibm.com
以下に電話をしてください。 919-254-7798 メールしてください: narten@us.ibm.com
Harald Tveit Alvestrand Google Beddingen 10 Trondheim, 7014 Norway
7014年のハラルドTveit Alvestrand Google Beddingen10トロンヘイム(ノルウェー)
EMail: Harald@Alvestrand.no
メール: Harald@Alvestrand.no
Narten & Alvestrand Best Current Practice [Page 26] RFC 5226 IANA Considerations Section in RFCs May 2008
RFCs2008年5月のNarten&Alvestrandの最も良い現在の習慣[26ページ]RFC5226IANA問題部
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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に情報を扱ってください。
Narten & Alvestrand Best Current Practice [Page 27]
Narten&Alvestrandの最も良い現在の習慣[27ページ]
一覧
スポンサーリンク
