RFC2434 ＲＦＣでＩＡＮＡの考慮の章を書くためのガイドライン

この文書はRFC2434の日本語訳（和訳）です。この文書の翻訳内容の正確さは保障できないため、正確な知識や情報を求める方は原文を参照してください。翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。この翻訳内容に誤りがある場合、訂正版の公開や、誤りの指摘は適切です。この文書の配布は元のＲＦＣ同様に無制限です。

Network Working Group T. Narten Request for Comments: 2434 IBM BCP: 26 H. Alvestrand Category: Best Current Practice Maxware October 1998 Guidelines for Writing an IANA Considerations Section in RFCs ＲＦＣでＩＡＮＡの考慮の章を書くためのガイドライン Status of this Memo この文書の状態 This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. このメモはインターネット共同体のための情報を供給します。これはインターネット標準を指定しません。このメモの配布は無制限です。 Copyright Notice 著作権表示 Copyright (C) The Internet Society (1998). All Rights Reserved. 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). 多くのプロトコルが定数と他の周知の値から成り立つ識別子を利用します。プロトコルが定義され、利用が開始された後でも、新しい値が割り当てられる必要があるかもしれません（例えば、ＤＨＣＰの新しいオプション、ＩＰｓｅｃの新しい暗号あるいは認証アルゴリズムタイプ）。このような値が整合していて、異なる実装で解釈できることを保証するために、割当ては中央集権的に執行されなくてはなりません。ＩＥＴＦプロトコルで、その役割はインターネット番号割当当局（ＩＡＮＡ）によって供給されます。 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. ＩＡＮＡが慎重に特定の名前空間を管理するために、新しい値を割当てることができる状態を記述してたガイドラインを必要とします。もしＩＡＮＡに名前空間管理の役割を期待するなら、ＩＡＮＡにその役割を記述した明快で簡潔な指示を与えなくてはなりません。この文書は値を名前空間に割当てることに対するポリシを定式化する際に考慮されるべき問題を論じ、そして文書の著者に、文書に含める、ＩＡＮＡが必要とする、特定の文のガイドラインを供給します。 Table of Contents 目次 1. Introduction 1. はじめに 2. Issues To Consider 2. 考慮するべき問題 3. Registration maintenance 3. 登録維持管理 4. What To Put In Documents 4. 文書に何を入れるべきか 5. Applicability to Past and Future RFCs 5. 過去と将来のＲＦＣへの適用性 6. Security Considerations 6. セキュリティの考察 7. Acknowledgments 7. 謝辞 8. References 8. 参考文献 9. Authors' Addresses 9. 著者のアドレス 10. Full Copyright Statement 10. 著作権表示全文 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]のプロトコルフィールドあるいはメールメッセージでのＭＩＭＥ[MIME-REG]）。プロトコルが定義された、そして派遣が始まった後さえ、新しい値が割り当てられる必要があるかもしれません（例えば、ＤＨＣＰ [DHCP]あるいは新しい暗号化での新しいオプションタイプあるいはＩＰｓｅｃ [IPsec]のための認証アルゴリズム）。このようなフィールドが異なる実装で一貫した値と解釈を持つことを保証するために、それらの割当ては中央集権で執行されなくてはなりません。ＩＥＴＦプロトコルで、この役割はインターネット番号割当当局（ＩＡＮＡ）によって供給されます。 In this document, we call the set of possible values for such a field a "name space"; its actual content may be a name, a number or another kind of value. The assignment of a specific value to a name space is called an assigned number (or assigned value). Each assignment of a number in a name space is called a registration. この文書で、我々はこのようなフィールドで可能な値の集合を「名前空間」と呼びます；その実際の内容は名前や数やその他の種類の値かもしれません。名前空間への特定の値の割当ては、割当て番号（または割当て値）と呼ばれます。それぞれの名前空間での番号の割当てが登録と呼ばれます。 In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values should be assigned. This document provides guidelines to authors on what sort of text should be added to their documents, and reviews issues that should be considered in formulating an appropriate policy for assigning numbers to name spaces. ＩＡＮＡが慎重に特定の名前空間を管理するために、新しい値を割り当てられるべき状態を記述したガイドラインを必要とします。この文書はは、どんな種類の文が文書に加えられるべきかについて、著者にガイドラインを供給し、そして名前空間に数を割当てることに対して適切なポリシの定型化で考慮されるべき問題を再検討します。 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 can be delegated, the IANA only deals with assignments at the top level. 名前空間の全てが中央集権管理を必要とするわけではありません。ある場合には、（集中）調整なしで独立に割当を行うような、名前空間の委任が可能です。ドメインネームシステムで、例えば、ＩＡＮＡはより上位レベルでの割当だけを扱い、サブドメイン空間が委任された組織によって管理されます。他の例として、ＩＴＵで定義されたオブジェクト識別子（ＯＩＤ）が同じく委任されます[ASSIGNED]。名前空間の委任ができる時、ＩＡＮＡは最上位レベルの割当だけを扱います。 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. この文書は用語'MUST'と'SHOULD'と'MAY'とその否定をＲＦＣ２１１９ [KEYWORD]で記述された方法で使用します。この場合、ＲＦＣ２１１９で使われる「仕様書」は、ＩＥＴＦ標準プロセスに委ねられているプロトコル処理の事です。 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). 名前空間を管理する際に考慮すべき主要な問題はその大きさです。もし空間が小さく限定されているなら、割当は空間を消耗させないことを保証するために慎重にされなくてはなりません。他方もし空間が本質的に無制限であるなら、それを欲する者全てに新しい値を配ることが完全に合理的であるかもしれません。しかし、空間が本質的に無制限である時でも、空間の買占めや不必要な浪費を防ぐ最小限の調整は通常望ましいです。例えば、もし空間がテキスト文字列から成り立つなら、組織が「最良」名（例えば、既存の会社名）に対応する文字列の大きな集合を得るのを阻止することは望ましいかもしれません。 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. ２番目の考慮は、どの方法で名前空間を委任するのが有効かです。割当を扱うＩＡＮＡの負担を減らすために、道は適切な場合に進むべきです。 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. ある場合には、名前空間は本質的に無制限で、そして割当て番号が安全に誰にでも配ることができます。主観的な調査が必要ない時、ＩＡＮＡがどのタイプの要求に応じるべきか、そして割当番号の要請を考慮する前にどの情報が供給されなければならないかについて、特定の指示を与えられるなら、ＩＡＮＡは直接割当を行うことが出来ます。ＩＡＮＡが割当ポリシを定義しないことに注意してください；主観評価なしで割当決定を許すガイドラインが与えられるべきです。 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. 大部分の場合、何らかの将来の割当の調査が適切で、誰が調査をするか、どの程度の精度で実行すべきかが問題です。多くの場合、名前空間に精通したＩＥＴＦ作業グループ（ＷＧ）に相談されるべきと思うかもしれません。実際は、しかしながら、ＷＧはいつか解散します、それで彼らが恒久的評価者とは思えません。どのＷＧも生成していない名前空間を個別の提出文書で作ることも可能です。 One way to insure community review of prospective assignments is to have the requester submit a document for publication as an RFC. Such an action insures that the IESG and relevant WGs review the assignment. This is the preferred way of insuring review, and is particularly important if any potential interoperability issues can arise. For example, many assignments are not just assignments, but also involve an element of protocol specification. A new option may define fields that need to be parsed and acted on, which (if specified poorly) may not fit cleanly with the architecture of other options or the base protocols on which they are built. 有望な割当の共同体批評を保障する一つの方法は要求者がＲＦＣとして文書を公開することです。このような行動はＩＥＳＧと適切なＷＧが割当の評価をすることを保証します。これは評価を保証する望ましい方法で、もし互換性問題が起こる可能性があるなら、特に重要です。例えば、多くの割当は、割当だけでなくプロトコル仕様書の要素を伴います。新しいオプションは解析と動作を必要とするフィールドを定義するかもしれず、これは（もし不完全に指定されるなら）他の構築されるオプションや基礎プロトコル体系と適合しないかもしれません。 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. ある場合には、しかしながら、割当を得るためにＲＦＣを公表する負担は極端です。しかしながら、目的に特化したメーリングリスト（例えば、メディアタイプのietf-types@iana.org）上で、あるいはより一般的なメーリングリスト（例えば、現在や前のＩＥＴＦＷＧ）上で、追加の提案を論じることは一般にまだ有用です（そして時々必要です）。このようなメーリングリストは、新しい登録で割当を得る前に公開検討を行うことや、要求者に適切な登録が何を含むべきか理解するアドバイスを与える方法を提供します。 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. メーリングリストでの議論が貴重な技術的専門知識を供給できるが、意見は変化するかもしれません、そして議論が解決なしでしばらく継続するかもしれません。加えるに、ＩＡＮＡは全部のメーリングリストには参加できず、そして合意に達成したことの決定ができません。それ故に、登録要求に関して、一般的なメーリングリストが決定的推薦を供給する役割をすることを、ＩＡＮＡは許すことができません。その代わりに、ＩＡＮＡは指名された問題の専門家を使うでしょう。ＩＡＮＡは「指名された専門家」が割当問題でアドバイスすることを当てにするでしょう。すなわち、ＩＡＮＡは受け取った要請を特定の「連絡ポイント」（１人あるいは数人）に転送し、そして指名された専門家から返された推薦に対して行動を起こします。指名された専門家は正確にそれを評価するために必要なだけの広い割当要請の批評を始めて調整することができます。 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. 指名された専門家はＩＥＳＧの適切なエリア部長によって任命されます。彼らは新しい番号空間を作る文書がＲＦＣとして公表される時に典型的に命名されますが、元々の任命された専門化が後で忙しくなるかもしれないので、適切なエリア部長は、もし必要であるなら、後継者を指定するでしょう。 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]の６.５章で概説された標準的なＩＥＴＦ抗議手順令を使って抗議できます。指名された専門家はＩＥＳＧによって任命されるので、ＩＥＳＧが解任するかもしれません。 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. 私的利用－私的あるいはローカルな使用のためだけ、タイプと目的はローカルサイトで定義される。多数のサイトが異なる（そして相容れない）方法で同じ値を使うのを阻止することはしません。ＩＡＮＡがこのような割当を調査する必要がなく、そして割当は一般に互換性の役に立ちません。 Examples: Site-specific options in DHCP [DHCP] have significance only within a single site. "X-foo:" header lines in email messages. 例：ＤＨＣＰ[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. 階層的割当－委任された管理者が、制御権を得た名前空間の部分上で値を割り当てることができます。ＩＡＮＡは他のポリシに従って名前空間のより高いレベルを制御します。 Examples: DNS names, 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. 来た順に割当－連絡先と番号の使用目的の短い説明を提出すれば、誰でも割当て番号を得られます。番号では、正確な値は一般にＩＡＮＡによって割り当てられます；名前では、特定の名前が通常要求されます。 Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP and UDP port numbers. 例：vnd. （ベンダ割当）ＭＩＭＥタイプ[MIME-REG]、ＴＣＰとＵＤＰポート番号。 Expert Review - approval by a Designated Expert is required. 専門家調査－指名された専門家による賛成が必要です。 Specification Required - Values and their meaning must be documented in an RFC or other permanent and readily available reference, in sufficient detail so that interoperability between independent implementations is possible. 仕様書要求－値とその意味は、独立な実装間の互換性が可能であるように、ＲＦＣや他の永久的で容易に利用可能な文献により、十分詳細に文書化されなくてはなりません。 Examples: 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). ＩＥＳＧ承認－新しい割当がＩＥＳＧによって承認されなければなりませんが、要求がＲＦＣ文書化されるという条件がありません（ＩＥＳＧが事例によって文書や他の材料を求める決定ができます）。 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). ＩＥＴＦ合意－新しい値がＩＥＴＦ合意手順を通して割り当てられます。特に、新しい割当がＩＥＳＧで承認されてＲＦＣによって作られます。一般に、ＩＥＳＧは適切な人々（例えば、もしあれば、適切な作業グループ）から割当の見込みの意見を求めるでしょう。 Examples: SMTP extensions [SMTP-EXT], BGP Subsequent Address Family Identifiers [BGP4-EXT]. 例：ＳＭＴＰ拡張[SMTP-EXT]、ＢＧＰ次アドレスファミリ識別子 [BGP4-EXT]。 Standards Action - Values are assigned only for Standards Track RFCs approved by the IESG. 標準化行動－値がＩＥＳＧが認可した標準化中ＲＦＣでだけ割り当てられます。 Examples: MIME top level types [MIME-REG] 例：最上位ＭＩＭＥタイプ[MIME-REG]。 It should be noted that it often makes sense to partition a name space into several categories, with assignments out of each category handled differently. For example, the DHCP option space [DHCP] is split into two parts. Option numbers in the range of 1-127 are globally unique and assigned according to the Specification Required policy described above, while options number 128-254 are "site specific", i.e., Local Use. Dividing the name space up makes it possible to allow some assignments to be made with minimal review, while simultaneously reserving some part of the space for future use. 名前空間をいくつかに分類し、それぞれの分類で割当が異なる処理をされることが、しばしばされた適切なことを指摘します。例えば、ＤＨＣＰオプション空間[DHCP]は２つの部分に分けられます。１～１２７の範囲のオプション番号はグローバルに一意で、上に記述された要求仕様書ポリシで割り当てられryが、オプション番号１２８～２５４が「サイト固有」、すなわちローカル利用で割り当てられます。名前空間を分けることはある割当で、同時に将来の使用のために空間の一部を確保しながら、最小調査とすることを可能にします。 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. - 誰かが登録項目に対する重要な反対意見を持つが、著者が登録を変えることに同意しない場合、登録にコメントをする事を許す。 - 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. - ＩＥＳＧや他の権威に登録所有権の再割当権限を指定する。これは主に、いずれかの登録所有者に、必要な更新をするための連絡ができない時に、問題を解決するはずです。 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: 前の章で、周知の番号と他のプロトコル定数を割り当てるポリシを定式化する際に考慮されるべきいくつかの問題を提示しました。適切なポリシ定式化し、そして適切な文書でそれを指定するのは作業グループや文書著者の仕事です。ある場合には、「ＩＡＮＡの考慮」の章を持つことが適切であるかもしれません。特に、名前空間を作り（あるいは既存の空間の定義を修正し）そしてＩＡＮＡにその空間を持続する役割（例えば、登録された値の倉庫の役）を期待をする文書は、将来の割当の手順を文書化しなければなりません (MUST)。このような章がはっきりと述べなくてはなりません(MUST)： - 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. - 割当て番号のアプリケーションが調査される必要があるか否か。もし調査が必要なら、調査方法が指定されなくてはなりません(MUST)。指名された専門家が使われる時、文書内で指名された専門家を指名してはなりません(MUST NOT)；その代わりに、文書が賛同のためにＩＥＳＧに送られる時に適切なＩＥＳＧエリア部長に名前が伝えられるべきです。 - 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のよに）、そのメーリングアドレスが指定されるべきです。しかしながら、指名された専門家の使用も指定されなければならない(MUST)ことに注意してください。 - 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. - もしＩＡＮＡが外の評価なしに割当をすることを期待されるなら、要求が最小の主観で評価できるように、十分な指導が供給されなくてはなりません(MUST)。 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)。これは広範囲の値を指定することで多くの場合にＩＡＮＡによる直接割当てを容易にし、同時に将来の使用のために名前空間の十分な部分を確保して、この空間からの割当をより厳しい評価後だけ要求することができます。 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: 最終的に、引用されてポリシ例の１つを選び、そして名指しでそれを参照することは非常に許容できます。例えば、文書が以下のように書けます： 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]でで概説されたポリシに従い、番号範囲０～６３が来た順に割当てられ、番号範囲６４～２４０がＩＥＴＦ合意行動を通して割り当てられ、番号範囲２４１～２５５が私的利用のために確保されます。 For examples of documents that provide good and detailed guidance to the IANA on the issue of assigning numbers, consult [MIME-REG, MIME- LANG]. 番号割当て問題についてのＩＡＮＡに良い、そして詳細な指導を供給する文書の例は[MIME-REG, MIME-LANG]を調べてください。 5. Applicability to Past and Future RFCs 5. 過去と将来のＲＦＣへの適用性 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. 明示的にあるいは暗黙のうちにＩＡＮＡに依存するすべての既存のＲＦＣが正確な評価ポリシを指定しないで割当を評価するために、ＩＡＮＡは何のポリシが適切であるか決め続けるでしょう。デフォルトのポリシは来た順に割当てです。既存のポリシに対する変更は、常に標準的なＩＥＴＦ合意手順を通して始めることができます。 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. 明示的にあるいは暗黙のうちにＩＡＮＡかその他に登録の割当管理を当てにする将来のＲＦＣは名前空間を管理することに対するガイドラインを供給しなくてはなりません(MUST)。 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". セキュリティ問題の分析は、ＩＥＴＦプロトコルで使われるかＩＡＮＡに登録されるすべてのパラメータ（データタイプ、オペレーションコード、キーワードなど）で必要とされます。すべてのセキュリティ問題の記述は登録レベルにかかわらず可能な限り正確でなくてはなりません。特に、「このタイプに関するセキュリティ事項は評価されていない」が正確である場合に、「このタイプに関するセキュリティ事項がない」という宣言をしてはなりません。 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]. Jon PostelとJoyce K. ReynoldsがＩＡＮＡが効率的に割当管理をするために何が必要かについて詳細な説明を用意し、そして根気よくこの文書の多数の版にコメントしました。Brian Carpenterは文書の初期の版に助けになるコメントを供給しました。セキュリティの考察の１つの段落は[MIME-REG]から借用されました。 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 [BGP4-EXT] Bates. T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998. [DHCP-OPTIONS] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [IETF-PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [MIME-LANG] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2184, August 1997. [MIME-REG] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extension (MIME) Part Four: Registration Procedures", RFC 2048, November 1996. [SCSP] Luciani, J., Armitage, G. and J. Halpern, "Server Cache Synchronization Protocol (SCSP)", RFC 2334, April 1998. [SMTP-EXT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", RFC 1869, November 1995.

9. Authors' Addresses 9. 著者のアドレス

Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - BRQA/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: narten@raleigh.ibm.com Harald Tveit Alvestrand Maxware Pirsenteret N-7005 Trondheim Norway Phone: +47 73 54 57 97 EMail: Harald@Alvestrand.no 10. Full Copyright Statement 10. 著作権表示全文 Copyright (C) The Internet Society (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. 上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やインターネット標準を開発する目的で必要な場合以外は、インターネット学会や他のインターネット組織は著作権表示や参照を削除されるような変更ができません、インターネット標準を開発する場合はインターネット標準化プロセスで定義された著作権の手順に従われます。 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. この文書とここに含む情報は無保証で供給され、そしてインターネット学会とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当である事の保障を含め、すべての保証を拒否します。

Japanese translation by Ishida So