Skip to main content

تحديث على طلب تقديم العروض الخاص باستشاري إطار عمل إدارة مخاطر DNS – ردود على الأسئلة الواردة

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

نشرت ICANN في 16 يوليو طلبًا لتقديم العروض للحصول على استشاري خبير لمساعدة ICANN في تطوير إطار عمل لإدارة مخاطر DNS . وأشار الإعلان إلى أن إمكانية تقديم الأسئلة المتعلقة بطلب تقديم العروض RFP بين 1 - 16 أغسطس 2012 في تمام الساعة 23:59 بالتوقيت العالمي المنسق. وقد انتهت الفترة المتاحة لطرح الأسئلة حول طلب تقديم العروض. وتوفر ICANN في هذا التحديث الأسئلة التي وردت بالإضافة إلى الردود عليها بحيث يتسنى لجميع الجهات المعنية بالرد على دعوة تقديم العروض أن يكون لديها نفس المعلومات.

علمًا بأن آخر موعد لتلقي الردود هو 31 أغسطس 2012 , في تمام الساعة 23:59 بالتوقيت العالمي المنسق. ويجب إرسال الردود على drmf-rfi@icann.org على أن تكون موجهة باسم عناية السيد باتريك جونز في فريق أمن ICANN.

الأسئلة

تقديم العروض

  1. نرغب في معرفة ما إذا كنتم ستقبلون العروض الخاصة بهذا العقد من الاتحادات (شركتين استشاريتين) أم أنكم تشترطون الحصول على استشاري واحد فقط.

    الرد – نرحب بتلقي العروض المقدمة من اتحادات الشركات. ويجب أن يحتوي العرض على الكيفية التي ستعمل بها الأطراف المتعاقدة في الاتحاد مع بعضها البعض وطريقة التعامل مع ICANN.

تحديد الموعد

  1. ما هو النطاق الزمني المتوقع للمشروع، فيما يتعلق بالاجتماعات المنقضية، مع توفير المواعيد اللازمة للتعليق الداخلي والتعليق العام؟

    الرد – من الناحية النموذجية، سوف يكون لـ ICANN القدرة على الاحتفاظ باستشاري لبدء العمل في هذا المشروع في أواخر شهر سبتمبر، والمشاركة في لجنة مجتمعية مفتوحة في جمعية ICANN المقرر عقدها في أكتوبر بمدينة تورنتو، بولاية أونتاريو. سوف يتم تحديد مواد التسليم بالتوقيت المحدد بمجرد إسناد العمل إلى الاستشاري، إلا أنه من المتوقع بالنسبة لمجموعة العمل على مستوى مجلس الإدارة أن يتوفر مشروع إطار عمل لإدارة مخاطر DNS للمناقشة في بداية شهر ديسمبر 2012 ، وفترات التعليق العام ذات الصلة التي تلي ذلك لمجلس إدارة ICANN في جمعية ICANN المقرر عقدها في بكين، بالصين في أبريل 2013.

  2. ما هي المدة المتوقعة بالنسبة لخطة النقل لإكمال عملية بدء المشروع من حيث توافر فريق عمل ICANN ؟

    الرد – سوف يتوفر فريق عمل ICANN ومتابعة عمل الاستشاري طوال مدة المشروع. وينبغي أن يحد ذلك من حالات التأخير بين بداية المشروع ومرحلة التنفيذ لإدارة المخاطر التشغيلية في ICANN.

  3. ما هو تاريخ البداية المتوقع بالنسبة لتنفيذ أنشطة طلب تقديم العروض؟

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

  4. متى ستقوم ICANN بالإعلان عن قرارها حول مقدم العرض الفائز؟

    الرد – تعتزم ICANN اتخاذ قرارها سريعًا، وذلك استنادًا إلى جودة الردود الواردة وعملية الاختيار على المستوى الداخلي. وتعتزم ICANN الإعلان عن قرارها في أوائل شهر سبتمبر.

دعم فريق العمل

  1. ما هو الحجم المتوقع لفريق ICANN الداخلي المقرر لتنفيذ المنهجية والموقع الجغرافي وتنوع فريق العمل المخصص؟

    الرد – سوف يقود فريق الأمن في ICANN إطار العمل الخاص بإدارة مخاطر DNS ولكن سينطوي على خبرات من فريق العمل في الإدارات الأخرى، والتي تشمل الإدارة القانونية، وعمليات DNS ، وتقنية المعلومات، والإدارة المالية، وإدارة IANA ، على سبيل المثال لا الحصر. وفريق العمل الخاص بـ ICANN موزع على مستوى العالم، على الرغم من أن فريق الأمن منقسم في الوقت الحالي بين الساحل الشرقي والساحل الغربي للولايات المتحدة.

  2. ما هو التشكيل الخاص بفريق ICANN المخصص لتنفيذ أنشطة إدارة المخاطر (عدد فريق العمل، الترتيب الهرمي، إلخ)؟

    الرد – يوفر فريق الأمن في ICANN الدعم اللازم للجنة المخاطر التابعة لمجلس الإدارة ومجموعة العمل على إطار إدارة مخاطر DNS على مستوى مجلس الإدارة. وهناك فريق عمل من ICANN قادم من فريق الإدارة القانونية يوفر كل من الدعم لمجلس الإدارة ومشاركة الفريق التنفيذي من خلال الاستشاري العام في ICANN . ويتابع الفريق التنفيذي أنشطة إدارة المخاطر، بالإضافة إلى مخاطر إدارة التتبع لفريق عمل الإدارة الفردية.

  3. ما هو التزام موظفي الدوام الكامل فيما يتعلق بتوافر ICANN للمشاركة في الجهود المبذولة في المشروع؟

    الرد – سوف يتولى فريق أمن ICANN بتوفير الدعم لفريق العمل من أجل المشاركة ما الاستشاري في تنفيذ هذا المشروع.

