Skip to main content
Resources

قرارات المجلس المعتمدة | الاجتماع العادي لمجلس إدارة ICANN

هذه الصفحة متوفرة باللغات:

تمت ترجمة هذه الوثيقة إلى العديد من اللغات بغرض المعلومات فقط. ويمكن العثور على النص الأصلي والموثوق (بالإنجليزية) من: http://www.icann.org/en/groups/board/documents/resolutions-07feb14-en.htm

 

  1. جدول أعمال الموافقة
    1. الموافقة على محضر اجتماع مجلس الإدارة
    2. تعيين جو آبلي في اللجنة الاستشارية للأمن والاستقرار
    3. مراجعة اللوائح الداخلية لمجموعة الارتباط التقنية
    4. عضوية لجنة برنامجgTLD الجديدة
  2. جدول الأعمال الرئيسي
    1. حماية معرفاتIGO-INGO في جميع عمليات وضع سياسةgTLDs
    2. تشكيل مجموعة عمل لمجلس الإدارةحول عملية الاختيار والتعيين للجنة الترشيح والحجم والتركيب
    3. توصيات عملية وضع سياسةGNSO لـWhois المكثف

 

  1. جدول أعمال الموافقة:

    1. الموافقة على محضر اجتماع مجلس الإدارة

      تقرر بموجب القرار رقم (2014.02.07.01)، موافقة مجلس الإدارة على محاضر جلسات اجتماعات مجلس إدارة ICANN المنعقدة في 8 و16 و17 و20 و21 نوفمبر.

    2. تعيين جو آبلي في اللجنة الاستشارية للأمن والاستقرار

      حيث أنه، تقوم اللجنة الاستشارية للأمن والاستقرار (SSAC) بمراجعة عضويتها وإدخال التعديلات عليها بين الحين والآخر.

      حيث أنه، طالبت لجنة عضوية SSAC، وبالنيابة عن SSAC، أن يقوم مجلس الإدارة بتعيين جو آبلي فيها.

      تقرر بموجب القرار (2014.02.07.02) أن يقوم مجلس الإدارة بتعيين جو آبلي في SSAC.

      حيثيات القرار 2014.02.07.02

      SSAC هي مجموعة متنوعة من الأفراد الذين مكنوا SSAC بخبرتهم في بعض المسائل المعينة من الوفاء بميثاقها التأسيسي وتنفيذ مهمتها. وقد استعانت اللجنة منذ تأسيسها بأفراد ذوي معرفة وخبرة هائلتين في المجالات الفنية والأمنية التي تعتبر حيوية لأمن واستقرار نظام اسم النطاق الخاص بالإنترنت

      يشار إلى أن هذا القرار هو من الاختصاصات الإدارية التنظيمية التي لا تتطلب إجراء تعليقات عامة.

      واستمر عمل اللجنة كهيئة منافسة تعتمد على خبراء معنيين بمادة البحث وافقوا على تقديم وقتهم ونشاطهم تطوعاً لتنفيذ مهمة اللجنة. يشارك جو آبلي في SSAC كجزء من دوره كمدير لعمليات DNS في ICANN. وانضم الآن إلىDyn  كمهندس رئيسي. سيضفي جو آبلي خبرة فيما يتعلق بعمليات DNS وعمقاً تقنياً كبيراً للفهم فيما يتعلق بـDNS والمسائل المرتبطة بها في SSAC.

    3. مراجعة اللوائح الداخلية لمجموعة الارتباط التقنية

      حيث أنه، تتطلب لوائح ICANN الداخلية من مجموعة الارتباط التقنية (TLG) تعيين منسق لا يحق له التصويت في مجلس إدارة ICANN، بالإضافة إلى موفد يحق له التصويت في لجنة الترشيح (NomCom).

      حيث أنه، تحدد اللوائح الداخلية مجالات المسؤولية للهيئات التي تؤلف TLG، بما في ذلك تعيين الخبراء الذين يمكن أن يطلب مجلس إدارة ICANN منهم المشورة حول الأمور المعنية، لم يتم تعيين هؤلاء الخبراء.

      حيث انه، في عام 2011، أجرت ICANN مراجعة لـTLG  حددت أن ثمة حاجة إلى التركيز لوضع آليات فعالة لتزويد مجلس الإدارة بالمشورة التقنية التي قد يحتاج إليها، مع التنويه أن الشكل الحالي من عمليات TLG لم يحقق هذا الهدف.

      حيث أنه، تهدف مراجعات اللوائح الداخلية المقترحة إلى السماح للهيئات الكفؤة في TLG بتركيز طاقاتها على وظائفها الاستشارية.

      حيث أنه، بموجب القرار رقم 2013.09.28.15، طلب مجلس الإدارة من رئيس مجلس إدارة ICANN، بالتنسيق مع الرئيس والمدير التنفيذي، مباشرة الاتصالات مع الهيئات الكفؤة في TLG لتسهيل تحديدها للخبراء لتحقيق المادة 11-أ، القسم 2، الفقرة 6 من لوائح ICANN الداخلية والتقوية الناتجة لآلية TLG الاستشارية.

      حيث أنه، بموجب القرار رقم 2013.09.28.16، طلب مجلس الإدارة من الرئيس والمدير التنفيذي النشر لإبداء التعليقات العامة المراجعات المقترحة على اللوائح الداخلية المرتبطة بارتباط TLG مع مجلس الإدارة وتعيين عضو لا يحق له التصويت في لجنة الترشيح.

      حيث أنه، تم نشر التعديلات المقترحة لإبداء التعليقات العامة في 30 أكتوبر 2013.

      حيث أنه، قدم طاقم الإدارة إلى مجلس الإدارة ملخص وتحليل بالتعليقات العامة المستلمة.

      حيث أنه، راجع مجلس الإدارة ونظر بالملخص والتحليل للتعليقات العامة وقرر أن مراجعات اللوائح الداخلية الملحقة بالمواد المرجعية في الملحقات أ، تتناول المسائل التي تمت مناقشتها أعلاه.

      تقرر بموجب القرار رقم (2013.02.07.03)، يوافق مجلس الإدارة على مراجعات اللوائح الداخلية كما تم نشرها لإبداء التعليقات العامة على http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm، شريطة إجراء تغييرين اثنين غير جوهريين تم إجراؤهما للتوضيح فقط.

      حيثيات القرار 2014.02.07.03

      خلفية حولTLG

      مجموعة الارتباط التقنية (TLG) هي إحدى الآليات الاستشارية المحددة في لوائح ICANN الداخلية. إحدى الوظائف الرئيسية لهيئات التي يفترض بـTLG القيام بها هي تحديد وتعيين خبراء يمكن لـICANN طرح أسئلة تقنية عليهم. حتى تاريخه، لم يتم تعيين أولئك الخبراء. تتألف TLG من أربعة منظمات: (i) معهد المعايير الأوروبية للاتصالات السلكية واللاسلكية (ETSI)، و(ii) قطاع توحيد الاتصالات لاتحاد الاتصالات الدولية (ITU-T)، و(iii) واتحاد شبكة الويب العالمية (W 3C)، و(iv) مجلس هندسة الإنترنت (IAB). ركزت TLG جهودها على التعيين السنوي لمنسق في مجلس إدارة ICANN، وموفد يحق له التصويت في لجنة الترشيح (NomCom) التابعة لـICANN. إن الحاجة إلى تغيير محور تركيز TLG هي موضوع نقاش في ICANN، كما هومبين في المراجعة التنظيمية لـTLG التي أجرتها ICANN في عام 2010 (المتوفرة على http://www.icann.org/en/groups/reviews/tlg.، والتي أدت إلىتوصيات بتغيير هيكلة TLG.

      لماذا يناقش مجلس الإدارة هذه القضية الآن؟

      يراجع مجلس إدارة ICANN مؤخراً السؤال الأساسي حول كيفية حصوله على المشورة التي يحتاج إليها. إحدى القيم الجوهرية لهذا العمل هي مناقشة كيفية تلقي مجلس الإدارة للمشورة التي يحتاج إليها، وكيفية متابعة المشورة الناتجة عن آليات ICANN الاستشارية بشكل أفضل. إن المشورة حول المسائل التقنية هي إحدى المجالات الرئيسية بينما لا تلبي الآلية الاستشارية الحالية لـTLG احتياجات مجلس الإدارة أو المهمة كما هي مبينة في اللوائح الداخلية. إن إجراء مجلس الإدارة اليوم، الذي يتناول كيفية تحسين الوظيفة الاستشارية في TLG، هو جزء من تركيز مجلس الإدارة المتجدد على تنظيم وتقوية أنشطته.

      ما هو الاقتراح الذي يتم النظر فيه؟

      الإجراء الذي يتم النظر به اليوم هو تبني مراجعات اللوائح الداخلية المرتبطة بـTLG التي تم نشرها لإبداء التعليقات العامة. تأثير هذه المراجعات هو إيقاف تعيين TLG لمنسق في مجلس إدارة ICANN، بالإضافة إلى تعيين TLG لموفد يحق له التصويت في NomCom التابعة لـICANN. إن إيقاف واجبات التعيين هذه سيسمح لهيئات TLG بتركيز اهتمامها على تقديم المشورة إلى ICANN، مقارنة مع تعيين أشخاص لا يمتلكون التفويض لتمثيل تنوع آراء الهيئات ضمن TLG. بدلاً من تركيز جهودها على تعيين منسق في مجلس الإدارة أو موفد NomCom، ستظل المهمة الرئيسية المتبقية لكل هيئة TLG هي التركيز على تعيين خبراء يمكن لمجلس الإدارة طلب المشورة منهم.

      لا يوفر دور المنسق هذا الولوج العالمي الأكبر للخبرة، حيث يتم تناوب دور منسق TLG على أساس سنوي، ولا يتمكن منسق واحد من توفير منصب منسق يمثل جميع هيئات TLG.

      لا تمثل مراجعات اللوائح الداخلية أي تغيير على دور TLG، وهو "توفير المعلومات التقنية والإرشادات إلى مجلس الإدارة وهيئات ICANN الأخرى". كما لن يتم إجراء أي تغيير على الهيئات الأربعة لـTLG. يهدف الإجراء المقترح إلى تبسيط دور هيئات TLG بتوقع ارتقاء وتعزيز تقديم هذه الهيئات للمشورة التقنية إلى مجلس الإدارة.

      من تمت مشاورته من أصحاب المصلحة أو غيرهم؟

      في 30 أكتوبر 2013، باشرت ICANN تعليقات عامة حول المراجعات المقترحة على اللوائح الداخلية. (راجع http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm.) تم إغلاق منتدى التعليقات العامة في 20 ديسمبر 2013. راجع مجلس الإدارة التعليق الوحيد المستلم عند تبني هذا القرار.

      ما هي المخاوف أو القضايا التي أثارها المجتمع؟

      تلقت ICANN رداً جوهرياً واحداً على مدار منتدى التعليقات العامة. أعرب المعلق عن تأييده لنية زيادة توفر المشورة التقنية إلى مجلس الإدارة وفعالية TLG. أوصى المعلق بعدم القيام بإلغاء منسق TLG قبل وضع آلية لطلب المشورة المنتظمة من TLG على الأقل. عارض المعلق إلغاء مفوض TLG في NomCom على أساس أن هذا الإلغاء قد يعيق تواصل مجتمع NomCom مع المجتمعات التقنية. (راجع http://forum.icann.org/lists/comments-bylaws-amend-tlg-30oct13/msg00002.html.)

      فيما يتعلق بتقوية آلية TLG الاستشارية، نوه مجلس الإدارة أنه تم تناول هذه المسالة بالفعل من قبل مجلس الإدارة في 28 سبتمبر 2013 في القرار رقم 2013.09.28.15.

      فيما يتعلق بالمخاوف المرتبطة بالتواصل مع المجتمعات التقنية، نوه مجلس الإدارة بأن كلٍ من المنظمات الأربعة التي تشكل TLG شاركت بالفعل في جهود التواصل المجتمعية الجارية. إن إلغاء موفد TLG في NomCom لا يمنع هذه المنظمات من مواصلة جهودها للتواصل.

      من المتوقع أن يكون لهذا القرار أثر مالي إيجابي على ICANN. إن إلغاء المنسق في مجلس الإدارة وNomCom سيحقق توفيرات مالية على ICANN.1 بالإضافة إلى ذلك، فإن الارتقاء وتعزيز كيفية تلقي ICANN للمشورة حول المسائل التقنية قد يكون له تأثير إيجابي على كيفية تناول ICANN للمسائل المرتبطة بأمن واستقرار ومرونة DNS.

      تم نشر المراجعات المحتملة على اللوائح الداخلية لإبداء التعليقات العامة على http://www.icann.org/en/news/public-comment/bylaws-amend-tlg-30oct13-en.htm من 30 أكتوبر 2013 إلى 20 ديسمبر 2013. تتضمن اللوائح الداخلية التي تم تبنيها تغييرين اثنين غير جوهريين في المادة 11، القسم 2.5 تم إجراؤهما لأغراض التوضيح، ولا يحتاجان إلى مزيد من التعليقات العامة.

      يشار إلى أن هذا القرار هو من الاختصاصات الإدارية التنظيمية التي خضعت بالفعل للتعليقات العامة.

    4. عضوية لجنة برنامجgTLD الجديدة

      حيث أنه، في 10 أبريل 2012، أنشأ مجلس الإدارة لجنة برنامج gTLD الجديدة، والتي تم تفويضها بجميع السلطات القانونية وسلطة اتخاذ القرارات لمجلس الإدارة المرتبطة ببرنامج gTLD الجديد كما هو مبين في الميثاق، باستثناء الأمور التي من المحظور على مجلس الإدارة تفويضها بموجب القانون، أو وفقاً للمادة 12، القسم 2 من لوائح ICANN الداخلية.

      حيث أنه، قررت اللجنة الفرعية للنزاعات والأخلاقيات حول gTLDs الجديدة التابعة للجنة حوكمة مجلس الإدارة أن ستيف كروكير لم يعد لديه تضارب مصالح فيما يتعلق ببرنامج gTLD الجديد، وقبل مجلس الإدارة هذا القرار.

      تقرر بموجب القرار رقم (2014.02.07.04)، تعيين ستيف كروكير كعضو يحق له التصويت في لجنة برنامجgTLD الجديدة (NGPC). أصبحت العضوية الجديدة في NGPC كمايلي:

      • تشيرين شلبي (الرئيس)
      • فادي شحاده
      • ستيف كروكير
      • كريس ديسبين
      • هيثر درايدن (مسؤول الاتصال)
      • بيل غراهام
      • برونو لانفين
      • أولجا مادروجا فورتي
      • إيريكا مان
      • غونزالو نافارو
      • راي بلزاك
      • جورج سادوسكي
      • مايك سيلبر
      • جون سونيون (مسؤول الاتصال)
      • كيو واي وو

      حيثيات القرار 2014.02.07.04

      يؤكد مجلس الإدارة مجدداً على حيثيات القرارين 2012.04.10.01 – 2012.04.10.04، واللذين ينصان بالكامل على ما يلي: من أجل عقد اجتماعات فعالة واتخاذ الإجراءات المناسبة فيما يتعلق ببرنامج gTLD الجديد للجولة الحالية من البرنامج ووفقًا لدليل مقدم الطلب، قرر مجلس الإدارة تشكيل "لجنة برنامجgTLD الجديدة" وفقاً للمادة 12 من اللوائح الداخلية وفوض سلطة اتخاذ القرار إلى اللجنة فيما يتعلق ببرنامجgTLD الجديد للجولة الحالية من البرنامج التي بدأت في يناير 2012، ولدليل مقدم الطلب ذي الصلة الذي يسري على هذه الجولة الحالية.

      إن تأسيس لجنة برنامجgTLD الجديدة (NGPC) من دون أعضاء ذوي مصلحة متضاربة، ومنحها تفويض بسلطة اتخاذ القرارات، قد وفر بعض المزايا المهمة، بما في ذلك المساعدة على التخلص من أي شك بسبب تضارب مصلحة أعضاء مجلس الإدارة فيما يتعلق بالمشاركة في اجتماعات مجلس الإدارة وورش عملها بما أنه يمكن التعامل مع مواضيع برنامج gTLD الجديد على مستوى اللجنة. بالإضافة إلى ذلك، فقد وفرت للمجتمع رؤيا واضحة حول التزام مجلس الإدارة بالتعامل مع حالات التعارض، سواء كانت فعلية أو محتملة أو متصورة.

      قامت اللجنة الفرعية للنزاعات والأخلاقيات حول gTLDs الجديدة التابعة للجنة حوكمة مجلس الإدارة (BGC) بتقييم جميع بيانات المصلحة لأعضاء مجلس الإدارة المرتبطة بـgTLDs عند تحديد عضوية NGPC لأول مرة. تواصل اللجنة الفرعية مراجعة بيانات مصلحة أعضاء مجلس الإدارة المرتبطة بـgTLD الجديدة وأية تغييرات على بيانات المصلحة السابقة لأغراض تحديد ما إذا كان أي عضو في مجلس الإدارة (بما في ذلك المدراء المصوتين والمنسقين غير المصوتين) لديهم أي تضارب مصالح فعلي أو محتمل أو متصور يمنعهم من العضوية في NGPC.

      عندما قامت اللجنة الفرعية بتقييم بيانات المصالح لأول مرة، تم تحديد وجود تضارب مصالح لدى ستيف كروكير. أبلغ الدكتور كروكير مؤخراً عن بعض التغييرات على بيانه للمصلحة المرتبطة بـgTLDs الجديدة، وقامت اللجنة الفرعية بتقييم هذه التغييرات بشكل شامل. قررت اللجنة الفرعية أنه لم يعد ثمة تضارب مصالح بشكل عام لستيف كروكير فيما يتعلق بـgTLDs الجديدة. بالتالي، أوصت اللجنة الفرعية بتعيين الدكتور كروكير كعضو يحق له التصويت في NGPC. يوافق مجلس الإدارة على ذلك.

      ينبغي أن يكون لهذا القرار تأثير إيجابي على المجتمع وICANN ككل، وجزء من السبب هو حقيقة زيادة عدد أعضاء مجلس الإدارة المشاركين في القرارات المحيطة ببرنامج gTLD الجديد.

      ولا يتوقع أي يكون لهذا الإجراء أي تأثير من الناحية المالية أو على أمن أو استقرار أو مرونة نظام أسماء النطاقات.

      يشار إلى أن هذا القرار هو من الاختصاصات الإدارية التنظيمية التي لا تتطلب إجراء تعليقات عامة.

  2. جدول الأعمال الرئيسي:

    1. حماية معرفاتIGO-INGO في جميع عمليات وضع سياسةgTLDs

      حيث أنه، في 17 أكتوبر 2012، بدأ مجلس GNSO عملية وضع سياسة (PDP) حول حماية معرفات IGO-INGO في جميع gTLDs تناقش المسائل المبينة في ميثاق مجموعة عمل عملية وضع السياسة على http://gnso.icann.org/en/issues/igo-ingo-charter-15nov12-en.pdf. [PDF، 189 كيلوبايت]

      حيث أنه، اتبعت عملية وضع السياسة خطوات عملية وضع السياسة المنصوص عليها في لوائح ICANN الداخلية ودليل عملية وضع السياسة لـGNSO، الأمر الذي نتج عنه تقرير نهائي تم تسليمه إلى مجلس GNSO بتاريخ 10 نوفمبر 2013.

      حيث أن، توصلت مجموعة عمل حماية معرفات IGO-INGO في جميع gTLDs (أوIGO-INGO WG) إلى إجماع على خمسة وعشرين نوصية تتعلق بالمسائل المبينة في ميثاقها.

      حيث أنه، راجع مجلس GNSO وناقش توصيات IGO-INGO WG، وتبنى توصيات الإجماع لمجموعة العمل بالإجماع بتصويت مستقل في اجتماعه بتاريخ 20 نوفمبر 2013 (راجع http://gnso.icann.org/en/council/resolutions#20131120-2).

      حيث أنه، بعد تصويت مجلس GNSO، تم عقد فترة تعليقات عامة على التوصيات المعتمدة، وتم تلخيص التعليقات المستلمة ونشرها على (http://www.icann.org/en/news/public-comment/igo-ingo-recommendations-27nov13-en.htm).

      حيث أنه، أشارت GAC على مجلس إدارة ICANN في بيان بيونيس آيريس الرسمي أنها لا تزال ملتزمة بمواصلة الحوار مع NGPC حول الانتهاء من أشكال الحماية الدائمة لاختصارات IGO على المستوى الثاني، وتعمل NGPC بجد على هذه المسألة.

      تقرر بموجب القرار رقم (2014.02.07.05)، يقر مجلس الإدارة باستلام توصيات مجلس GNSO بالإجماع حول حماية معرفات IGO-INGO في جميع gTLDs كما هي مبينة في تقرير IGO-INGO WG النهائي (راجع http://gnso.icann.org/ar/issues/igo-ingo-final-10nov13-ar.pdf [PDF، 619 كيلوبايت])، ويطلب وقتاً إضافياً للنظر بالتوصيات حتى يأخذ بعين الاعتبار المشورة من GAC التي تتناول نفس الموضوع.

      تقرر بموجب القرار رقم (2014.02.07.06)، يطلب مجلس الإدارة من لجنة برنامج gTLD الجديدة التابعة لمجلس إدارة ICANN مايلي: (1) النظر بتوصيات السياسة من GNSO مع استمرارها بوضع منهج للرد على مشورة GAC حول حماية IGOs، و(2) وضع مقترح شامل لمناقشة مشورة GAC وتوصيات GNSO للنظر بها من قبل مجلس الإدارة في اجتماع لاحق.

      حيثيات القرارين 2014.02.07.05 – 2014.07.06:

      لماذا يعالج مجلس الإدارة هذه القضية الآن؟

      رداً على مشورة GAC حول حماية معرفات RCRC وIOC وIGOs في برنامج gTLD الجديد، أوكل مجلس الإدارة إلى GNSO مهمة وضع سياسة رداً على مشورة GAC. قرر مجلس GNSO في مداولاته أن ثمة حاجة إلى عملية وضع سياسة (PDP) لحل هذه المسألة حول إجراءات الحماية الخاصة للسلاسل على المستوى الأعلى والمستوى الثاني للمنظمات الدولية. في أكتوبر 2012، وافق مجلس GNSO على المباشرة بعملية وضع سياسة حول هذه المسألة. نشرت مجموعة عمل عملية وضيع السياسة تقريرها المبدئي لإبداء التعليقات العامة في 14 يونيو 2013، وأتبعتها بالتقرير النهائي في 10نوفمبر 2013. تضمن التقرير النهائي أكثر من عشرين توصية بالإجماع من مجموعة العمل وبيانات الأقلية من ممثلي RCRC وIGO وINGO الذين شاركوا في مجموعة العمل، مجموعة أصحاب المصلحة غير التجاريين لـGNSO ولجنة At-Large الاستشارية التابعة لـICANN. تم اعتماد جميع توصيات إجماع مجموعة العمل بالإجماع من قبل مجلس GNSO.

      بعد إغلاق فترة التعليقات العامة حول هذه التوصيات وتبني مجلس GNSO لتقرير التوصيات إلى مجلس إدارة ICANN، فإن الخطوة التالية كما هي مبينة في الملحق أ من لوائح ICANN الداخلية عي نظر مجلس إدارة ICANN بتوصيات GNSO. تتطلب اللوائح الداخلية من مجلس الإدارة "الاجتماع لمناقشة" توصيات سياسة GNSO "بأقرب وقت ممكن، ولكن يفضل ألا تزيد الفترة عن موعد الاجتماع الثاني بعد استلام تقرير مجلس الإدارة من مدير طاقم العمل.

      بالإضافة إلى ذلك، تسمح المادة 11، القسم 2.1 من لوائح ICANN الداخلية لـGAC "بعرض المسائل على مجلس الإدارة مباشرة، أو عن طريق التوصية بشكل خاص بالإجراء أو وضع سياسة جديدة أو مراجعة السياسات الحالية". أصدرت GAC مشورة إلى مجلس الإدارة حول برنامج gTLD الجديد عن طريق بيانها الرسمي في بكين المؤرخ في 11أبريل 2013، وبيانها الرسمي في ديربان المؤرخ في 18 يوليو 2013، وبيانها الرسمي في بيونيس آيريس المؤرخ في 20 نوفمبر 2013. تتطلب لوائح ICANN الداخلية من مجلس الإدارة أن تأخذ بعين الاعتبار مشورة GAC حول مسائل السياسة العامة عند تشكيل وتبني السياسات. إذا قرر مجلس الإدارة اتخاذ إجراء لا يتوافق مع مشورة GAC، فينبغي له إبلاغ GAC وتوضيح أسباب عدم اتباعه لتلك المشورة. ثم يتعين على GAC ومجلس الإدارة التعاون بحسن نية لإيجاد حل مقبول من الطرفين. إذا تعذر التوصل إلى حل، ينبغي على مجلس الإدارة أن يذكر في قراره النهائي سبب عدم اتباع مشورة GAC.

      ما هو الاقتراح الذي يتم النظر فيه؟

      قبل النظر بحل مسائل جوهرية تتعلق بتوصيات سياسة GNSO، ينظر مجلس الإدارة بالكيفية التي يرغب بها المضي قدماً بهذا الموضوع كمسألة إجرائية.

      وقد اعتمد مجلس GNSO بالإجماع توصيات السياسة في التقرير النهائي لعملية وضع سياسة IGO-INGO. يتم نقل توصيات السياسة إلى مجلس الإدارة للمراجعة والنظر وفقاً للوائح ICANN الداخلية. أصدرت GAC أيضاً مشورة إلى مجلس الإدارة حول حماية IGOs ضمن سياق برنامج gTLD الجديد – مؤخراً في بيانها الرسمي في بيونيس آيريس. لأن المشورة ترتبط ببرنامج gTLD الجديد، تنظر لجنة برنامج gTLD الجديدة (NGPC) التابعة لمجلس إدارة ICANN بمشورة GAC. لم تقم NGPC بعد بإنهاء مقترحها لتناول مشورة GAC المرتبطة بحماية IGOs، ولكنها تعمل بجد على هذه المسألة.

      بشكل عام، تتفق توصيات GNSO بشكل كبير مع المشورة التي قدمتها GAC إلى مجلس إدارة ICANN. ولكن ثمة توصيات سياسة معينة من GNSO تختلف عن مشورة GAC. في الوقت الحالي، ينظر مجلس الإدارة بالإقرار بتوصيات السياسة من GNSO في التقرير النهائي حول عملية وضع سياسة IGO-INGO، ولكنه يطلب المزيد من الوقت للنظر بالتوصيات نظراً لأن NGPC تعمل بجد على مناقشة مشورة GAC حول نفس الموضوع. يفكر مجلس الإدارة باتخاذ منهج شامل للنظر بتوصيات السياسة من GNSO ومشورة GAC عن طريق الطلب من NGPC مايلي: (1) النظر بتوصيات السياسة من GNSO مع استمرارها بوضع منهج للرد على مشورة GAC حول حماية IGOs، و(2) وضع مقترح شامل لمناقشة مشورة GAC وتوصيات سياسة GNSO للنظر بها من قبل مجلس الإدارة في اجتماع لاحق.

      ما هي المواد المهمة التي يستعرضها مجلس الإدارة؟

      راجع مجلس الإدارة تقرير توصيات مجلس GNSO إلى مجلس الإدارة، بالإضافة إلى ملخص عن التعليقات العامة والتقرير النهائي لمجموعة العمل. كما راجع مجلس الإدارة بيان بكين الرسمي وبيان ديربان الرسمي وبيان بونيس آيريس الرسمي.

      ستتم مناقشة المخاوف والمسائل التي أثارها المجتمع وأصحاب المصلحة حول توصيات سياسة GNSO ومشورة GAC عندما ينظر مجلس الإدارة بفحوى توصيات سياسة GNSO ومشورة GAC. عندئذٍ، سينظر مجلس الإدارة أيضاً بالتأثيرات المالية أو الانعكاسات على ICANN والمجتمع. لن يكون ثمة أية قضايا حماية أو استقرار أو مرونة مرتبطة بنطاقات DNS إذا وافق مجلس الإدارة على التوصيات المقترحة.

      يشار إلى أن هذا القرار هو ناتج عن عملية وضع سياسة خضعت بالفعل لعملية التعليقات العامة.

    2. تشكيل مجموعة عمل لمجلس الإدارةحول عملية الاختيار والتعيين للجنة الترشيح والحجم والتركيب.

      حيث أنه، تلقى مجلس الإدارة بالسابق التقرير النهائي لمجموعة عمل مراجعة إنهاء NomCom في 12 مارس 2010، والذي طالب بإجراء مراجعة خلال فترة ثلاثة سنوات لمسائل التركيب والحجم والتعيين في لجنة الترشيح.

      حيث أنه، توصي لجنة التحسينات الهيكلية (SIC) بأنه حان الوقت لإنهاء عمل المتابعة المتوقع في التقرير النهائية وأنه يمكن تأسيس مجموعة عمل تابعة لمجلس الإدارة لهذا الغرض.

      تقرر بموجب القرار رقم (2014.02.07.07)، يوافق مجلس الإدارة على تأسيس مجموعة عمل تابعة لمجلس الإدارة حول لجنة الترشيح (BWG-NomCom) وفقاً للميثاق الموصى به من قبل SIC، وستتم مناقشة عضويته من قبل لجنة حوكمة مجلس الإدارة.

      حيثيات القرار 2014.02.07.07

      يتناول مجلس الإدارة مسألة عمليات الاختيار والتعيين لـNomCom وحجم وتركيب NomCom، لأن NomCom تلعب دوراً رئيسياً في آليات المساءلة في ICANN. بسبب المخاوف الصريحة حول العيوب الحقيقية والمتوقعة لـNomCom الحالية والتغييرات في تركيب أصحاب المصلحة في ICANN، من الملائم مناقشة هذه المسائل المهمة في الوقت الراهن.2 من المتوقع أن تنظر مجموعة العمل المقترحة بمسائل ذات أهمية للمجتمع، بالتالي، ستثبت مساءلة ICANN في إجراء عملية ترشيح الأشخاص المؤهلين لمناصب ريادية رئيسية بشكل موثوق وشفاف. ستتابع مجموعة العمل التوصيات التي نتجت عن مراجعة هيكلية سابقة ألزمت بها لوائح ICANN الداخلية، بما يتماشى مع توجيهات مجموعة عمل إنهاء المراجعة (التوصية 10) لمراجعة حجم وتركيب ووظائف الاختيار والتعيين من قبل NomCom.

      عند النظر بهذا الإجراء، راجع مجلس الإدارة مواداً يشار إليها أدناه والتوصيات التي قدمتها SIC، بما في ذلك ميثاق مجموعة العمل، واستعرض خيار إضافة أعضاء من خارج مجلس الإدارة إلى مجموعة العمل للحصول على منظور إضافي من المجتمع.

      وليس ثمة تأثيرات مالية متوقعة لهذا القرار، ولن يتأثر أمن واستقرار ومرونة نظام أسماء النطاقات نتيجةً لهذا الإجراء.

      يشار إلى أن هذه وظيفة إدارية هيكلية لا تتطلب تعليقات عامة.

      المواد ذات الصلة:

    3. توصيات عملية وضع سياسةGNSO لـWhois المكثف

      حيث أنه، في 14 مارس 2012، بدأ مجلس GNSO عملية وضع سياسة (PDP) حول استخدام Whois المكثف من قبل جميع سجلات gTLDs، سواء الحالية والمستقبلية (راجع ميثاق مجموعة عمل عملية وضع السياسة، المبين على https://community.icann.org/x/vIg3Ag).

      حيث أنه، اتبعت عملية وضع السياسة إجراءات عملية وضع السياسة المنصوص عليها في اللوائح الداخلية والعملية الواجبة، الأمر الذي نتج عنه تقرير نهائي تم تسليمه بتاريخ 21أكتوبر 2013.

      حيث أنه، توصلت مجموعة عمل (WG) عملية وضع السياسة لـWhois المكثف إلى إجماع كامل حول التوصيات المتعلقة بالمسائل المحددة في الميثاق.

      حيث أنه، راجع مجلس GNSO وناقش توصيات مجموعة عمل عملية وضع السياسة لـWhois، وتبنى التوصيات في 31 أكتوبر 2013 بأغلبية ساحقة وتصويت بالإجماع (راجع http://gnso.icann.org/en/council/resolutions#20131031-1).

      حيث أنه، تجاوز تصويت مجلس GNSO حد التصويت المتطلب المبين في لوائح ICANN الداخلية لفرض سياسات إجماع جديدة على الأطراف المتعاقدة مع ICANN.

      حيث أنه، قرر مجلس GNSO إنشاء فريق مراجعة تنفيذ Whois المكثف لمساعدة طاقم عمل ICANN على وضع تفاصيل التنفيذ للسياسة الجديدة إذا تم اعتمادها من قبل مجلس إدارة ICANN.

      حيث أنه، بعد تصويت مجلس GNSO، تم عقد فترة تعليقات عامة على التوصيات المعتمدة، وكانت التعليقات المستلمة تؤيد التوصيات بشدة (http://www.icann.org/en/news/public-comment/thick-whois-recommendations-06nov13-en.htm).

      تقرر بموجب القرار رقم (2014.02.07.08)، يعتمد مجلس الإدارة توصيات سياسة مجلس GNSO لوضع سياسة إجماع جديدة حول Whois المكثف كما هو مبين في القسم7.1 من التقرير النهائي (راجع http://gnso.icann.org/ar/issues/whois/thick-final-21oct13-ar.pdf [PDF، 663 كيلوبايت]).

      تقرر بموجب القرار رقم (2014.02.07.09)، يطلب مجلس الإدارة من رئيس ICANN ومديرها التنفيذي وضع خطة تنفيذ لسياسة Whois المكثف متسقة مع الإرشادات التي يقدمها مجلس GNSO. لقد تم منح الرئيس والمدير التنفيذي الصلاحية والتوجيهات للعمل مع فريق مراجعة التنفيذ لوضع تفاصيل تنفيذ السياسة، ومواصلة التواصل مع المجتمع حول مثل هذا العمل.

      حيثيات القرارين 2014.02.07.08 – 2014.02.07.09:

      لماذا يعالج مجلس الإدارة هذه القضية الآن؟

      وتحدد ICANN متطلبات خدمة Whois لكافة سجلات نطاق المستوى الأعلى العام (gTLD) من خلال اتفاقيات السجل (RA) واتفاقيات اعتماد المسجلين (RAA). تحقق السجلات وأمناء السجلات التزامات Whois الخاصة بهم من خلال استخدام نموذجين مختلفين من الخدمة. غالبًا ما يوصف النموذجان الشائعان بأنها سجلات Whois "رقيقة" و"مكثفة". ويستند هذا التمييز على كيفية إدارة المجموعات المميزة بينها من البيانات. وترتبط مجموعة واحدة من البيانات باسم النطاق بينما ترتبط المجموعة الثانية من البيانات باسم نطاق المسجل.

      • يخزن السجل "النحيل" ويدير المعلومات المرتبطة باسم المجال. وتضم هذه المجموعة بيانات كافية لتحديد المسجل الراعي وحالة التسجيل وعمل تواريخ انتهاء لكل تسجيل وبيانات خادم الاسم وآخر مرة تم فيها تحديث السجل في مخزن بيانات WHOIS وURL لخدمة Whois الخاصة بأمين السجل.
      • وعبر السجلات "الرقيقة"، يدير أمناء السجلات المجموعة الثانية من البيانات المرتبطة بنطاق أمين المسجل وذلك عن طريق تقديم خدمات Whois الخاصة، كما هو مطلوب من قبل القسم 3.3 من RAA فيما يتعلق بالنطاقات التي ترعاها. تعد COM وNET أمثلة على السجلات الرقيقة.
      • وتقدم السجلات "المكثفة" وتحفظ كل من مجموعات البيانات (اسم النطاق والمسجل) عن طريق Whois. تعد INFO وBIZ أمثلة على السجلات المكثفة.

      لاستكشاف المزايا المحتملة للتطلب من جميع سجلات gTLD تقديم Whois مكثف، باشر مجلس GNSO عملية وضع سياسة في 14 مارس 2012. تشكلت مجموعة عمل عملية وضع السياسة وأوكلت إليها مهمة النظر بالمواضيع التالية كجزء من مداولاتها:

      • اتساق الاستجابة
      • الاستقرار
      • الوصول إلى بيانات Whois
      • التأثير على الخصوصية وحماية البيانات
      • آثار التكاليف
      • التزامن/الانتقال
      • الرسمية
      • المنافسة في خدمات السجل
      • تطبيقات Whois الحالية
      • مستودع البيانات
      • متطلبات Whois الخاصة بمنفذ المسجلين 43

      وقد نشرت مجموعة العمل تقريرها المبدئي لإبداء التعليقات العامة في 21 يونيو 2013، وتلاه تقريرها النهائي في 21 أكتوبر 2013، والذي لقي دعمًا كاملاً بالإجماع من مجموعة عمل عملية وضع السياسة بالإضافة إلى مجلس GNSO. وتبع تصويت مجلس GNSO فترة تعليقات عامة، كما هو مبين في لوائح ICANN الداخلية. عكست التعليقات تأييداً قوياً لتوصيات GNSO، دون إثارة أية اعتراضات أو مخاوف من أية مجموعة أصحاب مصلحة أو دائرة. نتيجةً لذلك، أصبحت هذه المسالة وتوصيات GNSO جاهزة لكي ينظربها مجلس إدارة ICANN.

      ما هو الاقتراح الذي يتم النظر فيه؟

      يتم النظر في التوصيات التالية:

      #1: ينبغي أن يصبح توفير خدماتWHOIS المكثف، مع وضع علامات متسقة وعرض وفقاً للنموذج المبين في المواصفات 3 من اتفاقية اعتماد المسجل لعام 20133 متطلباً لجميع سجلاتgTLD, سواء الحالية والمستقبلية.

      بالإضافة إلى ذلك، يوصي مجلس GNSO بمايلي:

      #2: بعد اعتماد التقرير النهائي والتوصيات من قبل مجلسGNSO, ومنتدى التعليقات العامة السابق (قبل دراسة مجلس الإدارة) والإخطار من قبل مجلس إدارةICANN إلىGAC, لطلب الآراء بشكل محدد حول أية اعتبارات متعلقة بالانتقال منWhois الرقيق إلى المكثف ينبغي أخذها بعين الاعتبار كجزء من عملية التنفيذ.

      #3: كجزء من المراجعة القانونية لعملية التطبيق للقانون الساري لنقل البيانات من النموذج الرقيق إلى النموذج المكثف التي لم يتم دراستها بالفعل في مذكرة مجموعة عمل الخبراء (EWG)4 الذي يجري ويتم أخذ في الاعتبار قضايا السياسة المحتملة التي قد تنشأ نتيجة المناقشات في استمارة الانتقال منWhois الرقيق إلى المكثف، بما في ذلك على سبيل المثال، التوجيه بشأن المتطلبات التعاقدية طويلة الأمد التي تعطي إشعارًا إلى، والحصول على اتفاق، من كل من المسجلين لاستخدامات أي بيانات شخصية محددة مقدمة من قبل المسجلين الذين ينبغي عليهم تقديم طلب إلى التسجيلات المتضمنة في عملية النقل.ينبغي لأي قضايا خصوصية أن تخرج من مناقشات عملية الانتقال التي لم تكن متوقعة من قبل مجموعة العمل والتي ستطلب أي اعتبارات في السياسة الإضافية، ومن المتوقع أن يخطر فريق مراجعة عملية التطبيق مجلسGNSO لهذه الإجراءات التي يمكن اتخاذها.

      من تمت مشاورته من أصحاب المصلحة أو غيرهم؟

      بالإضافة إلى التحديثات الدورية المقدمة إلى مجلس GNSO، تم تنظيم ورش عمل لعرض وطلب الآراء من مجتمع ICANN في اجتماع ICANN (راجع على سبيل المثال http://durban47.icann.org/node/39777 وhttp://beijing46.icann.org/node/37029).

      تم طلب بيانات من مجموعة الدائرة / أصحاب المصلحة بالإضافة إلى التعقيبات من منظمات الدعم واللجان الاستشارية الأخرى التابعة لـICANN في مرحلة مبكرة من العملية. قدمت معظم مجموعات مصلحة ودوائر GNSO آراءً، بالإضافة إلى لجنة At‑Large الاستشارية (راجع https://community.icann.org/x/WIRZAg).

      افتتحت مجموعة العمل منتدى تعليقات عامة حول التقرير المبدئي في 21 يونيو 2013.

      تمت مراجعة جميع التعليقات المستلمة حول التقرير المبدئي وأخذها بعين الاعتبار من قبل مجموعة عمل عملية وضع سياسة Whois المكثف (راجع القسم 6 من التقرير النهائي).

      بالإضافة إلى ذلك، تم طلب الآراء حول التقرير النهائي بعد اعتماد مجلس GNSO وقبل النظر بها من قبل مجلس إدارة ICANN (راجعhttp://www.icann.org/en/news/public-comment/thick-whois-recommendations-06nov13-en.htm).

      بالإضافة إلى ذلك، مجلس الإدارة أبلغ [PDF، 85 كيلوبايت] GAC بقرب موعد نظرها بهذه المسألة، وبطلب من مجلس GNSO، تم تشجيع GAC بشكل خاص على تقديم اية اعتبارات مرتبطة الانتقال من Whois الرقيق إلى المكثف ينبغي أخذها بعين الاعتبار كجزء من عملية التنفيذ (لم يتم استلام آراء حتى وقت تقديم هذه الورقة).

      ما هي المخاوف أو القضايا التي أثارها المجتمع؟

      لم يتم التعبير عن أية مخاوف لدى المجتمع فيما يتعلق بالتقرير النهائي وتوصياته. تمت مراجعة جميع التعليقات الأخرى قبل نشر التقرير النهائي والنظربها وتناولها من قبل مجموعة عمل عملية وضع السياسة كما هو مبين في القسم 6 من التقرير النهائي وانعكست في توصيات مجموعة العمل النهائية.

      ما هي المواد المهمة التي يستعرضها مجلس الإدارة؟

      راجع مجلس الإدارة تقرير توصيات مجلس GNSO إلى مجلس الإدارة، بالإضافة إلى ملخص للتعليقات العامة. لاحظ مجلس الإدارة أيضاً أنه رغم أن فريق مراجعة Whois لم يقدم أية توصيات معينةعند وقت تقديم تقريره النهائي [PDF، 96 كيلوبايت] لعدم وجود سياسة خاصة بـWhois المكثف لتتم مراجعتها، فقد أوصى "بإجراء صيانة شاملة لخدمة الإنترنت لتوفير قابلية استخدام معززة للمستهلكين، بما في ذلك عرض بيانات المشترك الكاملة لجميع أسماء نطاقات gTLD"، الأمر الذي يمكن تحقيقه بالتطلب من جميع gTLDs العمل بموجب نموذج Whois المكثف.

      ما هي العناصر ذات الأهمية لدى مجلس الإدارة؟

      لقد تم وضع التوصيات باتباع عملية GNSO لوضع السياسة كما هو مبين في الملحق أ من لوائح ICANN الداخلية، وقد نالت الدعم بالإجماع من مجلس GNSO. كما هو مبين في لوائح ICANN الداخلية، فإن دعم مجلس GNSO بالإجماع (بأغلبية ساحقة) للطلب يُلزم مجلس الإدارة بتبني التوصية بتصويت يبلغ أكثر من 66%، وقرر مجلس الإدارة أن السياسة ليست من صالح مجتمع ICANN وICANN.

      هل هناك تأثيرات مجتمعية سلبية أو إيجابية؟

      ثمة مزايا عديدة متوقعة نتيجةً لتطلب Whois مكثف لجميع سجلات gTLD، كما هو مبين في التقرير النهائي لعملية وضع سياسة Whois المكثف (راجع http://gnso.icann.org/ar/issues/whois/thick-final-21oct13-ar.pdf [PDF، 663 كيلوبايت]). ومع ذلك، ينبغي الاعتراف أن عملية انتقال سجلات gTLD الرقيقة الحالية ستؤثر على 120 مليون عملية تسجيل لأسماء النطاقات. نتيجةً لذلك، ينوي طاقم العمل المضي قدماً بحرص لإعداد وتنفيذ الانتقال الموصى به من Whois الرقيق إلى المكثف. يتوقع طاقم العمل أن يكون لعملية الانتقال تأثيرات مالية متوسطة كما هو مبين في القسم 5.6 من التقرير النهائي – تضمينات التكاليف. على وجه الخصوص، سيكون ثمة تكلفة لمرة واحدة متضمنة بالانتقال الفعلي من الرقيق إلى المكثف، ولكن يعتقد طاقم العمل أنه يمكن إدارتها بحيث تقلل من هذه التكاليف. علاوة على ذلك، مع الإقرار بأن معظم السجلات تتعامل بالتسجيلات عن طريق TLDs المكثفة والسجل الوحيد الذي يشغل حاليًا مع gTLDs رقيق (Verisign) يشغل أيضاً gTLDs مكثفة، فمن المتوقع ألا تحتاج الأطراف المتعاقدة المتأثرة إلى منحنى تعليمي مهم أو أنظمة برمجيات جديدة من أجل المضي قدماً بعملية الانتقال.

      هل توجد تأثيرات أو نتائج مالية علىICANN (كالخطة الإستراتيجية أو خطة التشغيل أو الميزانية) أو على المجتمع، و/أو العامة؟

      بالإضافة إلى تلك التغييرات المتطلبة في عملية المسجلين وسجلات gTLD كما هي مبينة في القسم السابق، ثمة آثار مالية محتملة مرتبطة بتنفيذ السياسة، على سبيل المثال فيما يرتبط بالمراجعة القانونية المتطلبة لمسائل الخصوصية المحتملة التي قد تنشأ عن النقاشات حول الانتقال من Whois الرقيق إلى المكثف، وتحديث نماذج شكازى الالتزام، والأسئلة الشائعة والوثائق الداعمة، ولكن من المتوقع أن تكون هذه التكاليف ضمن الميزانية الحالية و/ أو سيتم توقعها في السنة المالية الجديدة التي تبدأ في يوليو 2014.

      هل توجد أية مسائل تتعلق بـ DNS من حيث الأمن أو الاستقرار أو المرونة؟

      لن يكون ثمة أية مسائل تتعلق بالامن أو الاستقرار أو المرونة مرتبطة بنطاقات DNS إذا وافق مجلس الإدارة على التوصيات المقترحة، بما أنه تم تنفيذ Whois المكثف بالفعل في سجلات gTLD أخرى، وهي متطلب لـgTLDs الجديدة. علاوة على ذلك، تتمتع ICANN بالخبرة في عمليات الانتقال المشابهة عندما تم نقل سجل .org من سجل رقيق إلى مكثف في عام 2004.

      يشار إلى أن هذا القرار هو ناتج عن عملية وضع سياسة خضعت بالفعل لعملية التعليقات العامة.


1 Rationale for Resolution 2014.02.07.03 was updated on 18 February 2014 to highlight that the fiscal impacts of adopting the resolution should be considered in context of additional costs that may be associated with the Board's previous commitment to strengthen the TLG advisory mechanism established in the Bylaws.

2 Errata Note: Rationale for Resolution 2014.02.07.07 was updated on 18 February 2014 to clarify that the Board's decision to create a NomCom Working Group is to address the perceived structural deficiencies of the NomCom – not the composition of the NomCom. The original text stated, "Because of the expressed concerns about the real and perceived deficiencies of the current NomCom and the changes in the composition of ICANN stakeholders, it is appropriate to address these critical issues at this time."

3 http://www.icann.org/ar/resources/registrars/raa/approved-with-specs-27jun13-ar.htm#whois

4 voir http://forum.icann.org/lists/gnso-thickwhoispdp-wg/pdfLtpFBYQqAT.pdf [PDF, 146 KB]

resolutions-07feb14-ar.pdf  [170 KB]

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."