Skip to main content
Resources

NTIA の IANA 機能監督権限の移管

このページは以下の言語でもご覧いただけます。

提案の策定プロセスと今後の手続き [PDF, 948 KB]

提案の策定プロセスと今後の手続き

概要

2014年3月14日、米国商務省電気通信情報局(National Telecommunications and Information Administration:NTIA)は、IANA(Internet Assigned Numbers Authority:インターネット番号割当機関)機能の監督権限をグローバルマルチステークホルダーコミュニティに移管する意向を 発表しました。IANA機能の委託先であり、またDNS(Domain Name System)の世界的な調整の担い手でもあるICANN(Internet Corporation for Assigned Names and Numbers)に対して、NTIAはマルチステークホルダープロセスを招集し、移管に向けた提案を策定することを依頼しました。NTIAは、ステークホルダー、およびIANA機能の影響をもっとも直接的に受ける関係者に対して技術的詳細を検討することを期待する一方で、議論を導くのための明確な枠組みを確立し、移管の提案が広範なコミュニティの支持を受け、以下の4原則に対応する必要があることをICANNに伝えました。

  • マルチステークホルダーモデルを支持し、強化する
  • インターネットにおけるDNSのセキュリティ、安定性、回復力を維持する
  • IANAサービスに対する全世界のカスタマーおよびパートナーの要求と期待に対応する
  • インターネットのオープン性を維持する

NTIAは、NTIAの役割を政府主導または政府間機関による解決案に置き換える提案は受け入れないものとしています。

NTIAの発表直後から、ICANNは移管プロセスの原則とメカニズムに対するコミュニティの見識や意見を集めるため、マルチステークホルダープロセスおよび討議を開始しました。コミュニティからの最初のフィードバックに基づき、 NTIAのIANA機能監督権限の移管に関する提案を策定するための原則、メカニズム、およびプロセスの試案に対するパブリックコメントの募集が、4月8日に公開され、2014年5月8日までコメントが受け付けられました。また、プロセスの範囲を定義する スコーピング文書も公開されました。

試案に対して寄せられた 広範なコメントでは、プロセスが透明性を保ち、包含的かつ代表的であり、ボトムアップ型であり、マルチステークホルダーが関与すべきものであることが重視され、この点が継続的に強化されました。

この文書は、今後の手続きを定めるとともに、コミュニティの意見を総括します。

  • 調整グループ(それまで提案されていた「運営グループ」)の構成に関するコミュニティの意見の総括
  • 調整グループに参加するコミュニティメンバーに対する、それぞれの代表者を選出する内部プロセス開始の呼びかけ
  • 調整グループの作業に関連するトピックに対するコミュニティの意見の総括(必要に応じて検討および採用)

NTIAのIANA機能監督権限の移管について議論を進める中で、ICANNの説明責任に移管が及ぼす影響という、より広範なトピックについてもコミュニティが取り上げた点に留意する必要があります。コミュニティがNTIAの監督権限の移管について提案を策定する一方で、ICANNの説明責任という個別の問題にも対処することが重要です。その結果ICANNは、米国政府との間でこれまで契約関係を持たなかったICANNの説明責任を強化し、その役割に伴うICANN組織全体の説明責任に関する下支えとしての機能について検討するための、個別のプロセスを開始しました。これらのプロセスは相互依存の関係にあります(2つのプロセスの関係については、タイムラインの図を参照してください)。 ICANNの説明責任強化のプロセスは、2014年5月6日に公開されました。

アクション:調整グループの名称および結成の呼びかけ

  • 調整グループに代表されるコミュニティは、割り当てられた定員に応じて代表を選出する内部プロセスを開始することを求められます。
  • 被選出者の名前は、提出フォームにより2014年7月2日23時59分(UTC)までに通知しなければなりません。また、この情報はオンラインで公開されます。
  • コミュニティは、第50回ICANNロンドン会議(2014年6月22~26日)の終了までに最終的な選出を行うことが奨励されます。
  • 調整グループは、7月中旬(暫定的には7月16~18日)に会合を行って運営形態と作業方法を最終決定し、活動を開始します。
  • 完全な透明性を確保するため、調整グループは世界中のすべてのステークホルダーがアクセス可能な公開の会合を行い、関連する議事録および記録映像/音声をWebサイトで公開します。

意見の募集と今後の手続きについての総括

