4.11. 既知の登録ポリシーの使用

既知のポリシーはコミュニティの経験と広範な理解から恩恵を受けているため、その使用が奨励されており、新しいポリシーの作成には合理的な正当化を伴う必要があります。

1つ以上の既知のポリシーを引用し、審査プロセスでどのような考慮事項を考慮すべきかについての追加のガイドラインを含めることも許容されます。

例えば、メディアタイプの登録 [RFC6838] では、IETF Review と Specification Required の使用を含む多くの異なる状況がカバーされており、指定された専門家が従うべき特定の追加基準も含まれています。これは登録手順を表すことを意図したものではなく、特別な状況をカバーする必要がある場合に何ができるかの例を示すものです。

「First Come First Served」から「Standards Action」までの既知のポリシーは、厳格さが増す順序で一連のポリシーを指定しています（第4節の完全なリストの番号を使用）：

4. First Come First Served（先着順）

• 審査なし、最小限の文書。

5 と 6（同等の厳格さ）

• 5. Expert Review（専門家審査）：審査のための十分な文書を伴う専門家審査。
• 6. Specification Required（仕様必須）：相互運用性のための十分な安定した公開文書。

7. RFC Required（RFC 必須）

• 任意の RFC 発行、IETF または非 IETF ストリーム。

8. IETF Review（IETF 審査）

• RFC 発行、IETF ストリームのみ、ただし Standards Track である必要はない。

9. Standards Action（標準アクション）

• RFC 発行、IETF ストリーム、Standards Track または BCP のみ。

IETF Review または Standards Action が必要となる可能性のある状況の例には、以下が含まれます：

• リソースが限られている場合、例えば1バイト（または2バイト、または4バイト）のビット、または限られた範囲の数値。これらの場合、慎重に審査されずコミュニティの合意が得られていない登録を許可すると、許容される値があまりにも早く枯渇する可能性があります。

• 徹底的なコミュニティ審査が必要な場合、損害を与える可能性のある方法でプロトコルを拡張または変更することを避けるため。1つの例は、既存のコマンドコードを使用するオプションとは対照的に、新しいコマンドコードを定義することです：前者は厳格なポリシーが必要かもしれませんが、後者にはより緩和されたポリシーで十分かもしれません。別の例は、既存の操作のセマンティクスを変更するプロトコル要素を定義することです。

• リソースに関してセキュリティへの影響がある場合、新しい使用法が健全であることを確認するために徹底的な審査が必要です。この例には、許容されるハッシュアルゴリズムと暗号化アルゴリズムのリスト、およびシステム範囲内のトランスポートポートの割り当てが含まれます。

IANA に新しいレジストリの作成を要求する文書、または登録ポリシーを Expert Review または Specification Required よりも厳格なポリシーに変更する文書を審査する場合、IESG は、より緩和されたポリシーが検討されており、より厳格なポリシーが正しい選択であることを確認するために正当化を求めるべきです。

したがって、文書開発者は、これを予測し、指定されたポリシーを選択するための考慮事項を文書化する必要があります（理想的には文書自体に；それができない場合は、シェパードのライトアップに）。同様に、文書シェパードは、文書を IESG に送信する前に、選択されたポリシーが正当化されていることを確認する必要があります。

仕様が改訂される場合、登録ポリシーは、ポリシーが設定されてからの経験に照らして見直されるべきです。