دليل غير المحامين لاتفاقية اعتماد المسجل في تاريخ مايو 2009*
دليل غير المحامين لاتفاقية اعتماد المسجل في تاريخ مايو [PDF, 260 KB]
تم العمل على المستند وإخراجه استجابة لطلب اللجنة الاستشارية العامة (ALAC) لدليل لغير المحامين حول اتفاقية اعتماد المسجل الخاصة بـ ICANN (RAA) على موقع الويب http://www.atlarge.icann.org/correspondence/correspondence-01oct09-en.htm. كما يتضح من الطلب فإن RAA تمثل مستنداً قانونياً بين كل من ICANN والمسجلين يقع تحت طائلة قانون ولاية كاليفورنيا. كنتيجة، فإن هؤلاء ممن هم ليسوا جزءاً من هذه الاتفاقية أو غير معنيين بالنظام القضائي بالولايات المتحدة الأمريكية وغير المحامين و/أو غير المتحدثين باللغة الإنجليزية في الأساس قد يجد كل هؤلاء صعوبة في تفهم الالتزامات التي اتفق عليها ICANN والمسجلين. ولا يغير هذا الدليل أو يعدل من RAA بأية طريقة كما أنه لا يعتبر بمثابة تفسير قانوني لـ RAA.
يعتبر هذا الدليل بمثابة ملخص أساسي لـ RAA حتى تاريخ مايو 2009 (وهذا الملخص متوفر على موقع الويب http://www.icann.org/en/registrars/ra-agreement-21may09-en.htm ). لا يزال بعض المسجلين يعملون على اتفاقية RAA بموجب اتفاق مايو 2001 (وهي متوفرة على موقع الويب http://www.icann.org/registrars/ra-agreement-17may01.htm )، لذا فإن بعضاً من هذه النقاط الموضحة هنا لن يتم تطبيقها على كافة المسجلين خلال هذه الفترة. يمكنك التعرف على المسجلين ممن يعملون على اتفاقية RAA لعام 2009 عبر مراجعة قائمة المسجل المعتمد (متوفرة على موقع الويب http://www.icann.org/en/registrars/accredited-list.html ). كما أنه تم تحديد اتفاقية RAA المعمول ها لكل مسجل في عمود " RAA ".
للمساعدة على قراءة هذا الدليل، تم إعداد مسرد كلمات بسيط مع تضمينه في نهاية هذه الوثيقة.
1. نظرة عامة
جدير بالذكر أن RAA تعتبر جزءاً من عملية تسجيل اسم النطاق. وبشكل مختصر فإن ICANN تتعاقد مع مشغلي السجل والشركات التي تشغل gTLDs. إن كان العميل يريد أن يسجل اسم نطاق بـ gTLD، فيجب على العميل التعامل من خلال المسجل المعتمد لدى ICANN وهي الشركة التي تتعامل بـ RAA مع ICANN. عندما يرغب أحد العملاء في تسجيل اسم نطاق يكون على العميل تقديم المعلومات للمسجل وهي مثل معلومات الدفع والتعاقد إلى جانب معلومات خادم الاسم لتشغيل اسم النطاق. ثم يقوم المسجل بعدها بنقل هذه المعلومات إلى مشغل السجل بحيث يتم التعامل مع الاسم بنظام اسم النطاق. ولكل عملية تسجيل اسم نطاق فترة محددة من الوقت. وأقل فترة تسجيل مقدمة من المسجلين هي عام واحد ويمكن إنجاز عمليات تسجيل تصل إلى 10 أعوام في المرة الواحدة. عند انقضاء فترة التسجيل قد يرغب حامل الاسم المسجل في تجديد التسجيل. إن لم يوافق حامل الاسم المسجل على تجديد التسجيل، فسيفقد حامل الاسم المسجل عموماً حق استخدام اسم النطاق وسيكون اسم النطاق متوفراً لعميل آخر يرغب في التسجيل. عند انقضاء فترة التسجيل ولم يتم تجديدها فقد يتم حذف اسم النطاق نهائياً ولن يتم التعامل من خلال اسم النطاق مرة أخرى.
من أجل اعتماد المسجل من ICANN يكون على المسجل طلب الاعتماد وهي عملية تم تناولها بالتفصيل على موقع الويب http://www.icann.org/en/registrars/accreditation.htm. بشكل مختصر تقوم الشركة المتقدمة بطلب الاعتماد بإمداد ICANN بالمعلومات اللازمة حول الأعمال المنوطة بها والأحوال المادية والتقنية. كما يكون على مقدم الطلب كذلك توفير معلومات حول الأشخاص العاملين والمديرين في الشركة. إن نجح الطلب، يجب على المسجل عدة أشياء من بينها توقيع اتفاقية RAA الأساسية الخاصة بـ ICANN بهدف إتمام عملية الاعتماد.
يجب على كل مسجل معتمد لدى ICANN الدخول في اتفاقية RAA الأساسية مع ICANN لعرض وظائف التسجيل في gTLDs. تتكون RAA من عدة أجزاء: (1) الاتفاقية الأساسية؛ (2) الملاحق لكل TLD التي يتم الاعتماد بها للمسجل للعمل من خلالها؛ و(3) ملحق ترخيص شعار ICANN والذي يعطي المسجل المعتمد ترخيص استخدام شعار "ICANN للمسجل المعتمد" على موقع المسجل. في الوقت الذي تعتبر فيه الاتفاقية الأساسية وملحق ترخيص الشعار من الأشياء الأساسية لكل مسجل يمكن للمسجلين اختيار عدم الدخول في كل الملاحق المتوفرة لـ TLD. على سبيل المثل قد يقرر المسجل أن يقدم عمليات التسجيل لعدد قليل من TLDs مثل.COM و.NET و.INFO ولا يقدم عمليات التسجيل في أية TLDs أخرى. وفي هذه الحالة قد يختار المسجل الدخول فقط في ملاحق TLD لـ .COM و.NET و.INFO والتي قد يختار المسجل من خلالها أن يضيف TLDs في وقت لاحق. تتوفر قائمة توضح كل TLD المتوفرة التي يعتمدها كل مسجل لتقديم خدمات التسجيل على موقع الويب http://www.icann.org/en/registrars/accredited-list.html. في هذا الدليل، المصطلح "ذو الصلة بـ TLD" يشير إلى TLD بأن المسجل معتمد لتقديم الخدمات بها. وسيكون للمسجل اتفاقية منفصلة مع كل مشغل سجل بأن المسجل معتمد بها وقد تتضمن هذه الاتفاقية التزامات إضافية على المسجل.
قد لا يدعي المسجلون أن بإمكانهم إمداد حاملي الاسم المسجل بحالة دخول مميزة لأي من TLD ذات الصلة بالمقارنة مع المسجلين الأخر.
قد يقدم بعض المسجلين المعتمدين لدى ICANN خدمات تسجيل لنطاقات المستوى العلى لرمز الدولة (ccTLDs) مثل.DE و.UK و.ME لا تعتمد ICANN المسجلين لـ ccTLDs ولم يتم تطبيق متطلبات RAA للتسجيل بـ ccTLDs. تعتبر حالات التسجيل لـ ccTLDs مسألة اختيار لمشغلي سجلccTLD – ولا يتوجب على ccTLDs اعتماد المسجلين وإن اختارت الاعتماد فقد تقوم ccTLDs بإعداد التزاماتها وقواعدها الخاصة بها لتوفير الاعتماد.
وتعتبر اتفاقية RAA اتفاقية من جزأين. بعبارة أخرى فإن كل من ICANN والمسجل يقوم بالتزامات الواجبة عليه والواردة بالاتفاقية نحو الطرف الآخر كما أنه يمكن لكل من ICANN والمسجل انتهاك الاتفاقية. وتتحمل ICANN أو المسجل المسئولية عن الإخفاق في التوافق مع الالتزامات الخاصة.
كما أن اتفاقية RAA بين ICANN والمسجل فإنه لا يحق لأحد آخر – بمن فيهم حامل الاسم المسجل له الحق في مقاضاة ICANN أو المسجل بإدعاء انتهاك RAA.
2. اتفاقية RAA
تنقسم الاتفاقية الأساسية إلى خمسة أقسام:
- التعريفات
- التزامات ICANN
- التزامات المسجل
- إجراءات تأسيس أو مراجعة المواصفات والسياسات
- فقرات متنوعة
في حين يتبع هذا الدليل الأقسام المحددة باتفاقية RAA فقد تجد تداخلا لبعض الفقرات. ينتهج الدليل المناقشات التي دارت حسب الموضوع وليس بالضرورة حسب القسم تلو القسم لتحديد الفقرة.
يحدد قسم التعريفات المصطلحات المحددة المستخدمة خلال اتفاقية RAA. ودون محاولة إعادة التأكيد على كل التعريفات من هذا القسم فإن هناك بعضا من المصطلحات الأساسية الموضحة بالمسرد والمتضمنة في نهاية هذا الدليل.
بشكل مختصر تتضمن التزامات ICANN توفير الاعتماد ومنح المسجل ترخيصا لتحديد اعتماد المسجل من خلال ICANN. قد يطلب المسجلون الاعتماد بالإضافة إلى TLDs خلال فترة الاتفاقية. وتلتزم ICANN كذلك بالعمل على بطريقة منفتحة وشفافة مع تطبيق كل المعايير المساوية بين كافة المسجلين وعدم تقييد المنافسة وضمان توفر إجراءات الاستئناف الكافية والمناسبة مع ICANN.
تماما كما يحتوي قسم التزامات المسجل لاتفاقية RAA على العديد من الفقرات التي تفصل التزامات المسجلين فيما يتعلق التعاملات مع حاملي الاسم المسجل فإن هذا القسم من الدليل يقدم مزيد من التفاصيل عن تلك المتوفرة بالأقسام الأخرى.
ويتوجب على المسجلين بعض الالتزامات الأساسية مثل ارتباط المسجلين بإتباع سياسات ICANN والسياسات التوافقية والعمل بما يتوافق مع القانون. تتطلب RAA بشكل خاص من المسجلين الالتزام بسياسةحل النزاع لأسماء النطاقات الموحدة والتي يشار إليها عموما بـ UDRP.
كما أنه على المسجلين كذلك التمتع بصفات محددة حول ما يجب أن يقدموا له إشعارا لحاملي الاسم المسجل يتضمن الإشعارات المتعلقة لنهاية فترة التسجيل واستخدام البيانات الشخصية لحامل الاسم المسجل وإشعارات تتعلق في بعض الحالات بتخزين بيانات أسماء النطاق المسجلة من خدمات تسجيل الخصوصية أو البروكسي وهي موضحة أدناه. كما أن المسجلين مطالبون كذلك بنشر الرسوم لاستعادة الأسماء المسجلة.
2.3.1 تقديم المسجل البيانات لمشغلي السجل
بالنسبة لكل TLD ذي صلة يجب على المسجلين تقديم نقاط محددة من البيانات المتعلقة بكل اسم مسجل بـ TLD:
3.2.1.1 اسم الاسم المسجل قيد التسجيل؛
3.2.1.2 عناوين بروتوكول الإنترنت (IP) لخادم الاسم الأساسي وخادم (خوادم) الاسم الثانوي للاسم المسجل؛
3.2.1.3 الأسماء المطابقة لأسماء الخادم؛
3.2.1.4 هوية المسجل في حالة لم يتم توليد ذلك تلقائيا من نظام السجل؛
3.2.1.5 تاريخ انقضاء التسجيل في حالة لم يتم توليد ذلك تلقائيا من نظام السجل؛
جدير بالذكر أن حاملي الاسم المسجل مطالبون بإمداد المسجل بالمعلومات المتعلقة بأسماء الخوادم (3.2.1.2 – 3)، وقد تكون هناك معلومات أخرى مطلوبة تندرج أسفل القسم 3.2.1.6 بأنه يجب على حامل الاسم المسجل تقديم هذه البيانات. إن قام حاملا الاسم المسجل بتقديم تحديث حول نقاط البيانات هذه يكون لدى المسجل خمسة (5) أيام لتقديم التحديثات لمشغلي السجل.
كما أن المسجلين مطالبون كذلك بإمداد ICANN بقاعدة بيانات إلكترونية بكل عناصر البيانات لكل حالات التسجيل النشطة داخل TLD في حالة طلبت ICANN عند الإخفاق التقني أو التغيير في مشغل السجل.
لم تتم مناقشة خلفية خدمات Whois باتفاقية RAA. بالنسبة للسياق، يعتبر المسجلون مطالبون بتوفير معلومات الاتصال المحددة والمعلومات التقنية اللازمة المتعلقة بكل حالة تسجيل لاسم النطاق بموجب اعتماد السجل. ويجب أن تكون هذه المعلومات وبيانات Whois متاحة للنشر بتنسيق خاص وفي منفذ مصمم "port" لمشاركة بيانات Whois، المنفذ 43، إلى جانب النشر على صفحات الويب التفاعلية. كما أن خدمة Whois هي أداة تستخدم لعدد من الأغراض مثل تحديد مدى توفر اسم النطاق للتسجيل وتحديد مسجل اسم النطاق المرتبط بالأنشطة الخبيثة والاتصال بمسجلي اسم النطاق حول الأحداث المتعلقة حماية العلامة التجارية والتحقق من التجار عبر الإنترنت لتسمية عدد بسيط.
كما أن المسجلين مطالبون بوجود صفحة ويب تفاعلية ومنفذ 43 لخدمة بيانات Whois متاح للنشر للاستعلام مجانا. وتحدد RAA نقاط بيانات محددة يجب توفيرها استجابة للاستعلامات:
3.3.1.2 أسماء خادم الاسم الأساسي وخادم (خوادم) الاسم الثانوي للاسم المسجل؛
3.3.1.3 هوية المسجل (التي قد يتم توفيرها من خلال موقع الويب للمسجل)؛
3.3.1.4 تاريخ الإنشاء الأصلي لبيانات التسجيل؛
3.3.1.6 الاسم والعنوان البريدي لحامل الاسم المسجل؛
3.3.1.7 الاسم والعنوان البريدي وعنوان البريد الإلكتروني ورقم الهاتف الصوتي ورقم الفاكس (إن توفر) للاتصال التقني للاسم المسجل؛
3.3.1.8 الاسم والعنوان البريدي وعنوان البريد الإلكتروني ورقم الهاتف الصوتي ورقم الفاكس (إن توفر) للاتصال الإداري للاسم المسجل.
وهذه البيانات جميعها يشار إليها ببيانات Whois. كما ناقشنا أدناه فإن حاملي الاسم المسجل مطالبون بإمداد المسجل بتحديثات على فترات زمنية لبيانات Whois للاسم المسجل. وعند استلام التحديث يقوم المسجل بتحديث بيانات Whois. قد يتصل المسجلون للصيانة لوظيفة الاستعلام العام وتوجيه ذلك إلى أطراف أخرى.
تتطلب RAA من المسجلين توفير وصول محجوب لبيانات Whois إلى أطراف أخرى. عند توفير الوصول المحجوب أو الوصول إلى بيانات Whois من خلال وظيفة الاستعلام العام فإن المسجل يكون مطالبا بتحديد استخدام المقادير الكبيرة للاستعلامات والمحددات الأخرى حول استخدام بيانات Whois كما هو محدد في RAA بما يتضمن أنشطة التسويق والحالات المخادعة.
يذكر أن المسجلون مطالبون بالحفاظ على سجلات كل الاتصالات مع حاملي الاسم المسجل إلى جانب سجلات المعلومات المقدمة لمشغلي السجل.
ويذكر كذلك أن المسجل مطالب بالحفاظ على قاعدة بيانات لكل بيانات Whois لكل الأسماء المسجلة من خلال اعتماد المسجل إلى جانب كل البيانات التي يقمها المسجل لمشغلي السجل. بالإضافة إلى أنه يجب على المسجل أن يضمن قاعدة البيانات الاسم والعنوان البريدي وعنوان البريد الإلكتروني ورقم الهاتف الصوتي ورقم الفاكس للاتصال المتبادل لكل اسم مسجل.
ويطالب المسجل كذلك بتخزين – أو إيداع لدى طرف آخر موثوق – قواعد البيانات كاملة والتي يشار إليها بـ "مستودع البيانات." قد يتم تحرير قاعدة البيانات من المستودع لمساعدة المسجل أو ICANN أو الطرف الذي تم التنازل له بهدف تقديم خدمات المسجل. كما يدخل كل من ICANN والمسجل وشركة إيداع البيانات في اتصالات إضافية لحكم عبارات عملية مستودع البيانات ويتوفر نموذج لها على موقع الويب http://www.icann.org/en/rde/registrar-data-escrow-agreement-09nov07.pdf [PDF, 45 KB].
وعلى ذكر معلومات الخلفية فإنه توجد بعض أمثلة يرغب العميل فيها في استخدام اسم النطاق وتقليل مقدار المعلومات الشخصية التي يجعلها المسجل متوفرة في استعلام Whois. ولتنفيذ ذلك قد يتم تسجيل اسم النطاق من خلال خدمة الخصوصية (مما يسمح لحامل الاسم المسجل باستبدال بعض المعلومات الشخصية المحددة من خلال معلومات خدمة الخصوصية مثل استخدام الصندوق البريدي بخدمة الخصوصية مكان عنوان المنزل أو العمل لحامل الاسم المسجل) أو خدمة البروكسي وهي الخدمة التي تسجل اسم النطاق وترخص باستخدام اسم النطاق للعميل. عند استخدام خدمة البروكسي، تعبر خدمة البروكسي عن حامل الاسم المسجل وبالتالي يتم استخدام معلومات خدمة البروكسي لمعظم نقاط البيانات المحددة.1 على الرغم من حقيقة أن RAA يتضمن فقرات تتعلق باستخدام خدمات البروكسي أو الخصوصية فإن ICANN لم تتخذ يوما موقفا لصالح أو بما يتوافق مع خدمات البروكسي أو الخصوصية.
عند تسجيل الاسم المسجل من خلال خدمة تسجيل الخصوصية أو البروكسي فإن ذلك يؤثر على المعلومات الموجودة بقاعدة البيانات ويجب على RAA التي تتطلب أن يعرض المسجل خدمة الخصوصية أو البروكسي أن يقوم بأحد شيئين: يجب على المسجل أن يقوم بـ (1) تضمين قاعدة البيانات لاسم العميل والعنوان البريدي وعنوان البريد الإلكتروني ورقم الهاتف الصوتي بالإضافة إلى معلومات خدمة التسجيل لخصوصية أو البروكسي أو (2) في وقت اختيار العميل لاستخدام خدمة تسجيل الخصوصية أو البروكسي يقوم بعرض إشعار تخزين بيانات العميل. عند تخزين بيانات العميل سيتم فقط تخزين معلومات الاتصال المرتبطة بخدمة تسجيل الخصوصية أو البروكسي. في حالة عدم تخزين بيانات العميل مع الحفاظ فقط على معلومات خدمة التسجيل بالخصوصية أو البروكسي بقاعدة البيانات في حالة إخفاق السجل أو المسجل فيجب إرسال إشعار مستقبلا يتعلق بهذا الإخفاق فقط على معلومات الاتصال لخدمة الخصوصية أو البروكسي وليس إلى العميل.
وتتمتع ICANN بحقوق الوصول إلى البيانات التي يجب على المسجل الحفاظ عليها أو مراجعتها. ومع ذلك فإن ICANN مقيدة فيما يتعلق بالكشف عن محتوى البيانات باستثناء ما تسمح به مواصفات ICANN أو السياسة.
تفرض RAA العديد من المتطلبات حول التعاملات التجارية للمسجل بما يتضمن التعاملات مع حاملي الاسم المسجل.
القسم 3.7.4 من RAA يتطلب من المسجل ربما عدم تنشيط الاسم المسجل حتى استلام ضمان مؤكد بدفع رسوم التسجيل.
توضح RAA الإجراءات التي قد يتخذها المسجل في نهاية فترة التسجيل إن لم يقدم حامل الاسم المسجل موافقة لتجديد التسجيل بما يتضمن إلغاء المسجل للتسجيل في نهاية فترة التسجيل الحالية. إن عمل حامل الاسم المسجل أو شخص ما نيابة عن حامل الاسم المسجل الذي لم يوافق على التجديد فيجب على المسجل التأكد من حذف الاسم المسجل من قاعدة بيانات السجل خلال فترة 45 يوما من نهاية فترة التسجيل.
وهذا الالتزام المتعلق بحذف اسم النطاق غير مطلق. القسم 3.7.5.1 من RAA يحدد قائمة "حالات التخفيف المحتملة،" والتي عند العمل بها فإنها تسمح للمسجل بتجديد اسم النطاق حتى بدون موافقة حامل الاسم المسجل. وهذه الحالات تتضمن الاسم المسجل المعرض لإجراء UDRP2 وحكم المحكمة أو إجراءات التقاضي أو حل النزاع المشترك بين الأطراف الأخرى. يجب على المسجل الحفاظ على سجل الأسباب حول سبب تجديد المسجل للتسجيل دون موافقة حامل الاسم المسجل. ويتمتع المسجلون كذلك بالقدرة على إدراج بنود إضافية بالاتفاقية مع حامل الاسم المسجل من شأنه تعديل متطلبات حذف المسجل.
يتوجب على المسجلين تقديم إشعار لكل حامل اسم مسجل جديد بحذف المسجل وسياسات إعادة التجديد التلقائي. إن تغيرت سياسة حذف المسجل خلال فترة العمل باتفاقية التسجيل، فيجب على المسجل أن يبذل جهده لإعلام حاملي الاسم المسجلين بالتغييرات الطارئة على السياسة. تم تقديم تفاصيل عن سياسات الحذف والتجديد التلقائي بأي من مواقع الويب تلك التي يعمل عليها المسجل لتسجيل اسم النطاق وتجديده ويجب على المسجل كذلك تحديد أية رسوم قد تكون مطلوبة على هذه المواقع من أجل استعادة اسم النطاق خلال فترة السماح بالاسترداد (فترة من الوقت تمتد لـ 30 يوما يتم خلالها يشار إلى الاسم بحالة "على وشك الحذف" بالسجل).3
إن كان الاسم المسجل عرضة لنزاع UDRP وقت الحذف أو الانقضاء للتسجيل فإن المدعي على UDRP له الحق في تجديد (أو استعادة في حالة الحذف) اسم النطاق. إن قام المدعي بتجديد أو استعادة الاسم فيجب على المسجل تحديد الاسم في حالة معلق ( HOLD) أو مغلق (LOCK) ،4 ويجب تعديل معلومات Whois لتوضح أن الاسم محل نزاع. القسم 3.7.5.7 من RAA تقدم كذلك حق حامل الاسم المسجل لاستعادة أو تجديد الاسم في حالة إنهاء دعوى UDRP دون التوصل إلى قرار أو قرر المدعي على UDRP ذلك لصالح حامل الاسم المسجل الأصلي.
جدير بالذكر أن المسجلون مطالبون بالدخول إلى اتفاقيات التسجيل الورقية أو الإلكترونية مع كل حاملي الاسم المسجلين. وفقا لـ RAA يجب أن تتضمن اتفاقية المسجل/حامل الاسم المسجل – وفقا للحد الأدنى – البنود التالية (كما هي محددة الأقسام 3.7.7.1 – 12 من RAA):
- يجب على حامل الاسم المسجل أن يقدم "تفاصيل اتصال دقيقة وموثوقة" ويجب أن يقوم بتصحيحها وتحديثها خلال فترة التسجيل. وتم تضمين التفاصيل المطلوبة بالقسم 3.7.7.1: " الاسم بالكامل والعنوان البريدي وعنوان البريد الإلكتروني ورقم الهاتف الصوتي ورقم الفاكس إن وجد لحامل الاسم المسجل؛ واسم الشخص المرخص له وأهداف الاتصال في حالة كان حامل الاسم المسجل عبارة عن منظمة أو جمعية أو شركة؛ وعناصر البيانات المدرجة في الأقسام الفرعية 3.3.1.2 و 3.3.1.7 و3.3.1.8. "
- إن قدم حامل الاسم المسجل معلومات غير دقيقة وغير موثوقة أو أخفق متعمدا في تحديث المعلومات أو تعذر عليه الاستجابة خلال فترة (15) يوما عن استعلامات المسجل حول دقة تفاصيل معلومات الاتصال فسيكون حامل الاسم المسجل في حالة خرق مادي للاتفاقية وقد يتم إلغائها.
- وأيا كان من تم إدراجه كحامل الاسم المسجلـ يجب عليه أن يقدم معلومات اتصال كاملة وأن يمثل حامل الاسم المسجل في السجل. أحيانا قد يقوم حامل الاسم المسجل بتسجيل اسم نطاق ثم يسمح لشخص آخر باستخدام اسم النطاق (مثلا مصمم مواقع ويب يعمل على تسجيل أسماء نطاق للعملاء). إن حدث ذلك وكان الشخص بالفعل يستخدم اسما لم يتم إدخاله باتفاقية المسجل/حامل الاسم المسجل (في إشارة إلى " طرف آخر " باتفاقية RAA) فقد يكون حامل الاسم المسجل مسئولا عن الاستخدام الخاطئ لاسم النطاق من طرف ثالث. وسوف يحدث هذا إن كان على حامل الاسم المسجل تقديم دليل واضح عن الضرر في الإجراء” من استخدام طرف آخر لاسم النطاق. في هذه الحالة سيكون على حامل الاسم المسجل "قبول المسئولية عن الضرر المتسبب من الاستخدام الخاطئ للاسم المسجل، ما لم يكشف حامل الاسم المسجل عن هوية المسجل ومعلومات الاتصال الحالية للمستخدم النهائي.
- يجب على المسجل أن يقدم إشعارا حول كيفية القصد في استخدام البيانات المتوفرة من حامل الاسم المسجل ومن سيستلم بيانات حامل الاسم المسجل. يجب على المسجل كذلك أن يقدم إشعارا حول كيفية وصول حاملي الأسماء المسجلين وتحديث البيانات لهم. بالإضافة إلى ذلك يجب على المسجل أن يحدد نقاط البيانات التي يجب على حامل الاسم المسجل أن يقدمها للمسجل وماهية المعلومات التي يجب توفيرها على أساس طوعي. يجب على حامل الاسم المسجل الموافقة على كل بنود معالجة البيانات هذه.
- إن قام حامل الاسم المسجل بإمداد المسجل ببيانات شخصية نيابة عن أي شخص لا يدخل باتفاقية المسجل/حامل الاسم المسجل ( " الطرف الآخر " والذي تمت مناقشته أعلاه) يجب على حامل الاسم المسجل أن يؤكد على (1) إمداد الأفراد الخاصين بالأطراف الأخرى بنفس إشعارات معالجة البيانات التي يقدمها المسجل و(2) استلام نفس الموافقات من الأطراف الأخرى فيما يتعلق ببنود معالجة البيانات الخاصة بالمسجل.
- قد يقوم المسجل فقط بمعالجة بيانات حامل الاسم المسجل كما هو محدد في إشعارات معالجة البيانات الموضحة أعلاه.
- يتوجب على المسجل أن يوافق على اتخاذ مواصفات معقولة لحماية بيانات حامل الاسم المسجل من " الفقدان أو إساءة الاستخدام أو الوصول غير المرخص أو التبديل أو الكشف أو التغيير أو التدمير ".
- يجب على حاملي الاسم المسجلين تقديم ذلك: " إلى أفضل مدى في اعتقاد ومعرفة حامل الاسم المسجل أن لا يقدم الاسم المسجل ولا عملية التسجيل ولا طريقة الاستخدام بشكل مباشر أو غير مباشر قد ينتهك الحقوق القانونية لأطراف أخرى. " وهذا يعني أنه يجب على حامل الاسم المسجل أن يقدم للمسجل ما يثبت عدم استخدام اسم النطاق بطريقة تنتهك الحقوق القانونية للآخرين. وكمثال على ذلك " الانتهاك " قد يتمثل في تسجيل اسم النطاق الذي ينتهك العلامة التجارية لأي شخص لحال الاسم المسجل.5
- إن كان هناك نزاعا في التواصل مع استخدام الاسم المسجل فيجب على حامل الاسم المسجل الموافقة على التقاضي أمام المحاكم في مكان وجود المسجل (المحدد غالبا بموقع الويب أو في اتفاقية المسجل/حامل الاسم المسجل) ومحاكم "إقامة حامل الاسم المسجل". و"محل الإقامة" هي كلمة ذات معنى قانوني محدد ولكنها ستكون موقع تقديم حامل الاسم المسجل للمسجل بالبيانات الشخصية المحددة. وتعني مسألة الموافقة على التقاضي موافقة حامل الاسم المسجل على أن المحاكم في كل مكان لديها السلطة لتقرير هذه الأنواع من الحالات.6
- يجب على حامل الاسم المسجل الموافقة على خضوع عملية التسجيل للتعليق أو الإلغاء أو التحويل وفقا للأسباب المحددة بالقسم 3.7.7.11. وتتضمن هذه الأسباب: إن تبنت ICANN بندا أو سياسة تتطلب ذلك أو إن تطلبت إجراءات السجل أو المسجل ذلك "لتصحيح الأخطاء من المسجل أو مشغل السجل خلال علمية تسجيل الاسم أو لحل النزاع المتعلق بالاسم المسجل." على سبيل المثال فإن UDRP هي سياسة تبنتها ICANN تحدد المجلس الإداري وسماعه لنزاع اسم النطاق وقد يأمر بتعليق تسجيل اسم النطاق أو تحويله أو إلغاؤه ويجب على حامل الاسم المسجل الموافقة على هذا الاحتمال.
- يجب على حامل الاسم المسجل "تأمين ورفع أذى مشغل السجل والمديرين والعاملين والموظفين والوكلاء من وضد أية دعاوى وأضرار ومسئوليات وتكلفة ونفقات (تتضمن الرسوم والنفقات القانونية المعقولة) الناتجة أو المتعلقة بعملية تسجيل اسم النطاق لحامل الاسم المسجل." وهو أمر بسيط وهو يعني أنه إن كان مشغل المسجل (أو أي من العاملين لديه وما إلى ذلك) للاسم المسجل في حالة تقاضي بسبب عملية تسجيل اسم النطاق لحامل الاسم المسجل، يجب على حامل الاسم المسجل أن يدفع لمشغل السجل كل الرسوم والنفقات المتعلقة بالدفاع ضد الشكوى كما سيدفع كذلك مصروفات ونفقات أية أحكام أو مسئوليات يتم الحكم القضائي بها. وهذه "التعويضات" محصورة على الحالات القضائية.
كما تم التوضيح أعلاه بمزيد من التفاصيل توجد بنود وسياسات ومواصفات قد يتم العمل بها وتطبيقها على المسجلين. قد تحدد بعض من المواصفات أو السياسات التزام المسجل بالتحقق من معلومات الاتصال المرفقة من حامل الاسم المسجل عند تسجيل النطاق للمرة الأولى إلى جانب تحديد المتطلبات لحالات التحقق على فترات من معلومات الاتصال. ويطالب المسجلون بإتباع هذه المواصفات والسياسات المرفقة المعمول بها تجاريا.
كما أن المسجلين مطالبون كذلك باتخاذ "خطوات مناسبة" للتحقق من معلومات الاتصال في حالة إشعار أي شخص للمسجل بأن معلومات الاتصال للاسم المسجل هذا غير دقيقة. ويتوجب على المسجل كذلك التزامات للعمل على تصحيح المعلومات غير الدقيقة في معلومات الاتصال والتي يكون المسجل على وعي بها حتى في حالة عدم الإخبار بالمعلومات غير الدقيقة من أي شخص.
يجب على المسجل الحفاظ على معلومات الاتصال بالشكل المناسب لنفسه أولاً بما يتضمن عنوان البريد الإلكتروني الصالح وعناوين المراسلة البريدية وعنوان البريد الإلكتروني. يجب نشر معلومات الاتصال على موقع الويب الخاص بالمسجل.
لا يجب على RAA أن تفرض حدوداً على الرسوم التي يجب على المسجل أن يدفعها لحاملي الاسم المسجل لخدمات التسجيل.
تحدد RAA أن المسجلين ملتزمون بدفع رسوم سنوية إلى ICANN إلى جانب الرسوم المتغيرة. تحدد RAA أحكام دفع الرسوم.
2.3.7 التزامات المسجل للعمل نيابة عن الآخرين
عند تقدم الهيئات للاعتماد فإنها مطالبة بإمداد ICANN بمعلومات حول ملكية وإدارة المسجل المقترح. وأصبح من الشائع للشركات المتعددة والتي تتشارك المصلحة العامة الحاكمة (مثل الشركة "الأم" ذاتها أو الأشخاص ذاتهم المدرجين كمالكين) التقدم للاعتماد المنفصل. وهؤلاء المسجلين يعتبرون هيئات قانونية منفصلة باتفاقيات RAAs منفصلة ومع ذلك تضيف اتفاقية 2009 RAA بعض الالتزامات الإضافية حول حالات التسجيل المدمجة بسبب العلاقات الأخرى بين الشركات المدمجة. ولا يتمتع كل المسجلين بالمسجلين المدمجين.
تحدد RAA الشروط حيث يكون المسجل في ظل المصلحة العامة الحاكمة مع حالات التسجيل المدمجة قد يكون في حالة خرق لـ RAA استنادا إلى أفعال اثنين أو أكثر من هذه التسجيلات المدمجة.
تفرض اتفاقية RAA لعام 2009 التزامات جديدة على المسجلين العاملين مع البائعين - الأشخاص أو الهيئات التي يتصل بها المسجل من أجل العملاء وتقدم في بعض الأحوال بعض خدمات الأخرى للمسجل. تتطلب 2009 RAA من المسجلين تضمين بنود محددة باتفاقيات المسجل/البائع تتضمن: حظر البائع من عمل عروض تقديمية معتمدة من ICANN تتطلب أن تتضمن كل اتفاقيات التسجيل للبائع كل فقرات التي يطلب منها للمسجل تضمين ذلك في اتفاقية المسجل/حامل الاسم المسجل؛ وتتطلب نشر كل ارتباطات لكل مواقع ويب ICANN التي تجبر المسجل على النشر؛ وتحديد المسجل الراعي. ويطلب من البائع التأكد من ذلك إن كان العميل يستخدم خدمة تسجيل اسم النطاق لتسجيل الخصوصية أو البروكسي للبائع فحينها يقوم البائع بعمل واحد من الأشياء الثلاثة التالية: (1) إيداع هوية ومعلومات الاتصال للعميل مع المسجل؛ (2) إيداع هوية ومعلومات الاتصال بمخزن بيانات؛ أو (3) نشر إشعار للعميل بعدم تخزين معلومات الاتصال الخاصة به.
تطلب RAA كذلك من المسجل اتخاذ إجراءات توافقية وتعزيزيه ضد البائع الذي انتهك أي من الفقرات المطلوبة.
وسيطلب من المسجلين في الوقت الحالي إتمام دورة تدريبية والتشاور مع المسجلين على التزامات المسجل شريطة وجود ICANN. وعند إرسال إشعار مناسب (محدد في RAA) يطلب من المسجلين التعاون مع ICANN لإجراء مراجعات توافقية وتقديم معلومات إلى ICANN بطريقة حديثة والسماح بطلب زيارات ميدانية من جانب ICANN إلى جانب إجراء مراجعات تحقق عن مسئولية الأطراف الأخرى المستقلة فيما يتعلق بكتب وسجلات المسجل. بالإضافة إلى أنه إن كانت ICANN في حالة تشاور مع المسجلين وقامت بإنشاء محتوى يحدد حقوق حامل الاسم المسجل ومسئولياته ففي هذه الحالة يكون المسجلون مطالبون بنشر ارتباط لصفحة الويب تحتوي على هذا المحتوى.
2.4 إجراءات تأسيس أو مراجعة المواصفات والسياسات
كما تم الذكر أعلاه فإن المسجين مطالبون بالتوافق مع مواصفات وسياسات ICANN بما يتضمن تلك التي تم وضعها أو مراجعتها خلال فترة العمل بـ RAA. تحدد RAA مواضيع المواصفات والسياسات التي قد يتم وضعها ومراجعتها لاحقا بما يتضمن العناصر ذات الصلة بإمكانية التشغيل واستقرار DNS وقرارات النزاعات على اسم النطاق وتحديد الأسماء المسجلة وحالات الحظر على مخزن المسجل للأسماء المسجلة. جدير بالذكر أن المواضيع محددة وغير محددة بطريقة سهلة أو مكثفة ومع ذلك فإن النقطة الهامة هي في وجود العديد من النقاط حيث يكون على المسجل بعض من الالتزامات المستمرة للتوافق مع المراجعات والمواصفات الجديدة والسياسات التي تم العمل بها خلال فترة العمل بـ RAA حتى إن كانت بنود المواصفات والسياسات مكتوبة خصيصا لـ RAA. يجب على ICANN إمداد المسجل بفترة مناسبة من الوقت بعد استلام الإشعار للتوافق مع المواصفات المحددة حديثا أو السياسة المحددة حديثا.
بعض من هذه المواصفات والسياسات تعرف بـ "السياسات التوافقية" وهي توضع استنادا إلى "التوافق بين المستفيدون من الإنترنت الممثلين في عمليات ICANN." ويطلب من المسجل إتباع هذه السياسات التوافقية كما أن المسجل مطالب كذلك بإتباع سياسات ومواصفات ICANN الأخرى. ومع ذلك قد تكون هناك مرات عندما لا يعتقد المسجل في "التوافقات" الموجودة لدعم إنشاء هذه السياسة ومن ثم فإنه يعتقد أنه لا يتوجب عليه التوافق مع السياسة التوافقية. وتحدد RAA كذلك إجراءات المسجل لحل النزاع سواء في حالة وجود السياسة التوافقية أم لا وبالتالي فإن عليه أن يتبع السياسة أو المواصفات عن التعامل مع المشكلة. تحتوي الأقسام 4.3 و4.4 من RAA على مقدار محدد من كل معلومات محددة تتعلق بإنشاء السياسات التوافقية وتوقيت هذه العملية.7
يحدد القسم 5 من RAA مجموعة فقرات متنوعة التي تركز بشكل رئيسي على قرار حل النزاعات بموجب RAA وإنهاء RAA ونوع الاعتقاد الذي قد يطلبه ICANN أو المسجل من خلال الدعوى القضائية التي تتم بموجب RAA. بعض من هذه الأجزاء الواضحة في القسم 5 هي:
جدير بالذكر أن فترة RAA تصل إلى (5) أعوام للفترة وإن طلب المسجل تجديدها في نهاية فترة الخمسة أعوام فإن ICANN ستسمح بالتجديد ولكن فقط إن كان المسجل متوافقا مع الالتزامات الواردة في RAA. وما حدث في عام 2009، فإن هناك احتمالية أن تقوم RAA بالمراجعة مرة أخرى. وإن حدث ذلك قد يطلب المسجل الدخول– ولكن ولا يتعين عليه ذلك – في اتفاقية RAA "جديدة" حتى إن لم تنته اتفاقية المسجل الحالية. عند انقضاء فترة الخمسة أعوام وقيام المسجل بتجديد RAA فسيتعين على المسجل الدخول في أحدث نسخة من اتفاقية RAA المتاحة وقت التجديد.
قد يقوم المسجل بإنهاء اتفاقية RAA في أي وقت قبل إنهاء RAA عبر إرسال إشعار لـ ICANN قبل الإنهاء بفترة 30 يوما.8
قد تقوم ICANN فقط بإلغاء RAA في حالات محددة وهي محددة أسفل القسم 5.3، وهي تتضمن إن كان المسجل: قد قام بالتمثيل الجوهري الخاطئ في تطبيق الاعتماد؛ ومواجهة حكم قانوني أو دليل مقنع متعلق بحالة احتيال أو إساءة مشابهة؛ ويكون عرضة للنظام الحكومي عن إساءة الاستخدام تمويل الآخرين والتعذر في علاج الخرق القانوني لاتفاقية RAA المحددة في إشعار الخرق من جانب ICANN. قد تقوم ICANN كذلك بإنهاء اعتماد المسجل عندما يصبح المسجل مفلسا أو عاجزا عن الدفع أو عندما بكون المسجل مشتركا في إجراءات تحددها ICANN للتعامل مع الاستقرار التشغيلي للإنترنت. في كل الحالات خلال العجز عن الدفع يجب على ICANN إرسال إشعار خلال فترة (15) يوما من الإنهاء. بالنسبة للحالات التي تتضمن الاستقرار التشغيلي للإنترنت قد تقوم ICANN بتعليق RAA لفترة (5) أيام في حين تطلب ICANN الحكم القضائي من المحاكم.
إن استلم المسجل إشعار الإنهاء فقد يواجه المسجل الإنهاء من خلال اللجوء للتحكيم.9 قد يطلب المسجل كذلك بقاء المحكمين على الإنهاء – أو بعبارة أخرى السماح للمسجل بالاستمرار في العمل كمسجل معتمد – لحين صدور قرار نهائي في التحكيم. قد يقوم المحكمون كذلك بإصدار قرار وقف والسماح للمسجل بالاستمرار في ممارسة أعماله إن رأوا أن استمرار التشغيل للمسجل لن يضر العملاء والمستهلكون أو المصلحة العامة أو قد يحدد المحكمون مديرا منفصلا (غير مرتبط بـ ICANN أو المسجل) للعمل على إدارة عمليات تشغيل المسجل حتى يصدر المحكمون قرارهم. وعلى خلاف الإصدارات السابقة من RAA، قد تطلب ICANN من لجنة التحكيم أن "تلغي" الإيقاف وتنهي عمليات تشغيل المسجل قبل اكتمال قرار التحكيم. تحدد RAA المتطلبات الإضافية حول كيفية ومكان إجراء التحكيم. بالإضافة إلى أن RAA تسمح لكل من ICANN أو المسجل بإتمام إجراءات المحكمة المتعلقة بالنزاع على اتفاقية RAA. تحدد RAA حدود حول المقادير المالية التي تحددها لجنة التحكيم أو التي قد يفرضها الحكم القضائي على كل طرف خلال الدعوى أو التحكيم.
قد تقوم ICANN باتخاذ إجراءات توافقية أخرى ضد المسجل دون اللجوء إلى إنهاء RAA. مصلا تتمتع ICANN بحق تعليق قدرة المسجل على إنشاء أسماء جديدة مسجلة و/أو قدرة المسجل على بدء تحولات داخلية لأسماء السجل فترة تصل إلى عام واحد ولكن ذلك كله في حالات محددة. قد يواجه المسجل التعليق عن الإخفاق في معالجة RAA خلال فترة محددة من الوقت. بالإضافة إلى أنه إن استلم المسجل إشعارات عن ثلاثة انتهاكات على الأقل لـ RAA خلال فترة عام واحد حتى وإن عالج المسجل كل خرق تعرف عليه من الإشعار خلال فترة زمنية محددة يكون لدى ICANN القدرة على تعليق المسجل من إنشاء عمليات تسجيل جديدة استنادا إلى إعادة حدوث انتهاكات RAA. ولا يعتبر حق التعليق هذا بالإضافة إلى فقرات الإنهاء عبر التعليق لا يعتبر قويا كفاية كأداة لتعزيز التوافق مثل الإنهاء.
إن تحصل المسجل من خلال هيئة أخرى فيجب على المسجل إرسال إشعار عن هذا التحصل إلى ICANN مع إمدادها بمعلومات محددة تتعلق بإمكانية استمرار المسجل في الوفاء بمتطلبات الاعتماد خلال فترة (30) يوما من تاريخ التحصل. إن رغب المسجل في تحويل RAA إلى أعمال أخرى فيجب على ICANN أن توافق على هذا التحول كتابة.
3. خاتمة
تعتبر RAA مستندا قانونيا ملزما بين ICANN وبين كل واحد من المسجلين المعتمدين. وتعتبر هذه الاتفاقية من الأهمية بمكان في تحديد دور المسجل في نظام اسم النطاق وكيفية تفاعل المسجل مع حامل الاسم السجل. وتم توفير هذا الدليل لمساعدة حاملي الاسم المسجلين والمستخدمين النهائيين على التعاطي بشكل أفضل للالتزامات بين ICANN والمسجلين وتوفير بعض السياقات حول كيفية تأثير التزامات RAA على حاملي الاسم المسجلين والمستخدمين النهائيين. في الوقت الذي لا يقدم فيه هذا المستند تأثيرا قانونيا فإنه يمثل خطوة هامة لجعل عمل ICANN أكثر إمكانية للتعاطي معه فيما يتعلق بالجميع مع زيادة التفهم العام للأدوار والمسئوليات لكل الأشخاص في مجتمع الإنترنت.
4. مسرد
توجد بعض المصطلحات الأساسية التي قد تساعد على التفهم الأفضل عند القراءة في هذه المواضيع خاصة فيما يتعلق بـ ICANN ونظام اسم النطاق (DNS). ويمكن العثور على مسرد شامل بشكل أكثر على موقع الويب http://www.iana.org/about/glossary/. ولا تستبدل التوضيحات العامة هنا التعريفات القانونية للكلمات المستخدمة في RAA وهي مقدمة لتكون كدليل مساعد عند القراءة والتعرف على هذا الدليل.
ccTLD أو نطاق المستوى الأعلى لرمز البلد: تعتبر ccTLDs فئة من TLDs (انظر أدناه) وتفيد بالتحديد فقط لتمثيل الدول أو المقاطعات على قائمة ISO 3166. توجد أسماء من حرفين مثل.DE التي تعبر عن ألمانيا أو.IE لتعبر عن أيرلندا. سوف يكون هناك مزيد من ccTLDs في المستقبل القريب ويشار إليها باسم النطاق التدويل ccTLDs (IDN ccTLDs) وهي بحروف غير لاتينية وتسمح للمسجلين بالتسجيل بالنصوص والحروف المحلية للدولة مثل اللغة العربية للملكة العربية السعودية أو السريالية كما في روسيا. لا تعتبر عمليات التسجيل في ccTLDs خاضعة لفقرات RAA.
gTLD أو نطاق المستوى الأعلى العام: فئة TLDs (انظر أدناه) المستخدمة للأغراض العامة مثل.COM أو.NET وتتنوع gTLDs إلى نوعين: نطاقات المستوى الأعلى الراعية مثل.JOBS أو.TRAVEL وTLDs غير الراعية مثل.COM و.NET تعمل TLD الراعية على خدمة مجتمع محدد ويتفاعل المسجل مع المنظمة الراعية التي تشرف على تطور السياسة لتشغيل TLD الراعية. تطبق RAA على كل علميات التسجيل داخل gTLDs.
خادم الاسم: مصطلح عام للنظام على الإنترنت وهو يجيب على طلبات تحويل أسماء النطاق إلى شيء آخر.
حامل الاسم المسجل: مسجل اسم النطاق.
المسجل: هي هيئة تعمل على الطلبات من حامل الاسم المسجل لإجراء التغييرات على السجل بما يتضمن التسجيل الأولي لأسماء النطاق. تطبق RAA على كل المسجلين المعتمدين لأسماء المسجل داخل gTLDs.
السجل: بالنسبة لأغراض التعرف على RAA فإن السجل هو كتاب أو سجل يحوي كل عمليات التسجيل في TLD محدد.
مُشغل السجل: الشخص أو الهيئة التي تقوم على تشغيل السجل.
TLD أو نطاق المستوى الأعلى: يعتبر TLD هو النطاق الفرعي بأعلى مستوى في DNS والممثل في كل شيء من حق "dot" مثل.COM و.UK و.EDU كما توجد تصنيفات مختلفة لـ TLDs تتضمن TLDs العامة (gTLD) ورمز الدولة TLDs (ccTLDs).
UDRP أو السياسة الموحدة لحل النزاعات حول أسماء النطاقات: جدير بالذكر أن UDRP هي السياسة التي تبنتها ICANN والمشتركة في كل اتفاقية بين حامل الاسم المسجل والمسجل في gTLD. تحدد UDRP أحكام وشروط النزاع استنادا إلى التسجيل واستخدام اسم النطاق. يتم نشر UDRP على موقع الويب http://www.icann.org/en/dndr/udrp/policy.htm كما تتم الترجمة إلى 10 لغات.
* جدير بالذكر أن دليل غير المحامين عبارة عن مستند تم إصداره. كما يرحب طاقم العمل بـ ICANN بأي تعليقات حول كيفية تحسين الدليل.
1 لم تحدد RAA هذه المناقشة حول تسجيل الخصوصية/البروكسي. وهي متوفرة في هذا الدليل للمحافظة على السياق.
2 تم توضيح UDRP باختصار في المسرد الموجود في نهاية هذا الدليل.
3 وقد تم تقديم التمثيل الجغرافي لدائرة الحياة للاسم المسجل النموذجي لـ gTLD على موقع الويب http://www.icann.org/en/registrars/gtld-lifecycle.htm. وقد يفيد هذا المخطط في الإشارة إلى المزيد من المعلومات حول حالة ما بعد الانقضاء لأسماء النطاق.
4 جدير بالذكر وجود الأسماء التقنية الرسمية لحالات اسم النطاق والناتجة عن طلب الإنترنت المستند إلى المجتمع للتعليقات. والحالات المطلوبة هنا محددة من المسجل. عندما تكون عملية التسجيل ضمن أحد الحالات المذكورة فيتعذر حينها حذف النطاق كما يتعذر تعديل التسجيل. يجب على المسجل إزالة حالة معلق (HOLD) أو مغلق (LOCK) عند حدوث أي تعديل.
5 كما توجد العديد من الطرق الأخرى المحتملة " لانتهاك الحقوق القانونية " للأطراف الأخرى ويتم تشجيع حاملي الاسم المسجل المحتملين على طلب النصيحة بشكل مستقل إن كانوا مهتمين بانتهاك التسجيل أو استخدام اسم النطاق لحقوق طرف آخر.
6 يجب وجود نطاقات مقاضاة أخرى قادرة على تقرير حل النزاع حول استخدام الاسم المسجل مع عدم تحديد النطاقات القضائية الإضافية في RAA.
7 للتعرف على أمثلة حول السياسات التوافقية التي تم العمل بها داخل ICANN، انظر السياسات الموضحة على موقع الويب http://www.icann.org/en/general/consensus-policies.htm.
8 ولدى ICANN عمليات خاصة عليها تقوم بها للمساعدة في الانتقال المتزامن في حالة الإنهاء لاعتماد المسجل. يمكن التعرف على مزيد من المعلومات حول الإجراءات المحددة المتعلقة بإجراءات إلغاء اعتماد نقل المسجل من خلال موقع الويب
http://www.icann.org/en/processes/registrars/de-accredited-registrar-transition-procedure-01oct08.pdf [PDF, 119 KB].
9 ويعتبر التحكيم طريقة خاصة لحل النزاع كما هو مفترض كطريقة عامة لقديم دعوى في المحكمة. تعتبر إجراءات التحكيم أسرع وأكثر فعالية من إجراءات التقاضي أمام المحكمة. بدلا من الإشراف من القضاء تعتبر لجنة التحكيم مشرفا من اللجنة ولجنة يتم تحديدها بشكل مستقل ويجب أن تكون بعيدة كل البعد عن تضارب المصلحة مع الأطراف المتضمنة في عملية التحكيم.