Skip to main content

تنفيذ مرجع المصدر المفتوح لخادم RESTful Who is الخاص بأسماء النطاقات – إجابات للأسئلة المتعلقة بطلب تقديم العروض (RFP)

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

ويرجى من المشاركين الرد على طلب تقديم العروض من خلال الرد على: rws-opensource@icann.org. انتهت الفترة المتاحة لطرح الأسئلة حول طلب تقديم العروض (RFP). موعد الرد النهائي على طلب العروض هو 15 يونيو 2012.

تم تقديم الستة والعشرين سؤالاً التالية إلى rws-opensource@icann.org ما بين 16 مايو و5 يونيو 2012. ويتم نشر المجموعة الكاملة من الأسئلة والإجابات على موقع الويب الخاص بـ ICANN لتعم المنفعة على جميع المشاركين.

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

المتطلبات

سؤال: في قسم "المتطلبات"، يحتوي طلب تقديم العروض على رابط http://tools.ietf.org/id/weirds. ضمن هذا العنوان، يتم سرد قليل من المسودات التي لا ترتبط بشكل تام بنموذج الكائن Whois الخاص باسم نطاق TLD التقليدي (الذي يسمح عادةً باستعلامات المسجلين والنطاقات والمضيفين وجهات الاتصال في مخزن الكائن المحلي الخاص بالسجل). على وجه الخصوص، يشير draft-fiorelli-weirds-rws إلى قاعدة البيانات RIPE كبديل، ويشير draft-newton-et-al-weirds-rir-json-response وdraft-newton-et-al-weirds-rir-query إلى "سجلات الإنترنت الإقليمية" (RIRs)، ويشير draft-newton-weirds-arin-whoisrws إلى Whois ARIN، ويتعامل draft-lacnic-weirds-restwhois-redirects مع إعادة التوجيه من خادم Whois العام. أما بالنسبة لمتطلبات طلب تقديم العروض، هل نفترض أن الوثائق المتبقية فقط (draft-designteam-weirds-using-http وdraft-kucherawy-weirds-requirements وdraft-sheng-weirds-icann-rws-dnrd) – اثنان منها مشار إليهما صراحةً في طلب تقديم العروض في قسم "المراجع" – وثيقة الصلة كمتطلبات لتنفيذ المرجعية؟ إذا لم يكن كذلك، يرجى تحديد أي من المسودات الأخرى الموجودة في http://tools.ietf.org/id/weirds مطلوبة أيضًا ليتم دعمها ولماذا.

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

سؤال: المجموعة WEIRDS تنشئ معياري IETF للاستعلام عن بيانات RIR. ومعايير الاستعلام عن بيانات تسجيل اسم النطاق. هل يجب عند تنفيذ المرجعية تطبيق كل هذه المعايير أم فقط المعايير ذات الصلة ببيانات تسجيل اسم النطاق.

الإجابة: نظرا إلى وجود 5 سجلات إنترنت إقليمية فقط ويشارك معظمها بالفعل في WEIRDS ويعملون على تطبيقاتهم الخاصة بهم، فإننا نركز على جانب اسم المجال فقط. مع وجود مسجلين 1K + ICANN معتمدين، ومئات من gTLDs الجديدة بالإضافة إلى gTLDs الحالية بالإضافة للقيود على التمويل قررنا التركيز على خادم النشر الرئيسي.

سؤال: في القسم 2.4.4، جاء فيه أنه ينبغي أن يتضمن التطبيق منفذ 43 "وكيل" الذي يستخدم RESTful Whois للرد على الطلبات والقيام بترجمة استفسارات المنفذ 43 والإجابة عليها وفقًا لذلك. ورغم أن هذا منهج محتمل، يتضمن تنفيذ خادم Whois الحالي تنفيذ المنفذ 43 والذي يستطيع الوصول *مباشرة* إلى قاعدة بيانات خادم Whois (أي أنه لا يقدم الطلبات/الردود من/إلى واجهة مختلفة)، والذي يسمح بالحصول على أداء أفضل بكثير لمنفذ 43. هل من الجيد لتنفيذ المرجع استخدام هذا المنهج المباشر بدلاً من أسلوب "الوكيل" الموضح في طلب تقديم العروض، بينما يقدم التنفيذ منفذ 43 التابع لـ Whois الذي يجيب على الاستعلامات بنفس الأسلوب المُتبع في وضع "الوكيل"؟

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

سؤال: هل يخدم تنفيذ المرجع كلاً من نطاقات gTLD بالإضافة إلى ccTLD؟

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

