3.1. 登録の文書化要件

3.1. 登録の文書化要件 (Documentation Requirements for Registrations)

多くの場合、文書は既存のレジストリ（以前に公開された文書によって作成されたもの）での割り当てを要求します。

このような文書は、各値が登録されるレジストリを明確に識別する必要があります。IANA のウェブページに記載されている正確なレジストリ名を使用し、レジストリが定義されている RFC を引用してください。既存のレジストリを参照する場合、レジストリを正確に識別するための URL を提供することが役立ちます（セクション 2.2 を参照）。

既存のレジストリで新しい割り当てを行う際に、割り当てポリシーが何であるかを言及する必要はありません。それは参照から明らかであるべきだからです。ただし、異なるポリシーを持つ異なる範囲を持つレジストリのように、複数の割り当てポリシーが適用される可能性がある場合は、どの範囲が要求されているかを明確にすることが重要です。これにより、IANA はどのポリシーが適用されるかを知り、正しい範囲で値を割り当てることができます。

登録に必要なすべての情報を提供し、レジストリに設定されている特別なプロセスに従ってください。レジストリは、登録のために登録テンプレートの完成を要求したり、登録前に議論のために特定のメーリングリストに要求を投稿するよう登録者に求めたりすることがあります。レジストリの参照文書を調べてください：必要な情報と特別なプロセスはそこに文書化されているはずです。

通常、使用される数値は文書が承認されたときに IANA によって選択されます。ドラフトは最終値を指定すべきではありません。代わりに、「TBD1」や「TBD2」などのプレースホルダーを文書全体で一貫して使用し、登録される各項目に異なるプレースホルダーを付けます。IANA Considerations は、RFC エディタにプレースホルダー名を IANA が割り当てた値で置き換えるよう求める必要があります。ドラフトがテストまたは早期実装のために数値を指定する必要がある場合、早期割り当てを要求する（セクション 3.4 を参照）か、テストまたは実験用にすでに確保されている値を使用します（対象のレジストリが明示的な割り当てなしでそれを許可している場合）。IANA がその間にそれらの値の 1 つを別の文書に割り当てないように、ドラフトが独自の値を選択しないことが重要です。ドラフトは IANA Considerations セクションで特定の値を要求でき、IANA は可能な場合にそのような要求に対応しますが、提案された番号はドラフトが承認されるまでに他の用途に割り当てられている可能性があります。

通常、使用されるテキスト文字列値は文書で指定されます。テキスト文字列では衝突の可能性が低いためです。実際に衝突がある場合、IANA は著者と協議し、別の値を使用する必要があります。ドラフトがテストまたは早期実装のために文字列値を指定する必要がある場合、期待される最終値を使用することがあります。しかし、代わりにドラフト値を使用することがしばしば有用で、ドラフトバージョン番号を含めることもできます。これにより、早期実装と最終バージョンを実装しているものとを区別できます。たとえば、最終バージョンで「foobar」を使用する予定の文書は、ドラフトの -05 バージョンでは「foobar-testing-draft-05」を使用する可能性があります。

一部のレジストリでは、虚栄心または組織名ベースでの名前またはコードの割り当てを禁止する長年のポリシーがあります。たとえば、例外を作る強い理由がない限り、コードは常に順次割り当てられる場合があります。この文書の何もこれらのポリシーを変更したり、将来の適用を妨げることを意図したものではありません。

例として、次のテキストを使用して DHCPv6 オプション番号の割り当てを要求できます：

IANA は、DNS Recursive Name Server オプションにオプションコード値 TBD1 を、
Domain Search List オプションにオプションコード値 TBD2 を、
RFC 3315 のセクション 24.3 で定義されている DHCP オプションコード空間から
割り当てるよう求められます。

IANA Considerations セクションは、必要に応じて文書の他の場所の関連セクションへのポインタを含めて、すべての IANA アクションを要約する必要があります。参照文書が大きい場合、セクション番号を含めることは特に有用です。セクション番号により、参照文書を検索する人が関連情報を見つけやすくなります。

複数の値が要求される場合、追加/変更の要約表を含めることが一般的に役立ちます。この表が IANA のウェブサイトに表示される、または表示される形式と同じ形式であることも役立ちます。たとえば：

Value     Description          Reference
--------  -------------------  ---------
TBD1      Foobar               this RFC, Section 3.2
TBD2      Gumbo                this RFC, Section 3.3
TBD3      Banana               this RFC, Section 3.4

注：著者が変更の完全な表を含めることが冗長すぎる、または反復的すぎると感じる場合でも、著者はドラフトに表を含める必要がありますが、最終 RFC の公開前に表を削除するよう求めるメモを含めることができます。