Skip to main content
Resources

إجراءات الطلبات المجتمعية لتغيير نطاق gTLD

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

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

مقدمة

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

نشرت منظمة ICANN مسودة الإجراءات للتعليق العام في شباط (فبراير) 2018. بعد النظر في الوثائق المستلمة، استنتجت كل من منظمة ICANN ومجموعة العمل أن التعليقات لم تشر إلى أن الإجراءات متضاربة مع السياسات الموجودة والتحديثات التي تتم مناقشتها للإجراء. فوق ذلك، بتاريخ 26 نيسان (أبريل) 2018، اتفق مجلس GNSO [بصيغة PDF, 574 KB] على أنه "يجب على منظمة ICANN مواصلة التعامل مع عملية طلب مجتمعية لتغيير نطاق gTLD على أنها مسألة تنفيذية." تم الاتفاق على هذه النسخة المنشورة من الإجراءات من قبل مجموعة العمل ومنظمة ICANN في نيسان (أبريل) 2018.

الإجراءات

الإصدار: أبريل/نيسان 2018

طلب تغيير مجتمعي لنطاق gTLD

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

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

1. التعريفات

1.1 يتم تعريف نطاق gTLD للمجتمع على أنه نطاق gTLD لديه اتفاقية سجل مع ICANN تتضمن البند 12 مع القسم بعنوان "سياسات تسجيل المجتمع" أو "سياسات TLD."

2.1 يتم تعريف تغيير مجتمعي لنطاق gTLD على أنه تغيير على البند 12 من اتفاقية السجل مع ICANN.

3.1 يتم تعريف مجتمع TLD بواسطة متطلبات الأهلية المحددة في البند 12 من اتفاقية السجل مع ICANN.

4.1 يتم تعريف مشغل السجل على أنه كيان مع اتفاقية سجل لإدارة نطاق gTLD للمجتمع.

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

2. إجراءات طلب تغيير مجتمعي لنطاق gTLD

1.2 يقدم مشغل السجل طلب تغيير مجتمعي لنطاق gTLD ("الطلب")

يجوز لمشغل السجل تقديم طلب في أي وقت. يجب تقديم الطلب خطيًا إلى ICANN مشفوعًا باستبيان طلب التغيير المجتمعي لنطاق gTLD (راجع الملحق A) [بصيغة PDF, 38 KB]، كما يجب أن يتضمن وثائق دعم التغيير من قبل مجتمع TLD (بما في ذلك الهيئات التي تمثل أي توسع مقترح لمجتمع TLD ، إن وجد)، وكذلك من قبل الهيئات الحكومية الممثلة، إن وجدت.

2.2 مراجعة ICANN التمهيدية للطلب

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

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

3.2 فترة التعليقات لطلب التغيير

بعد المراجعة التمهيدية للطلب من قبل منظمة ICANN ، ستقوم ICANN بنشر الطلب ومسودة التعديلات للتعليقات العامة لمدة 30 يومًا.

4.2 فترة رد مشغل السجل

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

3. مراجعة ICANN والقرار

1.3 مراجعة ICANN

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

  1. وصف مجتمع TLD – هل هناك وصف واضح لمتطلبات أهلية TLD وكيف تتأثر بالطلب؟
  2. الدليل على توعية TLD ودعمها – هل هناك دليل معقول على التواصل مع مجتمع TLD يبين الجهود التي يبذلها مشغل السجل "لتشغيل TLD بطريقة تسمح لمجتمع TLD بالمناقشة والمشاركة في وضع وتعديل السياسات والممارسات لنطاق TLD "؟ هل هناك دليل معقول على دعم مجتمع TLD للطلب؟
  3. الفوائد التي تعود على مجتمع TLD – هل الردود المقدمة في 3.1 و4.1 من استبيان طلب التغيير تشرح بشكل كاف كيفية إفادة الطلب لمجتمع TLD ؟ هل السماح بالتغيير سيؤدي إلى إلحاق الضرر بمجتمع TLD ؟
  4. المخاوف التي أثيرت خلال فترة التعليقات – هل تمت إثارة مخاوف مهمة خلال فترة التعليقات والتي حددت الضرر على مجتمع TLD أو مجتمع الإنترنت؟ هل قدم مشغل السجل ردًا مناسبًا على هذه المخاوف؟ قد يتضمن الرد المناسبة أدلة داعمة لمشغل السجل تفيد بأنه (1) لن يكون هناك أي ضرر على سمعة المجتمع؛ أو (2) لا يوجد تدخل في الأنشطة الأساسية للمجتمع؛ أو (3) لا يوجد أي ضرر اقتصادي على المجتمع.

2.3 قرار ICANN

1.2.3 الموافقة

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

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

2.2.3 الرفض

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

الملحق أ: استبيان طلب التغيير المجتمعي لنطاق gTLD [بصيغة PDF, 38 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."