سؤال: خادم WHOIS هو في الأساس نظام استعلام لقاعدة بيانات. قاعدة البيانات هي مجموعة من المعلومات التي تكون لدى السجل أو المسجل حول المجالات، ولغة الاستعلام كل ما يقبله خادم WHOIS، ويتم تحديد الناتج من قاعدة البيانات الأساسية. ماذا تحتوي قاعدة بيانات، وما هي الاستعلامات التي تدعمها لغة الاستعلامات؟

في حين أنه من الممكن استشعار الإجابة على هذه الأسئلة من ملاحق WHOIS الحالية لاتفاقيات سجل WHOIS المليئة، فإن الملاحق ليست سيانً. على سبيل المثال، تحدد اتفاقية .INFO استعلامات التطابق الجزئي، في حين أن اتفاقية .BIZ لا تقوم بذلك. يحتوي سجل .AERO على حقل ENS_Authid، ولديه بطاقات خصوصية، في حين أن .ASIA يحتوي على ENS_Authid ولكن ليست لديه بطاقات خصوصية. تشير اتفاقية .XXX إلى معلومات DNSSEC، بينما الاتفاقيات السابقة لا تقوم بذلك. يشير اتفاق .POST إلى حقل Maintainer (القائم بالصيانة) بدلاً من حقل Email (البريد الإلكتروني) في الاتفاقيات الأخرى. اتفاق .NAME يصف مستويات متعددة من الوصول إلى الموارد وكائنات التسجيل الواقي.

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

الإجابة: يرجع ما يوجد في قاعدة البيانات الأساسية والاستعلامات التي يتم دعمها إلى جهاز إصدار السياسات الخاصه بالتسجيل/المسجل كما أبرزت في توضيحك الموجود أعلاه.

وبعبارة أخرى، نحن نتوقع أن يكون التنفيذ مفتوح المصدر RWS قادرًا على التعامل (قابلة للتهيئة) بشأن الحقول التي تتيح الاستعلام.

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

الإجابة: من المتوقع أن يتم تحديد هيكل الناتج في بروتوكول IETF. في الوقت الراهن تحتوي مسودات الإنترنت المذكورة في طلب تقديم العروض على هيكل لأسماء النطاقات.

سؤال: هل هناك أي متطلبات محددة لأداء النظام؟ على سبيل المثال، هل هناك اشتراط للحد الأدنى للطلبات لكل ثانية بمواصفات أجهزة معينة؟

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

سؤال: هل هناك قائمة محددة لترميزات المعتمدة لبيانات WHOIS التي يجب دعمها؟ على سبيل المثال، هل سيكون كافيًا تقييد الطلبات والإجابات بـ UTF-8 أم هل يجب أن يكون هناك دعم لعدد كبير من الترميزات؟ هل من الممكن أن تحتاج بيانات السجل/المسجل للتحويل بين الترميزات؟

الإجابة: هذا يعتمد على البروتوكول الذي لم يتم تحديده حتى الآن. ونتوقع أن يتطلب UTF-8، ولكن قد يدعم أيضا ترميزات أخرى.

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

الإجابة: على غرار مسألة الترميزات، هذا يعتمد على ما يتطلبه البروتوكول.

سؤال: هل يوجد متطلب أدنى لخيارات السياسة؟ يحدد RFI ما يلي: "ينبغي على التنفيذ أن يسمح بتهيئة المعلمة الخاصة بخيارات السياسة "لكن يُعد هذا واسعًا إلى حد ما. هل توجد أمثلة على أنواع السياسات التي قد تكون مطلوبة؟ على سبيل المثال، هل تتضمن هذا سياسات مثل التحكم بالطلب، تصفية الردود (مثل التفاصيل الموسعة لطلبات whois من عملاء محددين)، وما إلى ذلك؟

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

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

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

سؤال: هل هناك أي متطلبات بشأن الإدارة الشاملة للمشروع أم سيُترك ذلك للمتعاقد؟ على سبيل المثال، أين ستتم استضافة الرمز؟ ماذا عن تتبع المشكلة، ومسارات عمل التطوير؟

الإجابة: لا، لا توجد متطلبات في هذا الشأن خلاف ما هو موضح في طلب تقديم العروض.

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

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

سؤال: من حيث تهيئة المعلمة وفقا للمادة 2.5. من طلب تقديم العروض هل يجب تقديم التنفيذ فقط لإمكانية أن تجري تهيئته أم يكون ICANN مفتوحا للمقترحات؛ على سبيل المثال أن يكون واجهة لتهيئة مختلف الخيارات التي يمكن بالفعل أن تدرج في التنفيذ؟ هل يمكن تقديم هذا المنهج كوحدة إضافية واختيارية؟

