Skip to main content

مقدم خدمة اختبار ما قبل التفويض لنطاقات gTLD الجديدة – الأسئلة والأجوبة على طلب تقديم العروض

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

يرجى من المشاركين الرد على طلب تقديم العروض من خلال الرد على pre-delegation-testing-bid@icann.org. وقد انتهت الفترة المتاحة لطرح الأسئلة حول طلب تقديم العروض RFP. علمًا بأن موعد الرد النهائي على طلب العروض هو 20 نوفمبر 2012.

تم تقديم الأسئلة التالية في الفترة ما بين 30 أكتوبر و 7 نوفمبر 2012. ويجري نشر المجموعة الكاملة من الأسئلة والإجابات على موقع ICANN على الويب لتعم المنفعة على جميع المشاركين.

يتم تجميع الأسئلة معًا عندما ترد أسئلة متشابهة، أو عندما تكون نفس الإجابة ذات صلة بأسئلة متعددة.

النص الوارد أدناه مستند إلى الأسئلة التي تم تلقيها من أصحاب الردود المحتملين على طلب تقديم العروض RFP، وتمت إعادة كتابتها لغرض الحيادية.

السؤال 1 Q.16: ما الذي تقصده ICANN خصيصًا باللفظ "ثلاث مراحل أساسية؟"

هذه هي الأجزاء الثلاثة المختلفة التي تم تحديدها في القسم 2.2. ("النطاق").

السؤال 2 هل من المتوقع أن تكون واجهات الويب داخل كل نظام سجل بحاجة إلى إجراء اختبار هي الأخرى؟

يجب إجراء اختبار للواجهة Whois وفقًا لما هو مذكور في الفقرة 2.3.4.1. حيث ينص دليل مقدمي الطلبات على ما يلي:

"تلتزم ICANN بالتحقق من أن بيانات Whois قابلة للوصول من خلال البروتوكول IPv4 والبروتوكول IPv6 من خلال كل من TCP المنفذ 43 ومن خلال واجهة ويب مع مراجعة مستندات التوثيق الذاتي فيما يخص سعة معاملات Whois. كما أن صيغة الرد وفقًا للمواصفة رقم 4 لاتفاقية السجل والوصول إلى Whois (من خلال المنفذ 43 ومن خلال الويب) سوف تخضع للاختبار عن بعد بمعرفة ICANN وذلك من خلال العديد من النقاط المتنوعة على الإنترنت عبر استخدام البروتوكول IPv4 وIPv6".

السؤال 3 هل سيكون هناك مصدر محدد تابع لـ ICANN يمكن لموفر عملية الاختبار استشارته أثناء مراحل التصميم والتنفيذ في حالة ظهور أية مشكلة؟

نعم.

السؤال 4 يشير طلب تقديم العروض إلى أن العملية سوف تقوم بترسية عقد إلى موفر خدمات "واحد أو أكثر"، وهو ما قد يؤثر على تحديد الأسعار. هل يمكن لـ ICANN توفير أي إرشاد إضافي فيما يتعلق بهذا الأمر؟

وفقًا لما هو مطلوب في Q.24 وQ.25 وQ.26، يتعين على الموردين تقديم أسعار مستقلة لكل بند من البنود المذكورة في القائمة.

السؤال 5 هل مطلوب إجراء عملية الاختبار لكل موفر خدمة سجل نهائي، أو حسب كل مقدم طلب؟

يجب عل موفر عملية الاختبار التحقق من أن كل مقدم طلب قد أوفى بالتزامه لإنشاء عمليات السجل طبقًا لدليل مقدمي طلبات gTLD أو AGB.

السؤال 6 إذا سلمنا بأن هناك حوالي 1400 سلسلة فريدة يجري تقديم طلبات للحصول عليها، هل لا يزال من المتوقع أنه سيكون هناك حوالي 2000 اختبار بمعدل 20 اختبار في كل أسبوع؟

إننا نتوقع إجراء اختبار لعدد 1400 مقدم طلب بمعدل أولي بمقدار 20 اختبار في كل أسبوع. لاحظ رغم ذلك أننا نطالب أيضًا موفر الخدمة بأن تكون له القدرة على رفع المعدل ليصل إلى 100 اختبار في كل أسبوع، إذا طلبت ICANN ذلك.