إعداد المواد

  1. يشير طلب تقديم العروض إلى أن الاستشاري الخبير سوف يقدم تقريرًا إلى مجموعة العمل على إطار إدارة مخاطر DNS التابع لمجلس الإدارة ومجتمع ICANN . هل ستتم مشاركة مواد التسليم التي يقدمها الاستشاري حرفيًا مع المجتمع كمستندات عامة، أم أن ICANN أو الاستشاري الخبير سيقوم بإعداد ملخصات لمشاركتها علانية؟

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

قائمة بالمهام الخاصة بإطار إدارة مخاطر DNS

  1. مهمة 2 – إطار المخاطر – هل سبق أن اعتمدت ICANN إطارًا لإدارة المخاطر؟ ما طبيعة هذا الإطار؟

    الرد – نعم، ICANN لديها إطار عمل داخلي لإدارة مخاطر المؤسسة.

  2. مهمة 2 – إطار المخاطر – هل لدى ICANN أي أطر عمل تنظر في اعتمادها داخل المنظمة الخاصة بها؟

    الرد – سوف تتلقى ICANN المقترحات العملية القابلة للتنفيذ في إدارة مخاطر DNS.

  3. مهمة 2 – إطار المخاطر – هل لدى ICANN إطار عمل لإدارة مخاطر المشروعات (ERM ) يجب أن يتوازى معه هذا الإطار الخاص بإدارة مخاطر الأمن؟

    الرد – ICANN لديها إطار عمل لإدارة مخاطر المشروعات. وسوف تتلقى ICANN المقترحات العملية القابلة للتنفيذ في إدارة مخاطر DNS.

  4. مهمة 2 – إطار المخاطر – هل ستفكر ICANN في وضع قاعدة لإطار إدارة المخاطر الخاص بها على أساس الممارسات الرائدة والأطر المقبولة قبولاً عالميًا مثل Risk IT وCOBIT5 للأمن؟

    الرد – COBIT في الأساس عبارة عن إطار لعمليات تقنية المعلومات. ويتعين على الاستشاري الأخذ في الاعتبار أن التركيز على إطار إدارة المخاطر ليس في مجمله على تقنية المعلومات أو الدعم الفني، ولكن على مخاطر DNS لـ ICANN كمنظمة. ويمكن استخدام COBIT5 وRisk IT كمثالين ولكن لا يجب أن يكونا الأساس الذي يعتمد عليه الإطار المقترح من الاستشاري.

  5. مهمة 2 – إطار المخاطر – لا توضح قائمة مواد التسليم بوضوح المتطلبات الخاصة بحوكمة المخاطر (على سبيل المثال الميل للمخاطر وتحمل المخاطر، والمسئوليات والمسائلة بالنسبة لإدارة مخاطر تقنية المعلومات، والوعي والاتصال، وثقافة المخاطر). هل هذا أيضًا من بين مواد التسليم المطلوبة؟

    الرد – نرحب بالتوصيات الواردة من الاستشاري حول آليات الإفصاح بوضوح عن المتطلبات الخاصة بحوكمة المخاطر على أن يكون ذلك في سياق مخاطر DNS.

  6. مهمة 3 – بناء الإجماع – ما طول الفترة المتوقعة لدورة التعليق العام؟

    يوجد شرح للعملية الخاصة بدورة التعليق العام لـ ICANN على http://www.icann.org/en/news/public-comment. أما طول المدة الإجمالية لدورة التعليق العام فإنه يتوقف على ما إذا كانت التعليقات سيتم تلقيها في فترة التعليق الأولية، بما يستدعي فترة للتعليق على الردود. ارتأت مجموعة العمل إجراء عملية التعليق العام في الجزء الأول من عام 2013 ، على الرغم من أن هذا الموعد عرضة للتغيير استنادًا إلى مجموعة متنوعة من العوامل.

  7. مهمة 3 – بناء الإجماع – هل ستقوم مجموعة العمل بتوفير استعراض وتعليق قبل دورة التعليق العام؟ هل ستكون هناك الفرصة في تقديم مراجعات لإطار العمل قبل إطلاقه للتعليق العام، استنادًا إلى التعليقات والآراء الواردة من مجموعة العمل؟

    الرد – نعم

  8. مهمة 3 – بناء الإجماع – ما الإجراء الذي ستستخدمه مجموعة العمل للتعرف على مدى تحقيق الإجماع؟

    الرد – تسعى مجموعة العمل للحصول على إطار عمل لإدارة مخاطر DNS يكون قابلاً للتنفيذ ويكون مقبولاً بشكل عام لدى المجتمع بأنه يحقق المتطلبات الواردة في هذا العرض.

  9. مهمة 3 – بناء الإجماع – يشير طلب تقديم العروض إلى أن الاستشاري الخبير سوف "يساعد فريق العمل ومجموعة العمل على بناء الإجماع في دعم إطار إدارة المخاطر داخل ICANN (أي المنظمة والمجتمع)." هل من المقرر أن يتعامل الاستشاري الخبير مباشرة مع المجتمع، أم سيتعامل الاستشاري الخبير مع المجتمع فقط من خلال فريق عمل ICANN ؟

    الرد – من البداية الأولى، ترغب مجموعة العمل على مستوى مجلس الإدارة من الاستشاري المشاركة ف الجلسة المفتوحة لمجموعة العمل في اجتماع ICANN المقرر عقده في تورنتو في 18 أكتوبر 2012 . وسوف يتيح الاجتماع الفرصة أمام المشاركين المعنيين في المجتمع بطرح الأسئلة، وأيضًا أمام الاستشاري في الانخراط والمشاركة في الحضور في الاجتماع. كما أنه من المتوقع بالنسبة للاستشاري أن يتعامل مباشرة مع الخبراء في المجتمع في وضع وتطوير إطار المخاطر.

  10. مهمة 4 – دورة المخاطر – يشير طلب تقديم العروض إلى أن المهمة 4 تعتبر جزءًا من "مرحلة ثانية محتملة". ما هي العوامل المحددة لحدوث "مرحلة ثانية" من عدمه؟

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

  11. مهمة 4 – دورة المخاطر – هل يجب أن يحتوي العرض على تقديرات لأنشطة المرحلة الثانية المحتملة؟

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

  12. مهمة 4 – دورة المخاطر – ما الأدوات التي تستخدمها ICANN في الوقت الحالي في تحديد وتوثيق وإدارة ومراقبة المخاطر؟

    الرد – تتعقب ICANN المخاطر داخل الإدارات العاملة بها كما توفر تحديثات دورية بالنواحي الأساسية لمخاطر البرنامج من خلال لجنة مجلس الإدارة المعنية، مثل لجنة المخاطر التابعة لمجلس الإدارة، لجنة الماليات التابعة لمجلس الإدارة، لجنة IANA التابعة لمجلس الإدارة، على سبيل المثال لا الحصر. كما أن برنامج gTLD الجديد به آلية تقديم تقارير منفصلة من خلال لجنة gTLD الجديدة التابعة لمجلس الإدارة.

  13. مهمة 4 – هل توفر ICANN أية حلول للحوكمة، وإدارة المخاط والتوافق (GRC )؟

    الرد – يُجرى فريق التوافق في ICANN حاليًا عملية لتطوير أدوات من شأنها دعم الجهود التي تبذلها في إدارة مخاطر التوافق. لا تمانع ICANN في تلقي مقترحات حلول التقنية التي من شأنها المساعدة في جعل إطار إدارة مخاطر DNS عمليًا وقابلاً للتنفيذ بمجرد استلامه من الاستشاري.

  14. مهمة 4 – دورة المخاطر – هل تقدم ICANN أية مخاطر محددة وموثقة مسبقًا في منظمتها؟ وهل هناك أية أنشطة أخرى للمخاطر تحدث في المنظمة؟ ما هي طبيعتها؟

    الرد – تـُجري ICANN اجتماعات دورية للجنة المخاطر التابعة لمجلس الإدارة فيها وتستخدم المخاطر المحددة والموثقة مسبقًا في إدارة المخاطر داخل المنظمة.

  15. مهمة 4 – دورة المخاطر – هل ترغب ICANN في أن تشتمل مواد التسليم على مكتبة قياسية تضم العمليات والمخاطر والرقابة بالنسبة لمخاطر الأمن الأساسية الخاصة بها؟

    الرد – المهام الأساسية لهذا العقد منصوص عليها في طلب تقديم العروض. يجب تقديم معلومات إضافية تعدم تسليم إطار إدارة مخاطر DNS للمنظمة.

  16. مهمة 4 – دورة المخاطر – خلال التعامل مع خطة المخاطر (إستراتيجية الرد على المخاطر)، هل ترغب ICANN في تضمين إجراءات اختبار عينات لتحقق من فاعلية خطة المخاطر بالإضافة إلى إجراءات مراقبة للعوامل الأساسية؟

    الرد – نعم، يمكن تضمين ذلك إذا كان من شأنها دعم إطار العمل.

  17. مهمة 4 – دورة المخاطر – هل ترغب ICANN في المساعدة في تصميم ووضع المراقبة وتقارير التقييم؟

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

عام

  1. ما هي معايير الاختيار الأساسية التي تستخدمها ICANN في ترسية طلب تقديم العروض هذا؟

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


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