RFC2434 日本語訳
2434 Guidelines for Writing an IANA Considerations Section in RFCs. T.Narten, H. Alvestrand. October 1998. (Format: TXT=25092 bytes) (Obsoleted by RFC5226) (Updated by RFC3692) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Narten
Request for Comments: 2434 IBM
BCP: 26 H. Alvestrand
Category: Best Current Practice Maxware
October 1998
Nartenがコメントのために要求するワーキンググループT.をネットワークでつないでください: 2434IBM BCP: 26時間Alvestrandカテゴリ: 最も良い現在の練習Maxware1998年10月
Guidelines for Writing an IANA Considerations Section in RFCs
RFCsにIANA問題部に書くためのガイドライン
Status of this Memo
この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を改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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).
多くのプロトコルが定数から成る識別子と他の周知の値を利用します。 プロトコルが定義されて、展開が始まった後にさえ、新しい値は、割り当てられる(例えば、IPSecのためのDHCPの新しいオプションタイプ、新しい暗号化または認証アルゴリズムのために)必要があるかもしれません。 そのような量には異なった実現における一貫した値と解釈があるのを保障するために、主要な権威で彼らの課題を管理しなければなりません。 IETFプロトコルにおいて、その役割はインターネットAssigned民数記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に置くドキュメントに含まなければならない特定のテキストでドキュメント作者にガイドラインを提供します。
Narten & Alvestrand Best Current Practice [Page 1] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[1ページ]RFC2434ガイドライン
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
このMemoの状態… 1 1. 序論… 2 2. 考える問題… 3 3. 登録維持… 6 4. ドキュメントに置くべきもの… 7 5. 過去への適用性と未来RFCs… 8 6. セキュリティ問題… 8 7. 承認… 9 8. 参照… 9 9. 作者のアドレス… 10 10. 完全な著作権宣言文… 11
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 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-REG]のMIMEの種類)を利用します。 プロトコルが定義されて、展開が始まった後にさえ、新しい値は、(IPSecのための例えば、DHCPの新しいオプションタイプ[DHCP]、新しい暗号化または認証アルゴリズム[IPSEC])が割り当てられる必要があるかもしれません。 そのような分野には異なった実現における一貫した値と解釈があるのを保障するために、主要な権威で彼らの課題を管理しなければなりません。 IETFプロトコルにおいて、その役割はインターネットAssigned民数記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.
本書では、私たちは、そのような分野への可能な値のセットを「名前スペース」と呼びます。 実際の内容は名前、数またはもう1種類の価値であるかもしれません。 名前スペースへの特定の価値の課題は規定番号(または、割り当てられた値)と呼ばれます。 名前スペースの数の各課題は登録と呼ばれます。
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によって定義されるObject Identifiers(OIDs)を代表として派遣します[ASSIGNED]。 時は名前スペースです。
Narten & Alvestrand Best Current Practice [Page 2] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[2ページ]RFC2434ガイドライン
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.
このドキュメントはRFC2119[KEYWORDS]に述べられた方法で用語'MUST'、'SHOULD'、および'5月'、およびそれらのネガを使用します。 この場合、RFC2119によって使用される「仕様」はIETF標準化過程に提出されるプロトコルの処理を示します。
2. Issues To Consider
2. 考える問題
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).
名前スペースを管理する際に考える第一の問題はそのサイズです。 スペースは小さくサイズが限るなら、スペースが疲れ果てるようにならないのを保障するために慎重に課題をしなければなりません。 他方では、スペースが本質的には無制限であるなら、1つが欲しいだれにも新しい値を与えるのは完全に妥当であるかもしれません。 しかしながら、スペースが本質的には無制限であるときにさえ、通常、スペースの貯蔵か不要なむだになることを防ぐ最小量のレビューを持っているのは望ましいです。 例えば、スペースがテキスト文字列から成るなら、組織が「最も良い」名前(例えば、既存企業名)に対応する大きいセットのストリングを入手するのを防ぐのは望ましいかもしれません。
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が課題方針を定義しないことに注意してください。 それが少ない主観性をもって配分を決定にすることができる1セットのガイドラインをそれに与えるべきです。
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)が相談されるべきであると思うかもしれません。 しかしながら、実際には、WGsが結局解散するので、永久的な評価者であると彼らを考えることができません。 また、名前空間が個々の服従ドキュメントを通して作成されるのも、可能です。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
将来の課題の共同体レビューを保障する1つの方法はリクエスタにRFCとして公表のためのドキュメントを提出させることです。 そのような動作は、IESGと関連WGsが論評するのを保障します。
Narten & Alvestrand Best Current Practice [Page 3] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[3ページ]RFC2434ガイドライン
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.
課題。 これは、レビューを保障する都合のよい方法であり、何か潜在的相互運用性問題が起こることができるなら、特に重要です。 例えば、多くの課題が課題であるだけではありませんが、プロトコル仕様の要素をまた伴ってください。 新しいオプションは分析されて、影響されるのが必要であり、清潔に別の選択肢の構造を与えないかもしれない(不十分に指定されるなら)分野かそれらが組立しているベースプロトコルを定義するかもしれません。
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の関連Areaディレクターによって任命されます。 新しい付番スペースを作成するドキュメントがRFCとして発表されますが、元々任命された専門家が後で入手できなくなるとき、それらは通常命名されて、必要なら、関連Areaディレクターは交換を任命するでしょう。
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によって取り除かれるかもしれません。
Narten & Alvestrand Best Current Practice [Page 4] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[4ページ]RFC2434ガイドライン
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.
タイプと目的がローカル・サイトによって定義されている個人的であるか地方の使用だけのための個人的なUse。 複数のサイトが異なって(非互換)の方法で同じ値を使用するのを防ぐのを試みを全くしません。 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.
階層的な配分--スペースという名前のその部分の支配力をそれらに与えたなら、代表として派遣されたマネージャは値を割り当てることができます。 他の方針の1つに従って、IANAは名前空間の、より高いレベルを制御します。
Examples: DNS names, Object Identifiers
例: DNS名、Object Identifiers
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.
最初に、Come First Served--だれでも規定番号を得ることができます、彼らが値が何に使用されるだろうかに関する連絡先と簡単な説明を提供する限り。 数において、一般に、正確な値は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.
専門のReview--Designated Expertによる承認が必要です。
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.
仕様Required--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 Approval--IESGは新しい課題を承認しなければなりませんが、要求がRFCに記録されるという要件が全くありません(IESGは何らかのケースバイケースで材料を支える要求ドキュメントに分別がありますが)。
Narten & Alvestrand Best Current Practice [Page 5] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[5ページ]RFC2434ガイドライン
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 Consensus--新しい値はIETFコンセンサスを得るためのプロセスで割り当てられます。 明確に、IESGによって承認されたRFCsを通して新しい課題をします。 通常、IESGは適切な人々から将来の課題に関する入力を求めるでしょう(例えば関連作業部会は1であるなら存在します)。
Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address
Family Identifiers [BGP4-EXT].
例: SMTP拡張子[SMTP-EXT]、BGP Subsequent Address Family Identifiers[BGP4-EXT]。
Standards Action - Values are assigned only for Standards Track
RFCs approved by the IESG.
規格Action--値はIESGによって承認されたStandards Track RFCsのためだけに割り当てられます。
Examples: MIME top level types [MIME-REG]
例: MIMEの最高平らなタイプ[レッジをまねます]です。
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の範囲のオプション番号は、グローバルにユニークで上で説明されたSpecification Required方針によると、割り当てられます、オプションNo.128-254は「サイト特有です」が、すなわち、Local Use。 上にスペースという名前を分割するのは同時に今後の使用のためにスペースの何らかの地域を予約する間、最小量のレビューでいくつかの課題をするのを許容するのを可能にします。
3. Registration maintenance
3. 登録維持
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:
登録証明書は要求を評価して、記録するのに必要である関連情報を含む規定番号を求めて要求です。 数を割り当てる後にさえ、何人かのタイプの登録証明書は時間がたつにつれてアップデートする必要があるかもしれない追加情報を含んでいます。 パントマイムは、例えば、文字の組、言語タグなどがまさしく登録された値より多くの情報自体を通常含んでいるのをタイプします。 例の情報は連絡先情報、安全保障問題、アップデートへのポインタ、文学参照などを含むことができます。 そのような場合、ドキュメントは、だれが登録を維持して、アップデートするのに責任があるかを明確に述べなければなりません。 それは以下に適切です。
- 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.
- 何らかのメカニズムにコメントを登録に付けさせてください、他のものが登録におけるクレームに重要な反論を持っていますが、作者が登録を変えるのに同意しないケースのために。
Narten & Alvestrand Best Current Practice [Page 6] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[6ページ]RFC2434ガイドライン
- 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か別の権威を指定して、登録の所有権を再選任してください。 これは、必要なアップデートをするように登録所有者に連絡できないとき主に問題を逃れるためのものです。
4. What To Put In Documents
4. ドキュメントに置くべきもの
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.
- 規定番号のアプリケーションは、見直される必要があるかどうか レビューが必要であるなら、レビューメカニズムを指定しなければなりません。 Designated Expertが使用されているとき、ドキュメントはドキュメント自体でDesignated Expertを命名してはいけません。 代わりに、承認のためにドキュメントをIESGに送るとき、適切な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
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.
提供するSHOULDがIANAが新しい値を割り当てることができるガイドラインを試みる作者はDesignated Expertで直接必要さなしで論評します。 多くの場合、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つを選んで、それについて言及するのはかなり許容できます。 例えば、ドキュメントは以下のように言うことができました。
Narten & Alvestrand Best Current Practice [Page 7] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[7ページ]RFC2434ガイドライン
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]に概説された方針に従って、First Come First Served、IETF Consensus動作で64-240の間の数を割り当てて、兵士のUseのために範囲241-255の値を予約するとき、範囲0-63の数を割り当てます。
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レッジ、MIMEラング]に相談してください。
5. Applicability to Past and Future RFCs
5. 過去の、そして、将来のRFCsへの適用性
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を当てにするすべての既存のRFCsに関しては、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を当てにするすべての将来のRFCsがスペースという名前を管理するためのガイドラインを提供しなければなりません。
6. Security Considerations
6. セキュリティ問題
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によって示されたすべてのパラメタ(データ型、命令コード、キーワードなど)に必要です。 安全保障問題のすべての記述が登録のレベルにかかわらずできるだけ正確でなければなりません。 「このタイプに関連している安全保障問題は評価されていません」と述べるのがいつより正確であるかを考えて、特に、「このタイプに関連している安全保障問題がありません」があるという声明はそうしてはいけません。
Narten & Alvestrand Best Current Practice [Page 8] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[8ページ]RFC2434ガイドライン
7. Acknowledgments
7. 承認
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].
ジョン・ポステルとジョイス・K.レイノルズは、IANAが効率的に課題を管理するために必要とするものに詳説を提供して、このドキュメントの複数のバージョンで我慢強くコメントを提供しました。 ブライアンCarpenterはドキュメントの以前のバージョンで役に立つコメントを提供しました。 [MIME-REG]からSecurity Considerations部の1つのパラグラフを借りました。
8. References
8. 参照
[ASSIGNED] Reynolds, J., and J. Postel, "Assigned
Numbers", STD 2, RFC 1700, October 1994. See
also: http://www.iana.org/numbers.html
[割り当てられる]のレイノルズ、J.とJ.ポステル、「規定番号」STD2、1994年10月のRFC1700。 参照: 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.とチャンドラとR.とキャッツとD.とY.Rekhter、「BGP-4インチのためのMultiprotocol拡張子、RFC2283、1998年2月。」
[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月。
[IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for
Writing an IANA Considerations Section in
RFCs", BCP 26, RFC 2434, October 1998.
[IANA-問題]Alvestrand、H.、およびT.Narten、「RFCsにIANA問題部に書くためのガイドライン」、BCP26、RFC2434(1998年10月)。
[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] Atkinson, R., "Security Architecture for the
Internet Protocol", RFC 1825, August 1995.
[IPSEC] アトキンソン、R.、「インターネットプロトコルのためのセキュリティー体系」、RFC1825、1995年8月。
[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月。
[MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value
and Encoded Word Extensions: Character Sets,
Languages, and Continuations", RFC 2184, August
1997.
[ラングをまねている] N.とK.ムーア、「パラメタ値をまねてください、そして、コード化されて、拡大を言い表してください」解放されていて、 「文字コード、言語、および続刊」、RFC2184、8月1997日
[MIME-REG] Freed, N., Klensin, J. and J. Postel,
"Multipurpose Internet Mail Extension (MIME)
Part Four: Registration Procedures", RFC 2048,
November 1996.
解放された[MIME-REG]、N.、Klensin、J.、およびJ.ポステル、「マルチパーパスインターネットメールエクステンション(MIME)は4を分けます」。 「登録手順」、RFC2048、1996年11月。
Narten & Alvestrand Best Current Practice [Page 9] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[9ページ]RFC2434ガイドライン
[SCSP] Luciani, J., Armitage, G. and J. Halpern,
"Server Cache Synchronization Protocol (SCSP)",
RFC 2334, April 1998.
[SCSP] LucianiとJ.とアーミテージとG.とJ.アルペルン、「サーバキャッシュ同期プロトコル(SCSP)」、RFC2334、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. N.と解放されて、ローズとM.とStefferudとE.とD.クロッカー、「SMTPサービス拡張子」、RFC1869、1995年11月。
9. Authors' Addresses
9. 作者のアドレス
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@raleigh.ibm.com
以下に電話をしてください。 919-254-7798 メールしてください: narten@raleigh.ibm.com
Harald Tveit Alvestrand Maxware Pirsenteret N-7005 Trondheim Norway
ハラルド・Tveit Alvestrand Maxware Pirsenteret N-7005トロンヘイムノルウェー
Phone: +47 73 54 57 97 EMail: Harald@Alvestrand.no
以下に電話をしてください。 +47 73 54 57 97はメールされます: Harald@Alvestrand.no
Narten & Alvestrand Best Current Practice [Page 10] RFC 2434 Guidelines for IANA Considerations October 1998
IANA問題1998年10月のためのNarten&Alvestrandの最も良い現在の習慣[10ページ]RFC2434ガイドライン
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Narten & Alvestrand Best Current Practice [Page 11]
Narten&Alvestrandの最も良い現在の習慣[11ページ]
一覧
スポンサーリンク