السؤال 7 هل يمكن لـ ICANN تقديم عبارة محددة بأقل عدد متوقع من اختبارات ما قبل التفويض؟

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

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

يجب توضيح أية قيود تفرض على عملية توفير البرنامج أو الترخيص المتوفر وذلك في العرض المقدم. وكحد أدنى، تطالب ICANN أن تـُمنح ترخيصًا غير حصري ودائم وبدون أية رسوم لاستخدام البرنامج المقدم لأغراض عملية اختبار ما قبل التفويض.

السؤال 9 هل يشير "برنامج اختبار ما قبل التفويض" إلى كافة البرمجيات المستخدمة داخل نظام اختبار ما قبل التفويض أم البرمجيات المستخدمة في أداء الاختبارات الفنية فقط؟

يجب أن توفر كافة البرمجيات خدمة اختبار ما قبل التفويض.

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

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

السؤال 11 فيما يتعلق بالتقارير التي سيتم تقديمها من خلال نظام اختبار ما قبل التفويض، هل يتعين على موفر خدمة اختبار ما قبل التفويض تقديم تقرير لكل مقدم طلب، أم مجموعة فقط من التقارير الموحدة لكل منصة فنية لموفر خدمة السجل النهائي؟

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

السؤال 12 هل سيتم نزع الأهلية عن العروض المقدمة من مقدمي طلبات gTLD أو موفري خدمات السجل النهائي و/أو موفري خدمات DNS الذين تم التعاقد معهم من خلال مقدمي طلبات gTLD جديدة، أم سيتم توقيع جزاءات عليهم في عملية طلب تقديم العروض هذه؟

سوف تقبل ICANN العروض المقدمة من مقدمي طلبات gTLD الجديدة و/أو موفري خدمات السجلات النهائية لنطاقات gTLD الجديدة. ووفقًا لما هو مطلوب في Q.3 وQ.6، يتعين على مقدمي الردود الإفصاح عن كافة حالات تضارب المصالح بوضوح. علمًا بأن أي تضارب في المصالح لا ينزع الأهلية عن أي من مقدمي الردود تلقائيًا أو يوقع عليه جزاءات.

السؤال 13 هل ستعتبر ICANN أن مشغلي سجل الطوارئ النهائي أو اختصارًا EBERO من بين موفري خدمات اختبار ما قبل التفويض؟

نعم.

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

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

السؤال 15 هل يمكن لـ ICANN أن تسمح لجهتين المشاركة في عملية اختبار ما قبل التفويض (أي جهة واحدة تقوم بتطوير برنامج اختبار ما قبل التفويض واستضافة نظام اختبار ما قبل التفويض، وجهة أخرى تقوم بتوفير خدمات ما قبل التفويض)؟

نعم.

السؤال 16 هل ستنظر ICANN في ترسية العقد على مورد واحد من أجل الحصول على أ) المزايا الاقتصادية للتوسع في المشروع وب) نموذج الاختبار المتسق للجميع؟

إن ترسية المشروع على موفر خدمة واحد هو الخيار المفضل لـ ICANN. وعلى الرغم من ذلك، فإن ICANN على استعداد للنظر في الترسية على أكثر من مورّد واحد إذا كان هذا الخيار هو الأفضل.

السؤال 17 هل من الممكن تنفيذ اختبار واحد لكل موفر خدمة سجل نهائي (فمن شأن ذلك تقييد المتطلبات على حوالي 80 اختبار أو ما إلى ذلك)؟

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

السؤال 18 هل ستنظر ICANN في العروض التي تتناول مجموعة فرعية من عملية اختبار ما قبل التفويض؟ بمزيد من التفصيل: إذا سلمنا بالطبيعة الأكثر فنية والأهمية التي تتميز بها، هل ستنظر ICANN في العروض التي تتناول فقط مكونات DNS وDNSSEC في طلب تقديم العروض؟

لا.

السؤال 19 هل لدى ICANN ما تخشاه بخصوص تضارب المصالح مع خدمة تقييم الطلبات الأخرى التي تقدم إلى ICANN كجزء من برنامج gTLD الجديدة؟

لا.

السؤال 20 Q.26: بالنسبة لعملية التدقيق الميداني، كم شخصًا يجب أن يكون في عملية التدقيق الميداني الواحدة؟