الإجابة: نحن منفتحون على الاقتراحات.

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

الإجابة: تتوفر اللغة الإنجليزية الآن على الأقل، وسيكون من الجيد الحصول على لغات أخرى.

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

الإجابة: نعم، نحن نتقبل الاقتراحات. ولكن لتوضيح فكرة تضمين رمز الجهة الخارجية، فهي في حالة أن يكون من المفيد (من ناحية النفقة) بالنسبة للمزود أن يستخدمها بدلاً من القيام بالعمل من البداية.


المخطط الزمني للمشروع

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

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

سؤال: ما مدة الوقت المتوقع بين إصدارات المواصفات المكررة وتسليم التغييرات للمشروع؟

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


تقييم طلب تقديم العروض والتعاقد

سؤال: من هم الجمهور الذي يراجع طلب تقديم العروض؟ ولجنة التحديد؟

الإجابة: تتكون لجنة التحديد من خبراء فنيين سيقومون بمراجعة العرض.

سؤال: هل يتوفر مبلغ لميزانية المشروع؟

الإجابة: لدينا بعض من ميزانية ما تبقى من العام المالي الحالي وطلبنا المزيد للعام المالي القادم. ويسعدنا مراجعة العروض من المزودين المهتمين.

سؤال: ما الميزانية الإجمالية للمشروع؟ وهل تهتم ICANN بعروض الأسعار الثابتة أم أنها تتقبل المناهج الممرحلة حيث يتم جمع المتطلبات أولاً وتحديدها بالإضافة إلى النفقات ثم تقديرها أو عرضها على أساس العثور على مثل هذا التداخل مع ICANN؟

الإجابة: يسعدنا مراجعة العروض من المزودين المهتمين. ومستعدون لسماع الخيارات.

سؤال: هل هناك نوع عقد مفضّل (الوقت والمواد أو السعر الثابت المستقر أو ما إلى ذلك)؟

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

سؤال: في قسم "التقييم والإصدار"، يشير RFP إلى أن التوقيت الدقيق للإصدار قد يعتمد على عملية التوحيد القياسي لـ IETF. ما الطريقة التي تتوقع ICANN بها توقيت الإصدار لتعتمد على عملية IETF؟ بشكل محدد، من المتوقع الإصدار في قرابة شهر أو ما إلى ذلك من موعد استجابة RFP وإلا فقد يتم تأخيره إلى ما بعد نوفمبر 2012 أو أغسطس 2013 (نطاق التواريخ المتوفرة في النقاط الهامة الخاصة بـ WEIRDS WG)؟

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


أسئلة أخرى

سؤال: يتطلب طلب تقديم العروض "وجوب ملاءمة المنتج النهائي للعروض ذات الصلة والتي تم تقييسها في WEIRDS IETF WG." فهل تتوقع ICANN أو تتطلب مشاركة المتعاقد و/أو المساهمة في WEIRDS WG لضمان بقاء مشروع المصدر المفتوح على خط واحد مع WG؟

الإجابة: لا يتطلب الأمر المساهمة ولكن قد يكون من المفيد للمساهم متابعة قائمة مراسلات WEIRDS على الأقل.

سؤال: قامت ICANN بنشر خارطة طريق لتطبيق SAC 051 (http://www.icann.org/ar/news/announcements/announcement-6-04jun12-ar.htm)، والتي تتضمن عملIETF على بروتوكول جديد ولكن أيضًا تتوقع مساهمات من جمعية ICANN، وبشكل خاص ccTLD وgTLD والمسجلون وGNSO: "توصي خارطة الطريق تلك بمنهج ثابت متعدد للتأقلم مع استبدال بروتوكول WHOIS." هل نطاق مشروع التطبيق المرجعي مقيّد بمواصفات البروتوكول الذي تم إصداره بواسطة IETF؟

الإجابة: نعم، يجب أن تتلاءم مع طلبات تقديم العروض التي تم إصدارها بواسطة IETF، ولكن من المتوقع أيضًا أن تكون جودة الإنتاج.

سؤال: هل من المتوقع تضمين السجلات أثناء عمليات التطوير والاختبار؟

الإجابة: قد يتم تضمين بعض السجلات والمسجلين، ولكن لا ينبغي على المزودين المحددين الاعتماد على ذلك.


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