メインコンテンツまでスキップ

4. 登録方針の選択と既知の方針

4. 登録方針の選択と既知の方針 (Choosing a Registration Policy and Well-Known Policies)​

登録方針 (registration policy) は、レジストリ (registry) 内の新しい割り当て (assignment) の受け入れ方法を制御する方針である。登録方針を定義する際には、いくつかの論点を考慮する必要がある。

レジストリの名前空間 (namespace) が限られている場合、枯渇を防ぐために割り当てを慎重に行う必要がある。

空間が実質的に無限であっても、割り当ての前に最低限のレビュー (review) を行うことがしばしば望ましい。その理由は次のとおりである。

  • 値の囲い込みや不必要な浪費を防ぐため。たとえば、空間が文字列で構成される場合、望ましい名前（既存の企業名など）に対応する大量の文字列を取得することを実体に防ぎたい場合がある。

  • 要求が実際に妥当で必要であるかの健全性チェック (sanity check) を提供するため。経験上、主題の専門家 (subject matter expert) による何らかの最低限のレビューは、要求が不正であるか実際には不要である場合（たとえば、実質的に同等のサービスに対する既存の割り当てがすでに存在する場合）の割り当てを防ぐのに有用である。

おそらく最も重要なのは、レビューなしの拡張が相互運用性 (interoperability) とセキュリティ (security) に影響しうることである。[RFC6709] を参照のこと。

名前空間が実質的に無限であり、相互運用性またはセキュリティ上の潜在的問題がない場合、割り当て番号 (assigned numbers) は通常、主観的なレビューなしに誰にでも付与できる。そのような場合、IANA (Internet Assigned Numbers Authority) に、どの種類の要求を認めるべきかについての詳細な指示が与えられ、主観的判断を行使せずにそうできるのであれば、IANA が直接割り当てを行うことができる。

そうでない場合は、何らかのレベルのレビューが必要である。ただし、適切なレビューと登録の容易さのバランスが重要である。多くの場合、登録を行う者は IETF 参加者ではない。要求は他の標準化団体から、標準化に直接関与しない組織から、オープンソース・プロジェクトなどのアドホックなコミュニティ活動から、など、さまざまなところから来る。登録が不必要に困難であったり、時間やその他のリソースの観点で不必要にコストが高かったり、不必要に拒否されやすくあってはならない。

（バイト内のビットなどの限られたリソースや、サポートされない値がプロトコル動作に有害になりうる項目などのために）何を登録するかを制限することが必要な場合もあるが、多くの場合、実際に使用されているものがレジストリに反映されていることの方が重要である。過度に厳しい審査基準と過度のコスト（時間と労力）は、人々が登録を試みることを妨げる。レジストリが実際に使用されているプロトコル要素を反映できない場合、インターネット上のプロトコルの展開に悪影響を与え、レジストリ自体の価値も下がる。

したがって、登録方針について具体的に考え、任意に選んだり他文書からテキストをコピーしたりしてはならない。ワークグループやその他の文書開発者は、文書がレジストリを作成するときに適切な登録方針を慎重に選ぶべきである。レジストリのニーズに合う最も緩い方針を選び、コミュニティの関与を大きく要する方針（既知の方針の用語でいえば、Expert Review（専門家レビュー）や Specification Required（仕様必須）より厳しいもの）については、具体的な正当化 (justification) を示すべきである。ここでのニーズはレジストリごとに異なり、実際には時間とともに変化する。この BCP (Best Current Practice) がこの主題についての最終的な言葉になるわけではない。

以下は一般的な用法のために定義された方針である。名前空間内の新しい値を割り当てる手順を記述するために用いられてきた典型的な方針の範囲をカバーする。文書がこれらの用語を使うことが厳密に必須というわけではない。実際の要件は、IANA への指示が明確で曖昧さがないことである。ただし、意味が広く理解されているため、これらの用語の使用は強く推奨される。これらのいずれも適さない場合は、これらの用語に関連する手順の要素を新しい方法で組み合わせたものを含め、新たに作った方針を用いてもよい。その場合、なぜそうなのかの説明があるとレビュー過程に役立つ。各用語は以下の各下位節で完全に説明される。

  1. Private Use（私用）
  2. Experimental Use（実験的使用）
  3. Hierarchical Allocation（階層的割り当て）
  4. First Come First Served（先着順）
  5. Expert Review（専門家レビュー）
  6. Specification Required（仕様必須）
  7. RFC Required（RFC 必須）
  8. IETF Review（IETF レビュー）
  9. Standards Action（標準アクション）
  10. IESG Approval（IESG 承認）

名前空間を複数のカテゴリに分割し、各カテゴリ内の割り当てを異なる方法で扱うことがしばしば合理的であることに注意されたい。多くのプロトコルは現在、名前空間を二つ以上の部分に分割し、一方の範囲を Private Use または Experimental Use に予約し、他方の範囲を何らかのレビュー手続きに従って割り当てられるグローバルに一意な割り当て用に予約している。名前空間を範囲に分割すると、異なる範囲と異なるユースケースに対して異なる方針を置くことができる。

同様に、状況ごとに異なる方針を用いる、複数の方針を並行して指定することがしばしば有用である。その主題に関するさらなる議論は、第 4.12 節を参照のこと。

複数の方針を並行して指定する RFC の例:

  • LDAP [RFC4520]
  • TLS ClientCertificateType Identifiers [RFC5246]（以下の各下位節で詳述）
  • MPLS Pseudowire Types Registry [RFC4446]
に最終更新