Skip to main content
Resources

تغيير الترتيب الأساسي للتعاقد من الباطن (MSA)

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

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

لمحة عامة

توفر صفحة الويب هذه إرشاد لمشغلي السجلات بشأن طلب موافقة مؤسسة ICANN لتغيير الترتيب الأساسي للتعاقد من الباطن (MSA).

يعتبر أي ترتيب للتعاقد من الباطن متعلق بأي وظيفة حرجة على النحو المحدد في المواصفة 10، القسم 6 من اتفاقية السجل بمثابة ترتيب أساسي للتعاقد من الباطن (MSA). ويُشار إلى المقاولين من الباطن الذين يقومون بتشغيل وظيفة (وظائف) حرجة واحدة أو أكثر باسم إما مشغل سجل خلفي أو مزود خدمة سجل (RSP).

تشمل الوظائف الحرجة الخاضعة لعملية تغيير الترتيب الأساسي للتعاقد من الباطن MSA ما يلي:

  • تحويل ترميز بروتوكول نظام اسم النطاق DNS إلى اسم
  • منطقة الامتدادات الأمنية لنظام اسم النطاق DNSSEC الموقعة بشكل صحيح (حال تقديم الامتدادات الأمنية لنظام اسم النطاق DNSSEC بمعرفة السجل)
  • نظام التسجيل المشترك (SRS) يتم عادة عن طريق بروتوكول التزويد المرن (EPP)
  • خدمات دليل بيانات التسجيل (RDDS)، على سبيل المثال، بروتوكول الوصول إلى بيانات التسجيل (RDAP) ونظام WHOIS المقدم عبر المنفذ 43 ومن خلال خدمة قائمة على الويب.

من خلال عملية تغيير الترتيب الأساسي للتعاقد من الباطن MSA، تقوم مؤسسة ICANN باختبار وتقييم مزود خدمة السجل RSP للتأكد من أن لديه القدرة على تشغيل نطاق المستوى الأعلى (TLD) بطريقة مستقرة وآمنة. وتطلب مؤسسة ICANN أيضًا من مشغلي السجلات تقديم خطة انتقال لتوضيح طريقة تنسيق وإكمال نقل الخدمات من مزود خدمة سجل RSP إلى آخر بطريقة مستقرة وآمنة.

وفيما يلي جدول زمني عام لعملية الترتيب الأساسي للتعاقد من الباطن MSA. انقر هنا للحصول على سير عمل للعملية أكثر تفصيلًا.

تغيير الترتيب الأساسي للتعاقد من الباطن (MSA)

قبل التقديم: الاعتبارات والاستعدادات

تسلط الخطوات التالية الضوء على الاعتبارات والاستعدادات الرئيسية التي يجب على السجلات إجراؤها قبل تقديم طلب تغيير الترتيب الأساسي للتعاقد من الباطن MSA في بوابة خدمات التسمية (NSp).

الخطوة 1: ضع في الاعتبار المعاملات ذات الصلة قد يؤدي تغيير مزود خدمة السجل RSP الخاص بك إلى تغييرات أخرى مرتبطة. وضع في اعتبارك على سبيل المثال:

  • هل ستجري أي تعديلات على خدمات السجل في المستند أ من اتفاقية السجل (RA) نتيجة لتغيير مزود خدمة السجل RSP الخاص بك؟
  • هل ستتنازل عن نطاق المستوى الأعلى TLD إلى كيان مختلف بالإضافة إلى تغيير الترتيب الأساسي للتعاقد من الباطن MSA الحالي؟

التعديلات على خدمات السجل: إذا كان مزود خدمة السجل (RSP) المقترح يقدم خدمات سجل مختلفة عن مزود خدمة السجل RSP الحالي (على سبيل المثال، حجب التسجيل، لغات/نصوص اسم النطاق المدوّل (IDN، فستحتاج إلى تحديث لغة الملحق أ الخاص بك عن طريق تقديم طلب سياسة تقييم خدمات السجل (RSEP) قبل تقديم طلب تغيير الترتيب الأساسي للتعاقد من الباطن MSA. ونوصيك أن تطلب مكالمة مشاورة لمناقشة الخطوات المناسبة.

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

الخطوة 2: اعرف جدولك الزمني. اسمح لنفسك بما لا يقل عن 7-12 أسبوعًا لإتمام طلب تغيير الترتيب الأساسي للتعاقد من الباطن MSA من مؤسسة ICANN. وادرج في جدولك الزمني متطلبات مؤسسة ICANN لمعالجة تغيير الترتيب الأساسي للتعاقد من الباطن MSA، بما في ذلك الاختبار، فيما يتعلق باحتياجات ومتطلبات عملك. على سبيل المثال، ضع في اعتبارك:

  • هل ستنتهي اتفاقيتك مع مزود خدمة السجل RSP الحالي قريبًا؟
  • كم من الوقت سيستغرق الانتقال من مزود خدمة السجل RSP الحالي إلى مزود خدمة السجل RSP الجديد؟

الخطوة 3: نظِّم مكالمة مشاورة مع مدير حسابك للتأكد من فهمك للعملية. ويمكن لمدير الحساب تقديم نظرة عامة شاملة على ما تتضمنه العملية، وإبلاغك بالوثائق والاختبارات المطلوبة، والمساعدة في ضمان فهمك لما هو مطلوب لبدء طلب تغيير الترتيب الأساسي للتعاقد من الباطن MSA. وسيؤدي ذلك إلى جعل العملية أكثر كفاءة حالما تكون مستعدًا لإرسال طلبك.

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

المصادر

المتطلبات باختصار (حسب نوع تغيير الترتيب الأساسي للتعاقد من الباطن MSA)

المتطلب مزود خدمة سجل RSP معلوم مزود خدمة سجل RSP مجهول*

التقديم غير الرسمي

التقييم الفني

(تكلفة التقييم التقديرية 14300 دولار أمريكي)

الموافقة على خطة الانتقال

اختبار نظام التسجيل

تدريب المحاكاة

التقديم الرسمي/مراجعة ICANN

قرار ICANN

انتقال مزود خدمة السجل RSP

*لا يدعم حاليًا نطاقات gTLD الجديدة

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