يجب أن تشمل عملية اختبار ما قبل التفويض فريقًا يتمتع بالكفاءة اللازمة لإجراء عملية التقييم الميداني. ومن المتوقع أن يكون عدد قليل فقط من هذه الاختبارات مطلوبًا.

السؤال 21 هل يمكن لـ ICANN أن تتفضل بتوضيح عناصر عملية التدقيق التي من المقرر فحصها في عملية التدقيق الميدانية؟

يتعين على موفر خدمة اختبار ما قبل التفويض التحقق من التوافق مع المتطلبات الواردة في القسم 5.2 من دليل مقدمي الطلبات والتأكيدات ذات الصلة المنصوص عليها في طلب gTLD

السؤال 22 Q.26: هل تتوقع ICANN زيادة عدد الاختبارات بشكل كبير خلال فترة التعاقد؟

من المتوقع أن تتم عملية اختبار ما قبل التفويض بمعدل أولي يصل إلى 20 اختبار في الأسبوع، مع احتمالية زيادة النسبة إلى 100 اختبار في الأسبوع. وفقًا لما هو مذكور في Q.26(a)، يجب توفير الأسعار حسب كل اختبار.

السؤال 23 R.6: هل من المقبول عدم تنفيذ عملية التوثيق المتبادلة لوكلاء اختبار ما قبل التفويض إذا كان موفر خدمة اختبار ما قبل التفويض يعمل في بيئة شبكة داخلية/خاصة؟

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

السؤال 24 هل البروتوكول IPv6 أحد المطالب حيث إن "الاختبارات سيتم القيام بها عن طريق IPv4 وIPv6؟

من المقرر إجراء الاختبارات عن طريق IPv6 متى ما كان ذلك منطبقًا. لاحظ أن بعض الخدمات (على سبيل المثال DNS وWhois) يجب أن يتم توفيرها من خلال IPv6 (وفقًا لما هو منصوص عليه في المواصفة رقم 6 من اتفاقية gTLD الجديدة).

السؤال 25 R.18: ما المقصود بـ "عقد gTLD "؟

عقد gTLD هو "اتفاقية gTLD الجديدة" الموقعة.

السؤال 26 R.19: ما هي المحتويات الواردة في الحاشية السفلية المفقودة رقم 1؟

http://www.iana.org/procedures/idn-repository.html

السؤال 27 Q.26(b) غير مقدم بشكل صحيح

"اختبار عملية تحرير وكيل عهدة البيانات. من المتوقع أن تطالب ICANN بشكل رسمي 20 اختبارًا خلال مدة التعاقد".

السؤال 28 R.25: هل ستوفر ICANN خادم جذر لاختبار موثوق لمرساة DNSSEC؟

لا.

السؤال 29 R.26: هل تستطيع ICANN توفير المزيد من التفاصيل حول معايير نظام حماية البيانات DPS؟

حسب القسم 1.3 من المواصفة رقم 6 من الاتفاقية الأساسية، يجب أن يتوافق نظام حماية البيانات DPS مع طلبات التعليق RFC الواردة والتي تصف إطار عمل DPS (والموجود في الوقت الحالي في صيغة تمهيدية https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-dps-framework), وهو يصف عناصر التحكم والإجراءات الحاسمة في عملية الأمان لتخزين المواد الأساسية على سبيل المثال والوصول والاستخدام للمفاتيح الخاصة بها والقبول الآمن للمواد المفتاحية العامة للمسجلين.

السؤال 30 أسئلة حول القيود

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

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

السؤال 31 Q.5: هل هناك أية معلومات محددة لازمة فيما يتعلق بالمتعاقدين المدرجين من الباطن؟

وفقًا لما هو مذكور في Q.15(a)، يتعين على مقدمي الردود تقديم تقييم بتضارب المصالح استنادًا إلى القائمة الحالية من مقدمي طلبات gTLD الجديدة.

السؤال 32 في حالة فشل مشغلي TLD في أحد عناصر اختبارات ما قبل التفويض، هل يمكن لـ ICANN توضيح درجة الدعم المتوقع تقديمها من خلال موفر خدمة اختبار ما قبل التفويض إلى مشغل TLD، بخلاف خدمات ما قبل الاختبار؟

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

