Skip to main content
Resources

سياسة تقييم خدمات السجل

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

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

خدمات السجل وعملية التقييم

(الفترة من 25 يوليو 2006، تاريخ السريان، 15 أغسطس 2006)

1. التعريفات

1.1 خدمات السجل يمكن تحديد خدمات السجل كما يلي:

  1. ‌تلك الخدمات التي تكون كلاً مما يلي: (1) يقوم مشغلي السجل بالمهام التالية: استلام البيانات من المُسجلين فيما يتعلق بتسجيل أسماء النطاقات وخوادم الأسماء؛ وتزويد المُسجلين بمعلومات الحالة المتعلقة بخوادم المنطقة لنطاق TLD؛ ونشر ملفات منطقة TLD؛ وعملية خوادم منطقة مزود الامتداد؛ ونشر الاتصال والمعلومات الأخرى فيما يتعلق بعمليات تسجيل خادم اسم النطاق في TLD كما هو مطلوب في اتفاقية مزود الامتداد؛ و(2) المزوَدة من قبل مشغل مزود الامتداد في التاريخ الفعلي لاتفاقية مزود الامتداد، حيث يمكن أن تكون الحالة على النحو التالي؛

  2. ‌منتجات أو خدمات أخرى ينبغي على المشغل تزويدها بسبب تأسيس سياسة الإجماع (كما هو مبين أعلاه)؛

  3. ‌أية منتجات وخدمات أخرى لا يمكن تزويدها إلا من قبل مشغل السجل، بسبب تصنيفه كمشغل سجل.

  4. ‌د. التغييرات الجوهرية على أية خدمة سجل ضمن نطاق (أ) أو (ب) أو (ج) أعلاه. (تأتي التعريفات من اتفاقية .NET، كما تم تحديدها بمعرفة مجلس إدارة ICANN في 8 نوفمبر 2005، http://www.icann.org/minutes/resolutions-08nov05.htm).

1.2 الحماية - التأثير على الحماية من قبل خدمة السجل المقترحة يعني (أ) غير المفوض من الكشف أو التعديل أو الإدراج أو إتلاف سجلات البيانات، أو (ب) الولوج غير المفوض أو كشف المعلومات أو الموارد على الإنترنت من قبل أنظمة تعمل وفقاً لجميع المعايير المعمول بها. (التعريفات واردة من توصية GNSO، المتوفرة على http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.3 الاستقرار - يعني التأثير على الاستقرار أن خدمة السجل (1) غير ملتزمة بالمعايير المناسبة القابلة للتطبيق والتي تم اعتمادها ونشرها بواسطة هيئة معايير تم تأسيسها جيدًا ومعترف بها ومعتمدة، مثل Standards-Track (تتبع المعايير) أو Best Current Practice RFCs (أفضل الممارسات الحالية لطلبات التعليق) المناسبة والتي ترعاها IETF أو (2) يمكن لها أن تنشئ حالة تؤثر بصورة عكسية على الإنتاجية أو زمن الاستجابة أو الاتساق أو ترابط الاستجابات بخوادم الإنترنت أو النظم الأخيرة حيث تعمل وفقًا للمعايير المناسبة القابلة للتطبيق والتي تم اعتمادها ونشرها بواسطة هيئة معايير تم تأسيسها جيدًا ومعترف بها ومعتمدة مثل Standards-Track (تتبع المعايير) أو Best Current Practice RFCs (أفضل الممارسات الحالية لطلبات التعليق) المناسبة وتعتمد على معلومات التفويض الخاصة بمشغل السجل أو خدمات التوزيع الخاصة به. (التعريفات واردة من توصية GNSO المتوفرة على http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

1.4 لجنة التقييم التقني لخدمات السجل - يجب أن تتشكل لجنة التقييم التقني لخدمات السجل من مجموع 20 شخص خبير بتصميم وإدارة وتنفيذ الأنظمة المعقدة والمعايير- البروتوكولات المستخدمة في البنية التحتية للإنترنت وDNS (أي "لجنة التقييم التقني لخدمات السجل"). سيختار أعضاء لجنة التقييم التقني لخدمات السجل رئيسها. سيكون رئيس لجنة التقييم التقني لخدمات السجل هو شخص توافق عليه كلاً من ICANN والدائرة الانتخابية للسجل للمنظمات الداعمة المسئولة حينها عن سياسات سجل أسماء النطاقات الأعلى. يجب أن يحرر جميع أعضاء لجنة التقييم التقني لخدمات السجل ورئيسية اتفاقية تلزمهم بالنظر بالمسائل التي يتم تقديمها إلى اللجنة بشكل محايد وطبقاً لتعريفات الحماية والاستقرار. لكل مسألة تتم إحالتها إلى لجنة التقييم التقني لخدمات السجل، يجب أن يختار الرئيس عدداً لا يزيد عن خمسة أعضاء من لجنة التقييم التقني لخدمات السجل لتقييم المسألة التي تمت إحالتها، ويجب ألا يكون أحداً منهم ذو تضارب مصالح تنافسي أو مالي أو قانوني معها، ومع الأخذ بعين الاعتبار المسائل التقنية الخاصة التي تثيرها الإحالة. (التعريفات واردة من توصية GNSO، المتوفرة على http://gnso.icann.org/issues/registry-services/final-rpt-registry-approval-10july05.htm#5).

2. عملية النظر بخدمات السجل المقترحة

2.1 تفكير مشغل السجل أو المنظمة الراعية بخدمة السجل الجديدة

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

2.2 تحديد ما إذا كان التغيير يتطلب مراجعة ICANN

يحدد مشغل سجل gTLD أو المنظمة الراعية، بالتشاور مع ICANN كما هو مبين في القسم 2.4، ما إذا كان التغيير على الخدمة سيتطلب الموافقة بناءً على العقد بين ICANN ومشغل السجل (راجع ملاحظة التنفيذ الخطوة 1).

2.3 تقديم المعلومات حول التغيير المقترح إلى ICANN

تشجع السياسة مناصري خدمة السجل الجديدة على التنسيق مع ICANN قبل إرسال طلب خدمات سجل جديدة. إن الهدف من سياسة تقييم خدمات السجل وعملية الموافقة هو صنع أجواء تشجع مشغلي سجل gTLD على مناقشة أية تغييرات قد تؤثر على أطراف ثالثة مع ICANN قبل إجرائها.

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

2.4 فترة القرار المبدئي

بعد الإبلاغ الخطي من قبل مشغل السجل إلى ICANN بأن مشغل السجل قد يجري تغييراً على خدمات السجل ضمن نطاق الفقرة السابقة:

  1. ‌أأمام ICANN فترة 15 يومًا تقويميًا لاتخاذ "قرار مبدئي" حول ما إذا كانت خدمة السجل تتطلب المزيد من النقاش من قبل ICANN لأنها تحدد بشكل منطقي ما إذا كانت مثل خدمة السجل هذه: (1) قد تثير مسائل حماية أو استقرار ذات أهمية، أو (2) قد تثير مسائل تنافس ذات أهمية.

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

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

  4. ‌ إذا حددت ICANN خلال فترة 15 يوماً ميلادياً "القرار المبدئي" بأن خدمة السجل المقترحة، لا تثير مسائل حماية أو استقرار (كما هو مبين في القسمين 1.3 و1.4)، أو مسائل تنافس، يصبح لمشغل السجل الحق بنشرها عند اتخاذ مثل هذا القرار.

    إذا كان تنفيذ مثل هذه الخدمة المقترحة يتطلب تغييراً جوهرياً على اتفاقية السجل، ستتم إحالة القرار المبدئي إلى مجلس إدارة ICANN (راجع ملاحظة التنفيذ الخطوات 3-5).

2.5 مسائل التنافس

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

يجب نشر مثل الاتصالات المتعلقة بالإحالة هذه خلال على موقع ICANN الإلكتروني عند وقت الإرسال.

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

2.6 مسائل الحماية والاستقرار

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

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

عند تقييمها لخدمة السجل المقترحة، يجب على لجنة التقييم التقني لخدمات السجل تقديم تقرير حول احتمالية وأهمية تأثيرات خدمة السجل المقترحة على الحماية أو الاستقرار، وذلك يشمل ما إذا كانت خدمة السجل المقترحة تشكل مخاطرة معقولة بالتأثير العدائي ذو المعنى على الحماية أو الاستقرار (راجع ملاحظة التنفيذ الخطوات 5-7).

2.7 قرار مجلس ICANN

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

يجب تقديم نسخة غير محذوفة من تقرير لجنة التقييم التقني لخدمات السجل إلى مشغل السجل عند نشر التقرير. يحق لمشغل السجل الرد على تقرير لجنة التقييم التقني لخدمات السجل أو الإرسال إلى مجلس إدارة ICANN معلومات أو تحاليل إضافية تتعلق بالتأثير المحتمل لخدمة السجل على الحماية أو الاستقرار (راجع ملاحظة التنفيذ الخطوات 7-8).

3. إعادة النظر

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

وتعتبر قوانين ICANN الداخلية هي المصدر الرسمي للمعلومات فيما يتعلق بعملية إعادة النظر (انظر الفقرة الرابعة: القسم 2 http://www.icann.org/general/bylaws.htm#IV). ويتم تطبيق إعادة النظر في إجراءات فريق العمل التي تتناقض مع سياسة ICANN، أو في إجراء مجلس الإدارة الذي اتخذته دون اعتبار للمعلومات المادية. كما تتوفر معلومات عمليات إعادة النظر السابقة على http://www.icann.org/committees/reconsideration.

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