1. Introduction (はじめに)

多くのプロトコルは, 様々なプロトコルパラメータを識別するために定数を使用する拡張性のポイントを利用します。これらのフィールドの値が競合する用途を持たないようにし, 相互運用性を促進するために, それらの割り当ては中央の記録管理者によって調整されることがよくあります。IP ヘッダーの Protocol フィールド [RFC791] と MIME メディアタイプ [RFC6838] は, このような調整の2つの例です。

IETF は, IETF によって定義されたプロトコルパラメータのために IANA Functions Operator (IFO) を選択します。IETF と現在の IFO (ICANN) との間の契約では, そのエンティティは IANA PROTOCOL PARAMETER SERVICES Operator, または IPPSO と呼ばれています。過去の慣行との一貫性のため, IFO または IPPSO はこの文書では "IANA" と呼ばれます [RFC2860]。

この文書では, そのようなフィールドの可能な値の範囲を "名前空間 (namespace)" と呼びます。名前空間内の特定の値と特定の目的との結び付きまたは関連付けは, 割り当て (assignment) と呼ばれます (あるいは様々に: assigned number, assigned value, code point, protocol constant, または protocol parameter と呼ばれます)。割り当ての行為は登録 (registration) と呼ばれ, それはレジストリ (registry) のコンテキストで行われます。"割り当て (assignment)" と "登録 (registration)" という用語は, この文書全体を通じて互換的に使用されます。

与えられた名前空間で慎重に割り当てを行うためには, 新しい値が割り当てられるべき条件を説明し, 既存の値への変更をいつどのように行うことができるかを説明するガイダンスが必要です。この文書は, IANA Considerations のために提供されるガイダンスが明確であり, レジストリの運用において起こりうる様々な問題に対処することを保証するために, 仕様の著者によるこれらのガイドラインの文書化のためのフレームワークを定義します。

通常, この情報は "IANA Considerations" というタイトルの仕様の専用セクションに記録されます。

1.1 Keep IANA Considerations for IANA

専用の IANA Considerations セクションを持つ目的は, IANA のための明確かつ簡潔な情報と指示を収集する単一の場所を提供することです。技術文書は文書の他の部分に存在すべきです。IANA Considerations は, これらの他のセクションを必要に応じて参照によってのみ参照すべきです。IANA Considerations セクションを主要な技術文書として使用することは, それを文書の対象読者から隠し, IANA が取る必要のあるアクションのレビューを妨げます。

理想的な IANA Considerations セクションは, 要求された各 IANA アクションを明確に列挙し指定します。すべての該当するレジストリの完全な名前など, IANA が必要とするすべての情報を含みます。そして, 他の情報については文書の他の場所への明確な参照を含みます。

IANA アクションは通常, IANA への要求として表現されます (例えば, "IANA is asked to assign the value TBD1 from the Frobozz Registry...")。RFC Editor は, これらの文を取られたアクションを反映するように変更します ("IANA has assigned the value 83 from the Frobozz Registry...")。

1.2 For Updated Information

IANA は, ここで提供される情報を超えた追加の明確化情報を含む Web ページを維持しています。これには, 小さな更新や要約ガイダンスなどが含まれます。文書の著者は, そのページを確認する必要があります。ベストカレントプラクティスへの重要な更新は, 決定的な BCP 26 (この文書) の更新に反映される必要があります。

https://iana.org/help/protocol-registration

1.3 A Quick Checklist Upfront

この文書全体に精通していることは有用です。しかし, 迅速な参照のために戻ってきたときのために, 最も一般的に行う必要があることのチェックリストと, あまり一般的でないことを支援するための参照を以下に示します。

一般的に...

IANA が知る必要があるすべての情報を, 文書の "IANA Considerations" セクションに入れます (Section 1.1 を参照)。
そのセクションは IANA と指定された専門家レビュアーのための情報のみにとどめるようにします。重要な技術情報は文書の適切な技術セクションに入れます (Section 1.1 を参照)。
IESG は IANA 登録に関する問題を解決する権限を持っていることに注意してください。質問や問題がある場合は, 文書シェパードおよび/またはワーキンググループの議長に相談する必要があります。最終的に Area Director が関与することがあります (Section 3.3 を参照)。

新しいレジストリを作成する場合...

レジストリに説明的な名前を付け, その使用の簡単な説明を提供します (Section 2.2 を参照)。
それが属すべきレジストリグループを特定します (Section 2.1 を参照)。
新しいアイテムを登録するために必要な情報を明確に指定します (Section 2.2 を参照)。フィールドのデータ型, 長さ, 有効な範囲を必ず指定してください。
該当する場合, レジストリの初期アイテムセットを指定します (Section 2.2 を参照)。
後で形式やポリシーに変更が必要な場合に備えて, レジストリの変更管理ポリシーが IANA に明確であることを確認します (Sections 2.3 および 9.5 を参照)。
将来の登録に使用する登録ポリシー - またはポリシーのセット - を選択します (Section 4 を参照, 特に Sections 4.11 および 4.12 に注意)。
指定された専門家を必要とするポリシー (Expert Review または Specification Required) を使用している場合は, Section 5 を理解し, 指定された専門家にレビューガイダンスを提供します (Section 5.3 を参照)。
レジストリ内のアイテムまたは範囲が特別な使用のために予約されているか, それ以外の理由で割り当てに利用できない場合は, Section 6 を参照してください。

既存のレジストリに登録する場合...

レジストリを正確な名前で明確に識別し, オプションで URL で識別します (Section 3.1 を参照)。
レジストリに割り当てを行うことができる複数の範囲がある場合は, どの範囲が要求されているかを明確にします (Section 3.1 を参照)。
数値またはビット割り当てに特定の値を使用することを避け, IANA に登録時に適切な値を選択させます (Section 3.1 を参照)。これにより, 複数の文書間の登録競合を回避できます。
"参照 (reference)" フィールドには, 登録されるアイテムの最良かつ最新の文書を使用します。読者が関連する文書を見つけやすくするために, セクション番号を含めます (Sections 3.1 および 7 を参照)。