السؤال 33 بالنظر إلى مطلب إدراج الأسماء وعناوين يونيكاست IPv4/IPv6 لعُقد إنيكاست، ما هي الإجراءات التي ترغب ICANN في اتخاذها في حالة عدم قيام مشغل TLD - خلال العمليات العادية التي يقوم بها - بجعل الخوادم الفردية في مجموعات إنيكاست الخاصة به قابلة للوصول من خلال أي عنوان IP عام آخر بخلاف عنوان إنيكاست؟

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

السؤال 34 هل يمكن لـ ICANN التكرم بتوضيح عناصر عملية التدقيق التي من المقرر النظر فيها عند مراجعة اختبارات الأحمال المعتمدة ذاتيًا؟

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

السؤال 35 هل اختبار عملية تحرير وكيل عهدة البيانات مرتكزة حول إطلاق مستودع عهدة بيانات حالية من وكيل عهدة البيانات إلى ICANN أو إلى موفر اختبارات ما قبل التفويض؟

عملية اختبار الإطلاق مرتكزة على إطلاق المستودعات من وكيل عهدة بيانات gTLD إلى موفر خدمة اختبار ما قبل التفويض.

السؤال 36 فيما يتعلق بعهدة البيانات في البند 2.3.4.4، هل من المطلوب التحقق مما إذا كانت عهدة البيانات متوافقة مع المتطلبات من خلال برنامج محدد؟

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

السؤال 37 R.24: هل تشير العبارة "التحقق من أن البيانات يمكن إطلاقها في غضون 24 ساعة" إلى مراجعة يدوية لاتفاقية مستوى الخدمة SLA المبرمة بين موفر خدمة عهدة البيانات ومقدم الطلب (وفقًا لما هو مقدم من خلال مقدم الطلب)، أم يشير إلى اختبار فعلي يجب إجراؤه من خلال موفر خدمة اختبار ما قبل التفويض لضمان أن البيانات يتم إطلاقها وإعادتها بطريقة متوافقة مع متطلبات عهدة البيانات؟

في معظم الحالات تتوقع ICANN فقط مراجعة اتفاقية مستوى الخدمة، ولكن في بعض الحالات قد تطالب ICANN التحقق من القدرة الفعلية على الإطلاق لكل موفر خدمة عهدة بيانات. وفقًا لما أشير إليه في Q.26، تتوقع ICANN إجراء 20 اختبارًا خلال مدة التعاقد.

السؤال 38 هل من المقبول اختبار مستودعات عهدة البيانات الكاملة فقط؟

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

السؤال 39 R.19 وR.20: الرجاء توضيح المتطلبات الخاصة بتوثيق قائمة IDN

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

السؤال 40 R.13: هل يجري اختبار واجهة EPP فقط للتعرف على أوامر EPP المدرجة؟

لا، حيث يجب اختبار واجهة EPP لتحقيق التوافق المعياري مع المتطلبات المنصوص عليها في دليل مقدمي طلبات gTLD في القسم 5.2، أي "التحقق من التوافق بالنسبة لطلبات التعليقات المناسبة (والتي تشمل امتدادات EPP الخاصة بـ DNSSEC)".

السؤال 41 R.18: هل هناك أية اختبارات فنية يجب القيام بها لمراجعة امتدادات EPP الخاصة بمقدم الطلب؟

لا.

السؤال 42 2.3.4.1: هل هناك مطلب باختبار واجهة ويب Whois عبر HTTPS؟

في حالة توفير واجهة Whois على الويب عبر HTTPS فيجب اختبارها.

السؤال 43 Q.26: هل يشير "تدقيق اختبار الأحمال" إلى المراجعة اليدوية لوثائق الاعتماد الذاتي لمقدم الطلب، أو أنه يشير إلى الاختبارات الفعلية التي يتعين على موفر خدمة اختبار ما قبل التوثيق تشغيلها من أجل توثيق التأكيدات التي قام بها مقدم الطلب.

Q.26(c,d,e) يشير إلى اختبارات الأحمال الفنية الفعلية التي يتم إجراؤها من خلال موفر خدمة اختبار ما قبل التفويض. ومن المتوقع أن يكون عدد قليل فقط من هذه الاختبار مطلوبًا.


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