NTIAのIANA機能監督権限の移管について提案を策定するマルチステークホルダープロセスを招集する立場にあるICANNは、2014年4月8日~5月8日の期間中に、コミュニティにより提案された NTIAのIANA機能監督権限の移管について提案を策定するための原則、メカニズム、およびプロセスの試案について、一般の意見と対話を求めました。

試案は、原則、メカニズム、および提案されるプロセス(さらなる意見を求める上での論点、イベントのタイムラインなど)について、概要を示しています。さらに、プロセスの範囲を定義する スコーピング文書が公開されまました。

寄せられた多くのコメントには、世界中のマルチステークホルダーコミュニティの多様性に応じて広範な見解が反映されています。文書で寄せられたコメントの他に、コミュニティの対話もIANAの機能、DNSおよびプロトコルのレジストリに対する理解の推進に貢献しました。

調整グループの構成および見直された構成に焦点を当てるコメントや、ICANNがプロセスを招集し推進する立場として中立的な役割を果たすことを求めるコメントは、以下に示すように組み込まれました。

調整グループの役割と責任に関するコメントの総括は、調整グループと今後の活動についての意見として、 スコープに沿う形で提供されます。したがって、この文書は調整グループの役割と責任について規定するものではありません。運営形態や作業方法を定義していく過程での意見の採用は、調整グループの判断に委ねられます。スコープまたはICANNの説明責任に関するコメントは、ここには反映されません。スコーピング文書は、このプロセスの焦点について総括します。

プロセスにおける次の手続きは、調整グループの名称設定の呼びかけです。調整グループに代表されるコミュニティは、代表選出の内部プロセスを開始し、ロンドンで開催される第50回ICANN会議の終了までに選出を行うように促されています。被選出者の報告期限は、2014年7月2日23時59分(UTC)です。選出された候補者は、2014年7月中旬(暫定的には7月16~18日)に会合を行って運営形態と作業方法を最終決定し、活動を開始するものとします。ICANNは必要な施設とリソースを提供します。

調整グループは、IANA機能の影響を受けるさまざまな当事者の多様な要求に対応する移管の提案を準備する責任を担い、それぞれのコミュニティからのコンポーネントをNTIAが設定した基準を満たす単一の提案にまとめるものとします。つまり、広範なコミュニティの支持を得て、次の4原則に対応する必要があります。

  • マルチステークホルダーモデルを支持し、強化する
  • インターネットにおけるDNSのセキュリティ、安定性、回復力を維持する
  • IANAサービスに対する全世界のカスタマーおよびパートナーの要求と期待に対応する
  • インターネットのオープン性を維持する

NTIAは、NTIAの役割を政府主導または政府間機関による解決案に置き換える提案は受け入れないものとしています。

策定された提案について、ICANNは定義された枠組みと基準への順守を確認し、1) NTIAの原則の順守、2)コミュニティからの意見で示された原則への適合について判断します。提案の検討と受諾(必要に応じて)に対する責任は、NTIAにのみ委ねられています。プロセスが上記の要件を満たしているかどうかについてのICANNの評価は、提案とともに伝えられます。

調整グループの選出と構成

選出と構成について、当初の内容と修正後の内容については、付録Iの比較表を参照してください。

「運営グループ」から「調整グループ」への名称変更

「運営(steering)」という言葉がグループの機能を適切に表していないという懸念がコメントで多く寄せられたことを受けて、当初提案された「運営グループ(Steering Group)」から「調整グループ(Coordination Group)」へと名称が変更されました。

調整グループについて提案された選出メカニズムと構成の変更

調整グループの選出方法と構成については、コミュニティから多くの意見が寄せられました。コメントの大部分は、影響を受ける当事者と影響を受けない当事者からのメンバー選出でアプローチが異なり、矛盾があることを指摘し、より直接的な代表選出を求めるものです。すべてのコミュニティからメンバーを選出することについては、広い支持がありました。

これらの懸念に対応し、さらなる均衡をとるため、以下のように修正された選出メカニズムが変更に反映されています。

  • 影響を受ける当事者と影響を受けない当事者の区別を排除する
  • 内部プロセスにより調整グループの代表を選出する責任を、それぞれのコミュニティに割り当てる
  • ICANN理事会議長とGAC議長がグループメンバーを選出しない
  • コミュニティに対して、それぞれの選出プロセスを実施する過程で多様性の基準を順守するように強く促す

