Summary

  • プライマリIDNは評価上の依存関係の根であり、失格すれば関連バリアントもすべて失格する。
  • 個別バリアントの失格は、Application Change Requestで削除できればプライマリと失格していない残りのバリアントの継続を妨げない。

Root Zone Label Generation Rulesは単なる別表記の一覧ではない。プライマリ文字列のvariant-string-setを計算し、各バリアントにallocatableまたはblockedという管理対象の状態を割り当てる。申請できるのはallocatableバリアントであり、blockedバリアントは申請できない。プライマリは利用可能な集合と評価構造の両方を定める。

同じラウンドの新規IDNでは、プライマリと申請するallocatableバリアントを一つの申請に含める。評価に成功すれば、同一のレジストリ運営者に一つのRegistry Agreementで割り当てられる。一つの申請に入ることは、各文字列が独立していることを意味しない。

7.6.3節は依存の第一方向を示す。プライマリIDNが理由を問わず失格すると、関連するすべてのバリアントも失格し、申請全体が進めなくなる。バリアントがプライマリの失敗を救うことはない。

逆方向は限定的である。申請されたバリアントが失格した場合、申請者はApplication Change Requestを提出してそのバリアントを削除しなければならない。ACRが成功すれば、プライマリと失格していない残りのバリアントは継続できる。これは自動救済ではなく必須の手続きである。

提出時点で集合の外縁も固定される。提出後にACRで申請済みバリアントを撤回できるが、当初含めなかったallocatableバリアントは追加できない。また申請された各バリアントには、その意味、対象利用者コミュニティによる認知、もたらす便益、および便益を受けるコミュニティを扱う必要性の説明が必要である。

BTWはプライマリと各バリアントを別行にし、RZ-LGR状態、説明、評価結果、ACRを記録する依存台帳を勧める。これは編集上の助言でありICANN要件ではない。

Sources