調整グループにおける代表に関して、IANA機能のカスタマーの代表、および技術団体、政府、市民団体、業界からの広範なユーザーコミュニティおよびステークホルダーの参加を求める多様なコメントが寄せられました。より広範な協議によりICANNや技術コミュニティ以外の当事者を含めることで、最大限の支持を世界中から得ることができるという意見が出されています。

構成の修正:

  • ICANNコミュニティにとどまらず、IANAのカスタマーやパートナーのインターネット組織も包含する
  • 国別コードトップレベルドメイン(ccTLD) およびトップレベルドメイン (TLD)レジストリからの代表を含む
  • GNSOの代表を増員させるように求めるコメントを反映する
  • IP番号管理コミュニティからの代表が過剰であるというコメントに対応し、アドレス支持組織(ASO)と番号資源組織(NRO)の均衡をとるように調整する
  • ICANNに関与していない、より広範で横断的な業界代表を含める
  • IANA機能に関するリソースとして、IANAの専任スタッフとしての専門家に割り当てられているリエゾンの定員を充てる
  • ICANN以外のユーザーコミュニティの代表を保持する

調整グループの構成

調整グループは、それぞれのコミュニティおよびプロセスから選出された27名のメンバーから構成されることになります。多様性の基準を順守し、利益の対立を回避する配慮が求められます。

調整グループの構成(図を参照):

調整グループの構成

代表されるコミュニティ

定員

At-Large諮問委員会(ALAC

2

アドレス支持組織(ASO

1

国コードドメイン名支持組織(ccNSO、およびccNSOが選んだ非ccNSOの国コードトップレベルドメイン[ccTLD]事業者)

4

ジェネリックドメイン名支持組織(GNSO)。GNSOの定員は非レジストリからの代表。

3

ジェネリックトップレベルドメイン(gTLD)レジストリ

2

政府諮問委員会(GAC

2

国際商業会議所/情報化社会支援ビジネスアクション(ICC/BASIS

1

インターネットアーキテクチャ委員会(IAB

2

インターネット技術タスクフォース(IETF

2

インターネット協会(ISOC

2

番号資源組織(NRO

2

ルートサーバシステム諮問委員会(RSSAC

2

セキュリティと安定性に関する諮問委員会(SSAC

2

合計

27

調整グループに対して2名のリエゾンが置かれます。

  • ICANN理事会のリエゾン1名(ICANNの招集の役割)
  • IANAの専任スタッフとしての専門家(必要に応じて情報を提供)

上記のほかに、以下の意見が寄せられました。

サポートサービス

調整グループは、小規模の独立する事務局(ICANNが資金供給し、オープンプロセスにより選出)による支援を受けることができます。事務局は、運営および後方支援を行い、コミュニティからの提案収集と取りまとめを行います。

エンゲージメントとアウトリーチ

エンゲージメントとアウトリーチの活動は、それぞれの組織の間のパートナーシップにより世界中で推進されます。 イベントのタイムラインは、イベントの範囲を例で示しています。活動を網羅するものではありません。調整グループとそれぞれの組織はエンゲージメント戦略を策定する過程で、完全なアウトリーチとエンゲージメントを保証するように努めなければなりません。

予算

完全な透明性を保証するために、公開されアクセス可能な予算の確立を求める意見が寄せられました。

移動支援

調整グループメンバーに報酬が支払われることはありません。ただし、調整グループ会議に参加する調整グループメンバー向けの移動、食事と宿泊の費用は、要請に応じて、ICANN のコミュニティ移動支援ガイドラインに従い ICANN により負担されます。

支援される旅行者は、その費用を直接 ICANN に請求する ICANN の承認旅行代理店によりそれぞれの航空券を予約する必要があります。指定された会議に関するホテルルームおよび税金は、支援される旅行者に関する承認済みの到着および出発の日付に従い ICANN により手配され、直接支払われます。ICANN は払戻不可の、最低の規定航空料金、およびエコノミー料金に関してのみ予約を行い、それを支払います。払い戻しは会議参加者および派生するその他の妥当な雑費の支出に関して許可されます。

質問について、または必要な旅行手配を行うには、cgtravel@icann.orgに連絡してください。

原則とメカニズム、および調整グループの責任に関して寄せられた意見の総括

上記の意見の他に、原則とメカニズム、および調整グループの責任に関して、広範な意見が寄せられました。これらについては、調整グループに関する意見として以下に紹介します。当初のプロセスと修正後のプロセスの主要な変更内容は、付録Iの比較表に示します。 原則とメカニズム

原則とメカニズムの草案には、オープン性、包含性、透明性、説明責任を保ち、ボトムアップで実施されるプロセスを保証するための適切な特性がまとめられているという総意がありました。多様性の原則は、これがプロセスの正当性をさらに高めるという意見に応えて、リストに追加されました。これは、移管の世界的規模での実施、およびマルチステークホルダーモデルの価値に一致します。新規に追加されたメカニズムはありません。

原則

メカニズム

  • 包含的
  • 透明性
  • グローバル
  • 説明責任
  • マルチステークホルダー
  • 対象の絞り込み
  • 実際および実証ベース
  • すべての意見に耳を傾ける
  • 害を与えない(セキュリティ、安定性、および回復力の保持)
  • 総意に基づく
  • 多様性
  • Webベースのプラットフォーム
  • 作業方法
  • 組織的な対話
  • 既存の情報とプロセス
  • ストレステスト
  • 明確で可視的なタイムライン
  • 他のフォーラムでの討議
  • 広くアクセス可能なエンゲージメントプラットフォーム
  • 多言語対応
  • 意見を表明できる複数のフォーラム

独立した事務局

一部のコメントでは、ICANN以外のスタッフによる独立した事務局が調整グループを支援することの重要性が強調されました。独立した事務局(ICANNが資金供給)は、必要に応じて管理などの支援を提供します。ICANNは招集者として、プロセスの推進において中立的な立場を保持します。

調整グループの役割と責任に関するコミュニティの提案

前述のように、グループの役割と責任に関連するコメントへの対応はとられませんでした。以下に示すコミュニティからの提案については、検討と採用が調整グループの判断に委ねられています。このリストは、すべての提案を網羅するものではありません。

  • プロセスの原則とメカニズムを基盤として、コミュニティが推進する提案の策定に向けたプロセスを確立する
  • この移管に関連する重要課題の討議と理解のために、コミュニティの内部、およびコミュニティを横断する形で適切に構成された、広範で多様な作業グループを奨励して推進する
  • メンバー自身のコミュニティとその中での合意を、調整グループの他のメンバーに反映する
  • 重複する各領域(特殊用途の各レジストリなど)について、移管の提案を策定するコミュニティを調整し、これらの領域がコミュニティを横断する審査を受けるように保証する
  • それぞれのコミュニティ内で提案を全面的に支持する
  • IANAの各カスタマーのコミュニティにおける移管提案のコンポーネント策定について、進捗状況の情報を定期的に更新する
  • 合意による運営形態を採用し、反対意見を記録する
  • アウトリーチとエンゲージメントを実施する
  • 利害の対立を回避し、調整グループの適切な説明責任を保証する

コミュニティに寄せられた質問に関連して、以下の概要を参考にしてください。

Q1.IANA機能に対する監督権限のグローバルなマルチステークホルダーコミュニティへの移管において、これらの原則は提案策定プロセスを主導する上で適切でしょうか。適切でない場合は、どのような理由からでしょうか。また、他にどのような原則について検討すべきでしょうか。

提案された原則は、寄せられたコメントで支持されました。ただし、追加の原則が提案され、「多様性」を重視すべきであると求められました。これらのコメントを受けて、プロセスの指針となる原則のリストに「多様性」が追加されました。

Q2.IANA機能に対する監督権限のグローバルなマルチステークホルダーコミュニティへの移管において、これらのメカニズムは提案策定プロセスで使用する上で適切でしょうか。適切でない場合は、どのような理由からでしょうか。また、他にどのようなメカニズムについて検討すべきでしょうか。

提案されたメカニズムは、寄せられたコメントで広く支持されました。

Q3.IANA機能に対する監督権限のグローバルなマルチステークホルダーコミュニティへの移管における提案策定の原則とメカニズムに関連して、ICANNがプロセス招集者として考慮すべき要因は他にありますか。あるとすれば、どのようなものですか。

ICANNは中立的な役割を保持すべきであるという意見が寄せられました。

Q4.IANA機能に対する監督権限のグローバルなマルチステークホルダーコミュニティへの移管において、提案策定プロセスの世話役として運営グループを設置するのは、適切なアプローチでしょうか。適切でない場合、他にどのようなアプローチをとるできでしょうか。

運営グループを設置するという案については、支持するコメントが寄せられました。ただし、名称と構成の変更が求められました。寄せられたコメントを受けて、次のような変更が実施されました。

  • グループに期待される役割と目的をより的確に反映するため、「運営グループ」という名称が「調整グループ」に変更されました。
  • 関係当事者間の分類上の区別を支持する合意が得られなかったため、このような区分が排除されました。
  • グループの構成は、前述のように変更されました。
  • 代表選出プロセスは、コミュニティ主導の選出プロセスを求めるコメントが寄せられたことから、コミュニティメンバーによる選出を可能とするように見直されました。多様性に関して寄せられたコメントを反映するために、多様性の基準が強化されました。

Q5.IANA機能に対する監督権限のグローバルなマルチステークホルダーコミュニティへの移管において、提案策定プロセスの世話役として運営グループを設置して運営するための前述の手続きは、適切なアプローチでしょうか。適切でない場合、欠けているのはどのような手続きでしょうか。

寄せられたコメントでは、合意による運営が必要であると示された一方で、反対意見の文書化も求められました。

Q6.IANA機能に対する監督権限のグローバルなマルチステークホルダーコミュニティへの移管において、提案策定プロセスの世話役として運営グループを設置することに関連して、ICANNがプロセス招集者として考慮すべき要因は他にありますか。あるとすれば、どのようなものですか。

ICANN以外の独立した事務局の設置を求めるコメントが寄せられました。これらのコメントを受けて、ICANNが資金供給する独立事務局の設置が提案で強調されています。

タイムライン

Transition Timeline

調整グループの構成

付録I

分類

当初の提案

修正後の提案

(調整グループに関するコミュニティの意見を含む)

名称

運営グループ

調整グループ

原則とメカニズム

  • 包含的
  • 透明性
  • グローバル
  • 説明責任
  • マルチステークホルダー
  • 対象の絞り込み
  • 実際および実証ベース
  • すべての意見に耳を傾ける
  • 害を与えない
  • 総意に基づく
  • 「多様性」が原則のリストに追加されました。
  • 「害を与えない」には、さらに「(セキュリティ、安定性、および回復力の保持)」が追加されました。

構成

  1. SO/ACと関係当事者の区別
  2. 定員22名とリエゾン1名
  3. 2 ALAC
  4. 2 GAC
  5. 2 RSSAC
  6. 2 SSAC
  7. 2 GNSO
  8. 2 ASO
  9. 2 IETF
  10. 2 IAB
  11. 2 NRO
  12. 2 ISOC
  13. 2 ccNSO
  14. N/A
  15. N/A
  16. ICANN理事会のリエゾン1名
  17. N/A
  1. 区別なし
  2. 定員27名、リエゾン1名、専門家1名
  3. 2 ALAC
  4. 2 GAC
  5. 2 RSSAC
  6. 2 SSAC
  7. 3 GNSO(非レジストリからの代表)
  8. 1 ASO
  9. 2 IETF
  10. 2 IAB
  11. 2 NRO
  12. 2 ISOC
  13. 4 ccNSOおよび非ccNSOのccTLD事業者
  14. 2 gTLDレジストリ
  15. 1 ICC/BASIS
  16. ICANN理事会のリエゾ
    ン1名
  17. IANAの専任スタッフとしての専門家1名(必要に応じて情報を提供).

選出

ICANN理事会議長とGAC議長が「影響を受けない当事者」としてのグループメンバーを選出。

各コミュニティが代表を選出。

運営形態

合意に基づく

合意に基づき、反対意見を記録

サポート

ICANN事務局

調整グループは、独立する事務局(ICANNが資金供給し、オープンプロセスにより選出)による支援を受けることができます。事務局は、運営および後方支援を行い、コミュニティからの提案収集と取りまとめを行います。さらに、調整グループの求めに応じて他のサービスを提供できます。

カレンダー

a. プロセスに関連するタイムラインのイベント。

b. 調整グループを第50回ICANN会議までに結成。

a. 参加型カレンダー(コミュニティが特定イベントに参加できます)。

b. 非選出者の報告期限は、2014年7月2日23時59分(UTC)です。調整グループは、7月中旬(暫定的には7月16~18日)に会合を行って運営形態と作業方法を最終決定し、活動を開始します。

役割

運営グループの役割は、プロセスの適切な推進を調整および保証することです。関連する関係当事者は、それぞれのコミュニティのプロセスを主導して、必要に応じてメカニズムを決定します。ただし、その結果については、提案されたメカニズム全体に適合するように、運営グループが調整します。

調整グループは、コミュニティ主導の提案策定プロセスも確立します。

調整グループが決定します。このトピックに関するフィードバックは、意見として提供されます。

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."