×

شروحات وتفاصيل حول النطاقات مقدمة من هيئة ال ICANN

السلام عليكم ورحمة الله وبركاته قامت هيئة الايكان مؤخراُ بطرح العديد من الامور المتعلقة بالنطاقات من استفسارات ومشاكل بين مالكي النطاق وهيئات التحكيم ....... الخ
صورة 'available' الرمزية
قديمة 28 - 03 - 2012, 20:23
المشاركة 1
السلام عليكم ورحمة الله وبركاته

قامت هيئة الايكان مؤخراُ بطرح العديد من الامور المتعلقة بالنطاقات من استفسارات ومشاكل بين مالكي النطاق وهيئات التحكيم ....... الخ

في هذا الموضوع سيتم عرض العديد من هذه الامور .

مقدمة



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

شُكل ICANN فى 1988. لم تعد هذه الشراكة للتربح من الناس حول العالم ولكن كرست للحفاظ على الإنترنت آمنًا ومستقرًا وممكن إجراؤه فهو يروج للمنافسة ويطور سياسة على معرفات الإنترنت الفريدة.

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

ما هو نظام تسمية النطاق؟

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

النتيجة النهائية هي أن الموقع الإلكتروني ل ICANN يوجد على شكل icann.org بدلا من “192.0.34.163” والتي يتعرف عليها الحواسيب على شبكة الإنترنت. أحد مزايا هذا النظام - بعيدًا عن جعلها الإنترنت أسهل في التعامل مع الناس - هو أنه اسم نطاق محدد لا يتوجب تقيده بجهاز حاسوب محدد لأن الرابط بين نطاق محدد وعنوان آي بي محدد يمكن تغييره بسهولة وسرعة. وهذا التغيير سيكتشف بكل شبكة الإنترنت فى غضون 48 ساعة بفضل تحديثات البنية التحتية الدائمة ل DNS والنتيجة نظام بالغ المرونة

اسم النطاق نفسه يشمل عنصرين أساسيين: ما قبل "النقطة" وما بعدها. الجزء على يمين النقطة، مثل “com”, “net”, “org” وهكذا، يعرف باسم " النطاق عالي المستوى" TLD شركة واحدة فى كل حالة (تسمى المسجل)، تكون مسئولة عن كل النطاقات التي تنتهي بهذا النطاق المحدد عالي المستوى ولها حق الوصول المباشر للقائمة الكاملة للنطاقات تحت هذا الاسم، كما هو الحال فى عنوان آي بي الذي ترتبط به هذه الأسماء. الجزء الذي يسبق النقطة هو اسم النطاق الذي قمت بتسجيله والذي يستخدم فيما بعد ليمد النظم العاملة مثل الشبكات الإلكترونية، والبريد الإلكتروني وهكذا. هذه النطاقات يتم بيعها بأعداد كبيرة من قبل "المسجلون"، وأحيانا بدون مقابل حسب رغباتهم، على النقيض في كل حالة يدفعون رسومًا لكل نطاق لمكان التسجيل الذي يتم تسجيل اسم النطاق نسبة له.

*ICANN تحرر العقود مع كل مسجل. تقوم ايضا بإدارة نظام تفويض من المسجلين. فى هذه العقود يتوفر بيئة من الثبات والتناغم لاسم النطاق، وكذلك الإنترنت.

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

ماذا يتوجب على ICANN عمله بالنسبة لعناوين آي بي؟

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

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

ماذا عن الخادمات الرئيسية؟

الخادمات الرئيسية هي حالة مختلفة مرة أخرى. هناك 13 خادمًا رئيسيًا، أو أكثربدقة، هناك 13 عنوان أي بي على الإنترنت حيثما توجد الخادمات الرئيسية (الخادم الذي يحوي واحدًا من ال 13 عنوان أي بي من الممكن أن يكون في مختلف عشرات الأماكن). هذا الخادم يخزن نسخة من نفس الملف الذي يمثل المحتوي الرئيسي لكتب عناوين الإنترنت. يضع قوائم بعنواين النطاقات عالية المستوى (.com, .de, وهكذا) حيث العنوان الخاص بالمسجل يمكن أن يوجد.

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

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

ما هو دور ICANN؟

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

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

كيف يتم تكوين/بناء ICANN?

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

هناك ثلاث " منظمات داعمة " وتمثل:

المنظمات التي تتعامل مع عناوين اي بي.
المنظمات التي تتعامل مع أسماء النطاقات.
مديرو بلاد النطاقات عالية المستوى ( هناك استثناء خاص كما هو موضح بالأسفل).
ثم هناك أربع "لجان استشارية" والتي تمد ICANN بالمشورة والتوصيات. وهي تمثل:

الحكومات ومنظمات المعاهدات الدولية
مشغلو الخادمات الرئيسية
وتلك المهتمة بأمان الإنترنت
مصطلح "على الأكثر" المجتمع، يعني متوسط مستخدمي الإنترنت.
وفى النهاية، هناك جماعة Liaison التقنية, التي تعمل مع المنظمات التي تبتكر أساسيات تكنولوجيا الإنترنت

القرارات النهائية لهيئة ICANN توضع من خلال مجلس الإدارة. المجلس يتكون من 21 عضوًا: 15 منهم لهم حقوق التصويت و ستة liaisons ليس لهم حق التصويت. أغلبية الأعضاء الذين لهم حق التصويت (ثمانية منهم) يتم اختيارهم من خلال لجنة الترشيح المستقلة والباقون أعضاء مرشحون من منظمات داعمة.

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

كيف يتخذ ICANN القرارات؟

عندما يحين وقت عمل التغيرات التقنية للإنترنت، فهذه هي الخلاصة المبسطة للعملية:

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

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

تظل العملية فى إعادة حتي يصل مختلف أجزاء ICANN إلى تسوية أو يقوم مجلس الإدارة بوضع قرار حول تقرير تم عرضه.

كيف يتحمل ICANN المسؤولية؟

لدي ICANN مسؤوليات خارجية كما المسؤوليات الداخلية.

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

هيئة ICANN شركة منفعة عامة لاربحية ومديروها مسؤولون قانونيا عن تحمل واجباتهم فى ظل قانون الشركة.

داخليا، ICANN مسؤولة أمام المجتمع من خلال:

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

*هناك استثناء هام لهذا فى شكل "رموز نطاقات البلاد عالية المستوى" (ccTLDs) مثال ذلك .de لألمانيا و .uk للملكة المتحدة. هناك ما يزيد على 250 نطاق عالي المستوى ccTLDs، بعضهم لديهم عقود مع ICANN؛ بعضهم لديهم إتفاقيات موقعة عاملة مع ICANN؛ وبعضهم يتوجب عليه إدخال اتفاقيات رسمية مع ICANN. ومع ذلك ICANN يقوم بوظيفة تعرف ب "IANA" , والتي تضع قوائم بالعناوين الرئيسية لكل النطاقات عالية المستوى ccTLD لذلك باقي الإنترنت يمكن أن يجدها. ICANN فى الوضع الذي يسمح له بإضافة نطاقات عالية المستوى للنظام الأوسع، كما فعل فى 2000 و2004 عندما أضيف سبع وست نطاقات عالية المستوي على التوالي إلى "الخادم".





الأسئلة المتكررة بخصوص حاملي اسم النطاق



إذا قمت بشراء اسم من خلال أحد المسجلين، فهل يكون مسموحًا لي التحول إلى مسجل مختلف؟

نعم. تشترط السياسة الداخلية المتعلقة بتحول المسجلين- والتي تنطبق على جميع المسجلين المعتمدين بهيئة الإنترنت للأرقام والأسماء المخصصة ( ICANN )، أن حاملي الأسماء المسجلة يجب أن يكونوا قادرين على تحويل تسجيلات أسماء النطاقات الخاصة بهم بين المسجلين. كما يجب عليك أن تنتظر لمدة 60 يومًا بعد التسجيل الأولي أو بعد أي تحويلات سابقة لبدء تحويل آخر .

كيف يمكن أن أقوم بتحويل اسم النطاق الخاص بي إلى مسجل جديد؟

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

كما يمكن للمسجل الحالي أن يقوم بالتأكد من عزمك على التحويل باستخدام استمارة التأكيد على طلب تحويل المسجلين.

يطلب المسجل مني تقديم كود، فمن أين لي به؟

كود معلومات الترخيص ( Auth-Info Code ) هو كود فريد مبني على أساس كل نطاق، ويستخدم للحصول على ترخيص أو تأكيد على طلب التحويل؛ ويقوم بعض المسجلين بتوفير تسهيلات لخلق وإدارة كود معلومات الترخيص الخاص بك. وفي حالات أخرى، ستحتاج إلى الاتصال بالمسجل مباشرةً للحصول على هذا الكود. ويتوجب على هذا المسجل أن يوفره لك في غضون 5 أيام من طلبك.

وينطبق هذا الكود على عمليات تحويل جميع أسماء النطاقات العامة عالية المستوى (gTLD) ، باستثناء أسماء .gov ، و .edu, ، و .mi ، و .museum ، و .int

وماذا سيحدث إذا لم أكن أعرف من هو المسجل الخاص بي؟

إذا كنت لا تعرف من هو المسجل الحالي الخاص بك، فيمكنك الحصول على معلومات عن اسم النطاق الخاص بك عن طريق أداء عملية بحث (من هو Whois ) على موقع <http://www.internic.net/whois.html> .

يرفض المسجل الخاص بي تحويل اسمي، فماذا أفعل؟

يجوز للمسجل أن يرفض وبطريقة مشروعة طلب التحويل في ظروف معينة محدودة، على النحو التالي:

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

يطالبني المسجل الخاص بي بدفع تكلفة نظير التحويل إلى مسجل جديد، فهل ذلك يعد مسموحًا به؟

نعم، يسمح للمسجلين بتحديد الأسعار الخاصة بهم نظير الحصول على هذه الخدمة.

تم رفض طلبي لسبب غير المذكور أعلاه، أو أنني لا أوافق على السبب الذي قدموه، فماذا أفعل؟

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

تم تحويل اسم النطاق الخاص بي دون ترخيص مني بذلك، فماذا أفعل؟

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

كيف يمكن أن أعرف السبب وراء رفض طلب التحويل الذي تقدمت به؟

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

تم تحويل نطاقي إلى مسجل آخر دون علمي، والآن يظهر شخص آخر باعتباره المالك، فماذا أفعل؟

يجوز للمسجل فقط الشروع في التحويل إذا كان قد حصل على استمارة ترخيص كاملة ( FOA ) إما من 1) صاحب التسجيل أو من 2) جهة الاتصال الإدارية للنطاق. ويجب على المسجل أن يكون قادرًا على إخراج نسخة من هذه الوثائق عند طلبها؛ وفي حالة الإخفاق في القيام بذلك يكون هذا أساسًا لإلغاء عملية التحويل في حال وجود شكوى في إطار سياسة حل الخلافات المتعلقة بعمليات التحويل .

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

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

لا، حيث يمكن للمسجل الجديد الخاص بك والذي قمت باختياره أن يقوم ببدء طلب التحويل على أساس اسم النطاق المنتهي بمجرد الحصول على الترخيص المطلوب منك، فانتهاء أو عدم تجديد اسم النطاق لا يعد سببًا وجيهًا لرفض طلب التحويل.

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

تم سرد المسجل الخاص بي باعتباره جهة الاتصال الإدارية الخاصة باسم نطاقي، وهذا يحول دون عملية التحويل التي أقوم بها، فماذا أفعل؟

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

كما يمكنك تحديث البيانات المرتبطة باسم النطاق مع تحديد جهة اتصال إدارية مختلفة؛ وهناك بعض المسجلين يقومون بعرض أداة وسيطة على الإنترنت تتيح لك إدارة هذه البيانات بنفسك؛ والبعض الآخر يمكن أن يقوم بعمل هذه التحديثات إذا قمت بالاتصال بخدمة العملاء لديهم.
المشاهدات 1801 | التعليقات 4
قديمة 28 - 03 - 2012, 20:25
المشاركة 2
صورة 'available' الرمزية
available
.:: عضو متألق ::.
تاريخ الإنضمام: 20 - 11 - 2008
رقم العضوية : 62569
العمر: 38
المشاركات: 8,597
16
افتراضي رد : شروحات وتفاصيل حول النطاقات مقدمة من هيئة ال ICANN
اعتماد المسجلين: كيف تصبح أحد المسجلين المعتمدين في ICANN

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

يرجى مراجعة معايير التأهيل الموضحة في بيان سياسة اعتماد المسجلين.
يرجى مراجعة الاعتبارات المالية التي تنطبق على عملية أن تصبح أحد المسجلين المعتمدين لدى ICANN.
يرجى مراجعة الاتفاقيات والسياسات الحاكمة التي تنطبق على كل المسجلين المعتمدين لدى ICANN.
التقدم بطلب للحصول على اعتماد التسجيل. للتقدم بطلب، يجب عليك ملء طلب اعتماد المسجلين وإرساله إلى ICANN مع رسم تقديم طلب غير قابل للاسترداد قيمته 3500 دولار أمريكي. ولكي يتسنى لنا معالجة طلبك بأقصى سرعة ممكنة، يرجى إرسال إجابات محددة ودقيقة للغاية بالإضافة إلى كل وثائق الدعم اللازمة. وتكمن الأسباب الرئيسية في التأخير في معالجة أي طلب في فقد وثائق الدعم والحصول على إجابات غير مكتملة أو مبهمة على الأسئلة الواردة في الطلب. يرجى توجيه الاستفسارات التي قد تتراءى لك حول طلبك إلى [email protected].
بعد الانتهاء من مراجعة طلبك وإجراء أية عمليات استعلام وبحث لازمة للمتابعة، ستقوم ICANN بإخبارك عن طريق البريد الإلكتروني بقرارها بشأن طلب الحصول على الاعتماد الخاص بك.
وفور الموافقة على طلب الاعتماد، يجب إكمال الخطوات الإضافية التالية:

التوقيع على اتفاقية اعتماد المسجلين مع ICANN ودفع رسوم الاعتماد. يمثل الإصدار الحالي من الاتفاقية وثيقة معايير يقوم كل المسجلين بالتوقيع عليها مع ICANN. يتم منح اعتماد ICANN حاليًا لمدة 5 سنوات. (ستقوم ICANN بعمل الاتفاقية الخاصة بك وإرسالها إليك، بالإضافة إلى فاتورة بالنسبة السنوية الثابتة من رسوم الاعتماد).
التوقيع على اتفاقية مستودع بيانات المسجلين مع ICANN والتسجيل مع Iron Mountain، وكيل المستودعات المعيَّن لدى ICANN (الاتفاقية الموحدة مع ICANN وIron Mountain [PDF, 45 KB])، أو مع مقدم خدمة كطرف ثالث (TPP) لتوفير خدمات المستودع. على نحو ما هو مقرر في الفقرة 3 - 6 من اتفاقية اعتماد المسجلين (RAA)، يتحتم على كل المسجلين المعتمدين لدى ICANN إيداع معلومات تسجيل معينة تخص نطاقات gTLD. ويمثل تنفيذ كل من اتفاقية RAA واتفاقية مستودع بيانات المسجلين (RDE) مع ICANN الخطوة الأخيرة في عملية اعتماد المسجلين لدى ICANN.
وبمجرد إرجاع اتفاقية RAA وRDE الموقع عليهما ودفع رسوم الاعتماد، ستقوم ICANN بإخطار السجلات السارية لاعتمادك وإضافتك إلى قائمة المسجلين على http://www.icann.org/registrars/accredited-list.html وInterNIC Registrar Listing. يجب عليك إكمال تفاصيل العقد والتفاصيل المالية والفنية مع مشغلي السجل.
إكمال عملية الإعداد لاتفاقية التسجيل الخاصة بك لمالكي الأسماء المسجلة. وتتطلب اتفاقية اعتماد المسجلين لدى ICANN تضمين بعض الأحكام الخاصة في اتفاقية التسجيل هذه. بالإضافة إلى ذلك، تبنت ICANN سياسة موحدة لحل النزاعات المتعلقة بأسماء النطاقات، والتي يجب اتباعها من قبل كل المسجلين المعتمدين. قد ترغب أيضًا في تنفيذ سياسة الخصوصية لتلبية متطلبات اتفاقية الاعتماد الخاصة بك.
تشغيل الخدمة. بعد الانتهاء من تنفيذ الخطوات المذكورة أعلاه، يجب أن تكون في وضع يمكنك من خلاله البدء في تقديم الخدمات للجمهور بمجرد اجتياز عملية الاختبار وأن تصبح تشغيليًا مع كل السجلات المعنية التي قمت بالاعتماد لها.
قديمة 28 - 03 - 2012, 20:27
المشاركة 3
صورة 'available' الرمزية
available
.:: عضو متألق ::.
تاريخ الإنضمام: 20 - 11 - 2008
رقم العضوية : 62569
العمر: 38
المشاركات: 8,597
16
افتراضي رد : شروحات وتفاصيل حول النطاقات مقدمة من هيئة ال ICANN
سياسة التذكير ببيانات Whois


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


ملاحظات

المقدمة: قامت ICANN باعتماد سياسة التذكير ببيانات Whois (WDRP ) كسياسة إجماع في 27 مارس 2003. هذا ويجب على جميع أمناء السجلات المعتمدين من ICANN الالتزام بـ WDRP فيما يتعلق بالتسجيلات التي يقومون برعايتها في كافة نطاقات المستوى الأعلى والتي تم اعتمادهم لها. في ما يلي تفاصيل شروط الالتزام.

العملية التي تم اعتماد السياسة من خلالها: تم وضع سياسة WDRP كسياسة إجماع من خلال قرار مجلس ICANN رقم 03.41، والذي تم اعتماده بواقع تصويت 13-1-0 من قبل مجلس إدارة ICANN في 27 مارس 2003. حيث أنها إحدى السياسات الأربع التي تتعلق بقضايا Whois والتي أوصى بإنشائها مجلس منظمة دعم الأسماء العامة (GNSO ) كسياسات إجماع بواقع تصويت 21-3-0 في 20 فبراير 2003.

هذا فيما استند تصويت مجلس GNSO ومجلس الإدارة إلى تقرير فريق عمل Whois النهائي التابع لمجلس GNSO بشأن دقة بيانات Whois والوصول المجمع. فيما قام التقرير بتحديد مدى الاتفاق والاختلاف بين المجموعات المتأثرة وعملية التوعية المستخدمة لبحث تحقيق التمثيل المناسب لوجهات نظر المجموعات التي تتزايد فرص احتمال تأثرها فضلا عن طبيعة وقوة الدعم والمعارضة المبررة للسياسة المقترحة.

هذا وقد تم نشر التقرير على موقع الويب الخاص بـ ICANN في 11 مارس 2003 مع دعوة للتعليق العام. واستجابة لهذه الدعوة وردت تعليقات عامة متعددة تمت دراستها من قبل مجلس الإدارة، حيث تمت مناقشة التقرير في جلسة منتدى ICANN العام والذي عقد بمدينة ريو دي جانيرو في 26 مارس 2003.

جدير بالذكر أنه تم تقديم إشعار اعتماد هذه السياسة لجميع أمناء السجلات بتاريخ 16 يونيو 2003 وفقًا للقرار رقم 03.42.

الوقت المحدد لتحقيق الالتزام: وفقا لما نصت عليه الأقسام الفرعية 3.7.8، و4.1 و4.4 من اتفاقية اعتماد أمناء سجلات ICANN ، يجب على جميع مسجلي ICANN المعتمدين تحقيق الالتزام بـ WDRP بحلول "تاريخ الالتزام" الخاص بهم كما هو منصوص عليه في الجملتين التاليتين. حيث أن تاريخ الالتزام لأمناء السجلات الذين تم اعتمادهم قبل 16 يونيو 2003 هو 31 أكتوبر 2003. في حين أن تاريخ الالتزام لأمناء السجلات الذين تم اعتمادهم بعد 16 يونيو 2003 هو التاريخ الفعلي لاتفاقيات الاعتماد الخاصة بهم.

إضافة إلى ذلك، يتعين على كل أمين سجل، في بداية تاريخ الالتزام الخاص به، وقبل مرور عام على تاريخ إنشاء كل تسجيل لرعاة أمين السجل، تقديم إشعار WDRP (منصوص عليه أدناه) إلى المسجل المنوط بهذا التسجيل. فعلى سبيل المثال، يشترط أن يقدم أي أمين سجل يكون تاريخ التزامه في 31 أكتوبر 2003، إشعار WRDP للتسجيلات التي ترعاها في الجدول التالي:

تاريخ الالتزام 31 أكتوبر 2003
اسم النطاق تاريخ الإنشاء تقديم إشعار WDRP في موعد لا يتجاوز
example.com 14 أكتوبر 1995 14 أكتوبر 2004 (وبحلول 14 أكتوبر من كل عام بعد ذلك)
example.biz 25 يونيو 2003 25 يونيو 2004 (وبحلول 25 يونيو من كل عام بعد ذلك)
example.info 15 يونيو 2003 15 يونيو 2004 (وبحلول 15 يونيو من كل عام بعد ذلك)
example.net 12 نوفمبر 1997 12 نوفمبر 2003 (وبحلول 12 نوفمبر من كل عام بعد ذلك)
example.org 1 يناير 1993 1 يناير 2004 (وبحلول 1 يناير من كل عام بعد ذلك)
example.example.name 31 ديسمبر 2002 31 ديسمبر 2003 (وبحلول 31 ديسمبر من كل عام بعد ذلك)
(ملاحظة: قد لا يجوز تقديم إشعارات WDRP للتسجيلات ذات تواريخ الإنشاء في 29 فبراير بما يزيد عن الأول من مارس في السنوات غير الكبيسة.)

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

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

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

نموذج إشعار WDRP : قامت ICANN بتقديم نموذج إشعار WDRP التالي بهدف مساعدة أمناء السجلات في إعداد الإشعار المطلوب:

[نموذج] رسالة تذكير بيانات Whois



عزيزي العميل،

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

النطاق: example.com
اسم أمين السجل: IANA_RESERVED

المسجل:
الاسم: هيئة أرقام الانترنت المخصصة (IANA )
العنوان: 4676 Admiralty Way, Suite 330
المدينة: Marina del Rey
ولاية/إقليم: CA
الدولة: US
الرمز البريدي: 92092

جهة الاتصال الإدارية
الاسم: هيئة أرقام الانترنت المخصصة (IANA )
العنوان: 4676 Admiralty Way, Suite 330
المدينة: Marina del Rey
ولاية/إقليم: CA
الدولة: US
الرمز البريدي: 92092
رقم الهاتف: 310-823-9358
رقم الفاكس: 310-823-8649
البريد الالكتروني: [email protected]

للاتصال الفني:
اسم: هيئة أرقام الانترنت المخصصة (IANA )
العنوان: 4676 Admiralty Way, Suite 330
المدينة: Marina del Rey
ولاية/إقليم: CA
الدولة: US
الرمز البريدي: 92092
رقم الهاتف: 310-823-9358
رقم الفاكس: 310-823-8649
البريد الالكتروني: [email protected]

تاريخ الإنشاء الأصلي: 11/01/2001
تاريخ الانتهاء: 11/01/2001

معلومات خادم الاسم:
خادم الاسم: a.iana-servers.net.
خادم الاسم: b.iana-servers.net.
خادم الاسم: c.iana-servers.net.

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

شكرًا لاهتمامكم.

مع أطيب الأمنيات،
أمين السجل المعتمد من ICANN الخاص بك
قديمة 28 - 03 - 2012, 20:29
المشاركة 4
صورة 'available' الرمزية
available
.:: عضو متألق ::.
تاريخ الإنضمام: 20 - 11 - 2008
رقم العضوية : 62569
العمر: 38
المشاركات: 8,597
16
افتراضي رد : شروحات وتفاصيل حول النطاقات مقدمة من هيئة ال ICANN
سياسة حل نزاعات تحويل أمين السجل


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

ستنطبق سياسة حل نزاعات التحويل ( TDRP ) وإجراءات متوافقة على جميع أسماء النطاقات التي يتم إرسال طلبات التحويل إليها عند أو بعد تاريخ سريان مفعول هذه السياسة.

1. التعريفات
1.1 لجنة تحكيم حل النزاعات

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

1.2 مزود حل النزاعات

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

1.4 نموذج التفويض ( FOA )

نموذج التفويض ( FOA ) - وهو نموذج الموافقة المعياري المتطلب استخدامه من قبل أمين السجل المكتسب وأمين الخاص بالسجلات للحصول على تفويض من المسجل أو مسؤول الاتصال الإداري من أجل المعالجة الصحيحة لتحويل رعاية اسم النطاق من أمين سجل إلى آخر.

1.5 أمين السجل المكتسب

هو أمين السجل الذي أرسل إلى السجل طلب تحويل رعاية اسم النطاق من أمين السجل.

1.6 أمين السجل الخاص بالسجلات

أمين سجل الخاص بسجلات اسم النطاق الذي تلقى السجل له طلب تحويل الرعاية.

1.7 المسجَل

المسجَل هو الفرد أو المنظمة التي تسجل اسم نطاق معين. يتمتع هذا الفرد أو المنظمة بحق استخدام اسم النطاق ذاك لفترة معينة من الوقت، شريطة تلبية شروط معينة ودفع رسوم التسجيل. هذا الفرد أو المنظمة هو " الهيئة الاعتبارية " الملزمَة بأحكام اتفاقية الخدمة ذات الصلة مع مشغل السجل لـ TLD المعني.

1.8 السجل (مشغل السجل)

المنظمة المفوضة من قبل ICANN لتقديم خدمات التسجيل لـ TLD معين إلى أمناء سجلات معتمدين لدى ICANN.

1.9 القوانين التكميلية

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

1.10 سياسة التحويل

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

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

2.1 مشغل السجل من المستوى الأول

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

2.2 لجنة تحكيم حل النزاعات من المستوى الثاني

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

2.3 نظام التحديدات

يجب تقديم دعوى النزاع خلال فترة لا تزيد عن ستة ( 6 ) أشهر اعتبارًا من ارتكاب المخالفة المزعومة لسياسة التحويل. وفي حالة ادعاء أمين السجل بأن التحويل يخالف السياسة، يجب اعتبار تاريخ اكتمال التحويل على أنه التاريخ الذي حدثت به " المخالفة المزعومة". وفي حالة ادعاء أمين السجل المكتسب أنه ينبغي أن يكون التحويل قد حدث، يجب اعتبار التاريخ التي تم فيه استلام NACK (كما هو مبين أدناه) من قبل السجل على أنه التاريخ الذي حدثت به " المخالفة المزعومة".

3. إجراءات النزاع على المستوى الأول (السجل)
3.1 تقدم أمين السجل لطلب الإنفاذ لدى مشغل السجل المناسب

3.1.1 يحق لكلٍ من أمين السجل المكتسب أو أمين السجل ( " أمين السجل المتقدم بشكوى " ) الخاص بالسجلات التقدم بطلب إنفاذ. ويجب القيام بذلك بما يتفق مع القوانين التكميلية المعتمدة لدى مشغل السجل المعني.

3.1.2 يجب إرسال طلب الإنفاذ إلى السجل والمدعى عليه (المسجل غير المتقدم بالشكوى) بالشكل الإلكتروني، وينبغي أن ينطبق عليه ما يلي :

( 1 ) الطلب بأن يتم إرسال طلب الإنفاذ لاتخاذ قرار حوله وفقاً لسياسة حل النزاعات وتحويل المسجل والقوانين التكميلية المطبقة.

( 2 ) تقديم الاسم والعنوان البريدي وعنوان البريد الإلكتروني، وأرقام الهاتف والفاكس للمسجل المتقدم بالشكوى والممثلين المفوضين من قبل المسجل المتقدمين بشكوى للتصرف نيابة عن المسجل المتقدم بشكوى في الإجراءات الإدارية.

( 3 ) تقديم اسم المدعى عليه وجميع المعلومات (بما في ذلك أي عنوان بريدي أو عنوان بريد إلكتروني وأرقام الهاتف والفاكس) المعروفة للمسجل المتقدم بشكوى فيما يتعلق بكيفية الاتصال مع المدعى عليه أو أي ممثلين عن المسجلين، بما في ذلك معلومات الاتصال بناءاً على التعاملات قبل الشكوى.

( 4 ) تحديد اسم (أسماء) النطاق التي تخضع لطلب الإنفاذ.

( 5 ) تحديد الحادثة (الحوادث) التي أدت إلى النزاع.

( 6 ) وصف الأساس الذي يقوم عليه طلب الإنفاذ طبقاً للسياسة.

( 7 ) تحديد التعويضات المحددة الذي يتم السعي إلى تحقيقها (إما اعتماد التحويل أو رفضه).

( 8 ) تحديد أية إجراءات قانونية أخرى تم البدء بها أو إنهائها ذات صلة أو علاقة مع أي من اسم (أسماء) النطاقات موضوع الشكوى.

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

( 10 ) الاختتام بالبيان التالي، ويتبعه توقيع المشتكي أو ممثله المفوض :

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

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

3.1.3 يمكن أن يكون طلب الإنفاذ متعلق بأكثر من اسم نطاق واحد، شريطة أن تكون أسماء النطاقات متعلقة بنفس المسجل المتقدم بالشكوى والمدعى عليه، وتكون المطالبات ناشئة عن نفس الظروف الواقعية أو مشابهة لها.

3.1.4 يجب أن يكون ملحقاً بطلب الإنفاذ الإثباتات التالية المؤيدة بالوثائق (بحسب ما ينطبق وما هو متوفر) بالشكل الإلكتروني إذا أمكن، بالإضافة إلى جدول يفهرس هذه الإثباتات :

( 1 ) بالنسبة إلى المسجل المكتسب :

أ. نموذج تفويض ( "FOA" ) مكتمل

ب. نسخة عن مخرجات Whois حول تاريخ المباشرة بالتحويل، والتي تم استخدامها لتحديد مسؤولي اتصال التحويل المفوضين

ج. نسخة عن إثبات الهوية المستخدم

د. نسخة عن الاتفاقية الثنائية، أو القرار النهائي لهيئة حل النزاعات، أو أمر المحكمة في حالة تغير مسجل السجل بشكل متزامن مع تحويل المسجل

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

( 2 ) بالنسبة إلى مسجل السجل :

أ. نموذج تفويض ( FOA ) مكتمل من مسجل السجل إذا انطبق الأمر

ب. نسخة عن مخرجات Whois حول تاريخ المباشرة بالتحويل

ج. التاريخ السابق لتعديلات Whois التي تم إجرائها على التسجيل المطبق

د. إثباتات على أحد ما يلي إذا تم رفض التحويل :

الاحتيال
إجراء UDRP
أمر محكمة
هوية مسؤول الاتصال الإداري أو المسجل المتنازعين طبقاً للبند 4 [متطلبات مسجل السجل]
دفعة النزاع المطبقة بالإضافة إلى إثبات بأنه قد تم وضع التسجيل بحالة انتظار
اعتراض خطي علني من حامل الاسم المسجل أو مسؤول الاتصال الإداري
حالة الإغلاق بالإضافة إلى إثبات على وسيلة معقولة لإزالة المسجل حالة الإغلاق بحسب البند __ من المعروض __ من هذه الاتفاقية
اسم النطاق ضمن 60 يوماً من التسجيل المبدئي
اسم النطاق ضمن 60 يوماً من التحويل السابق.
هـ. نسخ عن جميع الاتصالات التي تم إجرائها إلى المسجل المكتسب فيما يتعلق بطلب التحويل المطبق، بالإضافة إلى أية ردود من المسجل المكتسب.

3.2 ينبغي أن يكون أمام المسجل غير المتقدم بشكوى ( " المدعى عليه " ) سبعة ( 7 ) أيام ميلادية اعتبارًا من استلام طلب الإنفاذ لتحضير رد على طلب الإنفاذ ( " الرد").

3.2.1 يجب إرسال الرد بالشكل الإلكتروني إلى كلٍ من السجل والمسجل المتقدم بالشكوى، ويجب أن يتضمن مايلي :

( 1 ) الرد بشكل محدد على البيانات والمزاعم المتضمنة في طلب الإنفاذ (يجب أن يتوافق هذا الجزء من الرد مع أية صياغة أو حدود صفحات مبينة في القوانين التكميلية لمزود حل النزاعات).

( 2 ) تقديم الاسم والعنوان البريدي وعنوان البريد الإلكتروني، وأرقام الهاتف والفاكس للمدعى عليه (المسجل غير المتقدم بشكوى).

( 3 ) تحديد أية إجراءات قانونية أخرى تم البدء بها أو إنهائها ذات صلة أو علاقة مع أي من اسم (أسماء) النطاقات موضوع طلب الإنفاذ.

( 4 ) التحديد بأنه قد تم إرسال نسخة عن الرد إلى المسجل المتقدم بالشكوى.

( 5 ) الاختتام بالبيان التالي، ويتبعه توقيع المشتكي أو ممثله المفوض :

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

( 6 ) إلحاق أية وثائق أو إثباتات أخرى يعتمد عليها المدعى عليه، بالإضافة إلى جدول يفهرس هذه الوثائق.

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

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

3.3 يجب على مشغل السجل مراجعة جميع الوثائق المطبقة ومقارنة بيانات الاتصال / المسجل مع تلك المتضمنة ضمن قاعدة بيانات Whois المفوضة، والتوصل إلى استنتاج خلال فترة لا تزيد عن 14 يوماً بعد استلام الرد .

3.3.1 إذا كانت البيانات المشمولة في طلب الإنفاذ لا تتطابق مع البيانات المبينة في قاعدة بيانات Whois المفوضة، يجب على مشغل السجل الاتصال مع كل مسجل وطلب المزيد من الوثائق.

3.3.2 إذا لم يستطع المسجل المكتسب تقديم نموذج تفويض ( FOA ) مكتمل يتضمن بيانات تطابق البيانات المتضمنة في قاعدة بيانات Whois المفوضة، ينبغي عندها على مشغل السجل اتخاذ قرار بأن يتم رفض التحويل ورده. وفي حالة السجل السميك، إذا كان Whois لمسجل السجل غير قابل للولوج أو غير صالح، ينبغي استخدام Whois لمشغل السجل. في حالة السجل الرقيق، إذا كان Whois لمسجل السجل غير قابل للولوج أو غير صالح، ينبغي على مشغل السجل إبلاغ ICANN وتأجيل حل النزاع إلى أن يتم حل هذه المشكلة المعينة من قبل ICANN.

3.3.3 في حالة رفض مسجل السجل طلباً بتحويل اسم النطاق ( "NACKs" )، ينبغي على مسجل السجل تقديم أدلة على أحد العوامل التي تم السماح لها بـ NACK. إذا لم يستطع مسجل السجل تقديم أدلة تثبت أي من العوامل، وقدم المسجل المكتسب للسجل نموذج تفويض ( FOA ) مكتمل مع بيانات تطابق تلك المتضمنة في قاعدة بيانات Whois المفوضة، ينبغي عندها الموافقة على معالجة التحويل.

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

3.4 رسوم خدمة حل النزاعات من المستوى الأول

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

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

3.4.3 يجب عدم تمرير هذه الرسوم إلى المسجل.

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

3.5 توفر إجراءات المحكمة

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

4. إجراءات حل النزاعات على المستوى الثاني مع مزود حل نزاعات
4.1 يمكن اللجوء إلى خدمات لجنة تحكم حل النزاعات في أي من الموقفين التاليين :

( 1 ) يمكن للمسجل المتقدم بشكوى اختيار تخطي عملية حل النزاع من المستوى الأول على مستوى السجل وإرسال طلب الإنفاذ مباشرة إلى مزود حل النزاعات.

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

4.2 طلب الإنفاذ المبدئي

4.2.1 في حالة اختيار المسجل المتقدم بشكوى إرسال طلب الإنفاذ إلى مزود حل النزاعات بدلاً من إرسال طلب الإنفاذ إلى مشغل السجل المطبق، يجب أن تنطبق الواجبات والمسؤوليات المبينة في البنود 3.1 إلى 3.2 أعلاه.

4.2.2 يجب على لجنة تحكيم حل النزاعات التي عيّنها مزود حل النزاعات مراجعة جميع الوثائق المطبقة ومقارنة بيانات الاتصال / المسجل مع تلك المتضمنة ضمن قاعدة بيانات Whois المفوضة، والتوصل إلى استنتاج خلال فترة لا تزيد عن ثلاثين ( 30 ) يوماً بعد استلام الرد من المدعى عليه.

( 1 ) إذا كانت البيانات لا تتطابق مع البيانات المبينة في قاعدة بيانات Whois المفوضة، يجب على لجنة تحكيم حل النزاعات الاتصال مع كل مسجل وطلب المزيد من الوثائق.

( 2 ) إذا لم يستطع المسجل المكتسب تقديم نموذج تفويض ( FOA ) مكتمل يتضمن بيانات تطابق البيانات المتضمنة في قاعدة بيانات Whois المفوضة عند وقت طلب التحويل، ينبغي عندها على لجنة تحكيم حل النزاعات اتخاذ قرار بأن يتم رفض التحويل ورده. في حالة السجل السميك، إذا كان Whois لمسجل السجل غير قابل للولوج أو غير صالح، ينبغي استخدام Whois المطبق لمشغل السجل. في حالة السجل الرقيق، إذا كان Whois لمسجل السجل غير قابل للولوج أو غير صالح، ينبغي على مزود حل النزاعات تأجيل حل النزاع إلى أن يتم حل هذه المشكلة المعينة.

( 3 ) في حالة رفض مسجل السجل طلباً بالتحويل ( "NACKs" )، ينبغي على مسجل السجل تقديم أدلة على أحد العوامل التي تم السماح لها بالبند 3.1.4 ( 2 ) من سياسة حل النزاعات. إذا لم يستطع مسجل السجل تقديم أدلة تثبت أي من العوامل، وقدم المسجل المكتسب إلى مزود حل النزاعات نموذج تفويض ( FOA ) مكتمل مع بيانات تطابق تلك المتضمنة في قاعدة بيانات Whois المفوضة عند وقت طلب التحويل، ينبغي عندها الموافقة على التحويل.

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

( 5 ) خيارات اتخاذ القرار المتعلقة بلجنة تحكيم حل النزاعات هي مقصورة على مايلي :

أ. الموافقة على التحويل

ب. رفض التحويل (أو طلب إعادة اسم النطاق إلى مسجل السجل في الحالات التي حدث بها التحويل بالفعل)

4.3 استئناف قرار حل النزاعات من المستوى الأول أو توصل مشغل السجل إلى نتيجة " عدم اتخاذ قرار".

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

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

4.3.3 في كلتا الحالتين، يجب الإشارة إلى الوثائق التي يتقدم بها المسجل إلى مزود حل النزاعات باسم " الاستئناف".

4.3.4 ينبغي على المستأنف إرسال طلب الاستئناف بالشكل الإلكتروني، وينبغي أن ينطبق عليه ما يلي :

( 1 ) طلب أن يتم إرسال الاستئناف لاتخاذ قرار حوله وفقاً للسياسة وهذه القوانين.

( 2 ) تقديم الاسم والعنوان البريدي وعنوان البريد الإلكتروني، وأرقام الهاتف والفاكس المستأنف وأي ممثلين مفوضين من قبل المستأنف للتصرف نيابة عن المستأنف في الإجراءات الإدارية.

( 3 ) تقديم اسم المستأنف ضده وجميع المعلومات (بما في ذلك أي عنوان بريدي أو عنوان بريد إلكتروني وأرقام الهاتف والفاكس) المعروفة للمستأنف ضده فيما يتعلق بكيفية الاتصال مع المستأنف ضده أو أي ممثلين عنه، بما في ذلك معلومات الاتصال بناءاً على ما قبل طلب الإنفاذ والتعاملات قبل الاستئناف.

( 4 ) تحديد اسم (أسماء) النطاق التي تخضع للاستئناف.

( 5 ) تحديد الحادثة (الحوادث) التي أدت إلى النزاع.

( 6 ) تحديد أساس الاستئناف، بما في ذلك الردود المعينة على نتائج مشغل السجل في عملية حل النزاع من المستوى الأول. (يجب أن يتوافق هذا الجزء من الرد مع أية صياغة أو حدود صفحات مبينة في القوانين التكميلية لمزود حل النزاعات).

( 7 ) تحديد التعويضات المحددة الذي يتم السعي إلى تحقيقها طبقاً للسياسة.

( 8 ) تحديد أية إجراءات قانونية أخرى معروفة لدى المستأنف تم البدء بها أو إنهائها ذات صلة أو علاقة مع أي من اسم (أسماء) النطاقات موضوع الشكوى.

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

( 10 ) الاختتام بالبيان التالي، ويتبعه توقيع المستأنف أو ممثله المفوض :

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

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

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

4.3.6 يجب أن يكون ملحقاً بالاستئناف أية إثباتات مؤيدة بوثائق لم يتم إرسال مسبقاً إلى مشغل السجل أثناء حل النزاع من المستوى الأول.

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

4.3.8 يجب على لجنة تحكيم حل النزاعات مراجعة جميع الوثائق المطبقة والتوصل إلى استنتاج خلال فترة لا تزيد عن ثلاثين ( 30 ) يوماً بعد استلام الاستئناف.

( 1 ) يجب على لجنة تحكيم حل النزاعات تقديم الأسئلة إلى السجل أو المستأنف أو المستأنف ضده.

( 2 ) يجب أن تستلم لجنة تحكيم حل النزاعات الردود على جميع هذه الأسئلة خلال فترة 7 أيام.

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

( 4 ) يجب أن تكون التعويضات التي تأمر لجنة تحكيم حل النزاعات بها هي مقصورة على ما يلي :

الموافقة على التحويل
رفض التحويل (أو طلب إعادة اسم النطاق إلى مسجل السجل في الحالات التي حدث بها التحويل بالفعل)
4.4 رسوم خدمة حل النزاعات من المستوى الثاني

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

4.4.2 في حالة أن المسجل المتقدم بشكوى أو المستأنف، أيهما ينطبق، لم يفز بالنزاع من المستوى الثاني، يحق لمزود حل النزاعات الاحتفاظ برسوم التقدم بالشكوى.

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

4.5 توفر إجراءات المحكمة

ينبغي ألا تمنع الإجراءات المبينة أعلاه أمين السجل من تحويل النزاع إلى محكمة ذات اختصاص قضائي لاتخاذ قرار مستقل قبل البدء بتلك الإجراءات الإدارية أو بعد انتهائها. وإذا قررت لجنة تحكيم حل النزاعات أنه يجب تحويل تسجيل اسم نطاق (إما إلى المسجل المكتسب، أو بشكل بديل، إعادته من المسجل المكتسب إلى مسجل السجل)، ينتظر هذا المسجل أربعة عشرة ( 14 ) يوماً ميلادياً بعد إبلاغه بالقرار قبل تنفيذه. ثم سينفذ السجل القرار بعدها ما لم يستلم خلال فترة أربعة عشرة ( 14 ) يوماً ميلادياً من أي من طرفي النزاع وثائق رسمية (مثل نسخة عن شكوى مختومة من كاتب المحكمة) بأنه قد تم رفع قضية قانونية فيما يتعلق باسم (أسماء) النطاق المعنية. إذا استلم السجل هذه الوثائق، بحسب ما هو مطبق، خلال فترة أربعة عشرة ( 14 ) يوماً ميلادياً، لن يتم تنفيذ القرار إلا في الحالات التالية: ( 1 ) تقديم أدلة بأن الأطراف قد توصلت إلى حل لهذا النزاع، أو ( 2 ) تقديم أدلة إلى مشغل السجل بأنه قد تم رفض أو سحب القضية القانونية، أو ( 3 ) استلام نسخة عن أمر من تلك المحكمة بصرف القضية القانونية أو طلب إجراءات معينة فيما يتعلق باسم النطاق.
قديمة 28 - 03 - 2012, 20:35
المشاركة 5
صورة 'available' الرمزية
available
.:: عضو متألق ::.
تاريخ الإنضمام: 20 - 11 - 2008
رقم العضوية : 62569
العمر: 38
المشاركات: 8,597
16
افتراضي رد : شروحات وتفاصيل حول النطاقات مقدمة من هيئة ال ICANN
سياسات حل النزاع لأسماء النطاقات



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

سياسة حل النزاع لأسماء النطاقات الموحدة (الواردة أدناه) قابلة للتطبيق على كافة نطاقات gTLD . وقد تنطبق سياسات حلول نزاعات إضافية على حالات معينة فقط في نطاقات TLD فردية . وهي أيضًا سترد فيما يلي .

ملاحظة : في حالة شكاوى خدمة العملاء بشأن مسجّل لاسم نطاق، يرجى الاطلاع على صفحة تقارير مشكلات المسجلين .

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


لقد تبنى المسجلون المعتمدون من قبل ICANN في كافة نطاقات gTLD (.aero, .asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .org, .pro, .tel and .travel ) سياسة حل النزاع لأسماء النطاقات الموحدة (UDRP). قد يتم البدء في إجراءات النزاع الناشئة من إساءة استخدام عمليات التسجيل المزعومة لأسماء النطاقات (على سبيل المثال، الاحتلال الإلكتروني) من خلال مالك حقوق العلامة التجارية . إن سياسة UDRP هي سياسة بين المسجل والعميل التابع له وهي مشمولة في اتفاقيات التسجيل لكافة المسجلين المعتمدين من قبل ICANN .

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

سياسة حل النزاع لأهلية الميثاق (CEDRP) تتبعها نطاقات TLD المدعومة .aero, .coop, .museum, and.travel للاعتراضات على تسجيل اسم نطاق ما على الأسس التي لا تلتزم فيها شركة التسجيل بمتطلبات الأهلية (المنصوص عليها في ميثاق النطاقات المدعومة) الخاصة بتسجيل اسم نطاق في نطاق TLD المحدد . ويستطيع أي شخص أو كيان تقديم اعتراض على اسم نطاق مُسجل وفقًا لسياسة CEDRP .

سياسة حل النزاع لأهلية الميثاق
القواعد الخاصة بسياسة حل النزاع لأهلية الميثاق
قائمة مزودي خدمة حلول النزاعات المعتمدين
سياسة إعادة النظر في الأهلية

سياسة إعادة النظر في الأهلية (ERP) مدمجة في اتفاقيات مع شركات التسجيل فيما يتعلق بتسجيلات اسم نطاق في .aero . وهي تحدد البنود والشروط . التي ترتبط بأي اعتراض على قرار صادر من الراعي فيما يتعلق بأهلية التسجيل في .aero. وقد وُضعت السياسة من قبل راعي نطاق .aero . فهي ليست إحدى سياسات ICANN وهي مقدمة هنا كمرجع فقط . ويمكن الحصول على المزيد من المعلومات من موقع ويب الراعي .

سياسة حل النزاع لمتطلبات الأهلية

سياسة حل النزاع لمتطلبات الأهلية (ERDRP) يتبعها نطاق TLD .name المقيد غير المدعوم . ويجب أن تتكون تسجيلات نطاق .name من الاسم الشخصي للفرد أو الاسم الشخصي لشخصية وهمية (بشرط أن يمتلك المُسجل علامة تجارية أو حقوق خدمة علامة في الاسم الشخصي لهذه الشخصية) . كما يمكن استخدام الرموز الرقمية بالاشتراك مع أي نوع من أنواع اسم الشخص السابقة . ويمكن إرسال الاعتراضات على تسجيلات نطاق .name على الأسس التي لا تفي بمتطلبات الأهلية وفقًا لسياسة ERDRP . وكذلك فإن التسجيلات الدفاعية وتسجيلات عناوين البريد الإلكتروني لنطاق المستوى الثاني معرّضة للاعتراض وفقًا لسياسة ERDRP . ويستطيع أي شخص أو كيان تقديم اعتراض على تسجيل ما وفقًا لسياسة ERDRP .

سياسة حل النزاع لمتطلبات الأهلية
القواعد الخاصة بسياسة حل النزاع لمتطلبات الأهلية
قائمة مزودي خدمة حلول النزاعات المعتمدين
سياسة متطلبات أهلية ميثاق نطاق .ASIA

تنطبق سياسة متطلبات أهلية ميثاق آسيا (.ASIA CERP) على أسماء النطاقات المسجلة في نطاقات TLD .ASIA المدعومة . تقتصر تسجيلات نطاق .ASIA على أعضاء مجتمع إنترنت دول آسيا بالكامل ودول آسيا المطلة على المحيط الهادئ . ويمكن إرسال الاعتراضات على تسجيلات نطاق .ASIA على الأسس التي لا تفي بمتطلبات الأهلية وفقًا لسياسة CERP . ويمكن الحصول على المزيد من المعلومات من موقع ويب نطاق .ASIA .

سياسة حل نزاع متطلبات الأهلية لنطاق .cat ( Política de Resolució de Conflictes sobre Requisits d'Admissibilitat del .cat )

تنطبق سياسة حل نزاع متطلبات الأهلية لنطاق .cat (.cat ERDRP) على أسماء النطاقات المسجلة لنطاق TLD .cat المدعوم . وتقتصر تسجيلات نطاق .cat على أعضاء المجتمع الكتالوني اللغوي والثقافي . ويمكن إرسال الاعتراضات على تسجيلات نطاق .cat على الأسس التي لا تفي بمتطلبات الأهلية وفقًا لسياسة ERDRP . ويمكن الحصول على المزيد من المعلومات من موقع ويب نطاق .cat .

سياسة الاعتراض على التسجيلات الدفاعية للملكية الفكرية

تنطبق سياسة الاعتراض على التسجيلات الدفاعية للملكية الفكرية (IPDRCP) على التسجيلات الدفاعية للملكية الفكرية في نطاق .pro TLD ، المقصور استخدامه على الأعضاء المتدربين المعتمدين في مهن معينة (وهي حاليًا المهن الطبية، والقانونية، والمحاسبية). ويمكن عمل تسجيل دفاعي للملكية الفكرية فقط من خلال مالك علامة تجارية مؤهلة أو تسجيل علامة خدمة . وتوفر سياسة IPDRCP وسيلة للاعتراض على التسجيلات الدفاعية للملكية الفكرية فيما يتعلق باحتمالية اضطلاع شركة التسجيل تلك بمؤهلات التسجيل . ويستطيع أي شخص أو كيان بدء إجراء من إجراءات سياسة IPDRCP من خلال إرسال الاعتراض وفقًا للقواعد .

سياسة الاعتراض على التسجيلات الدفاعية للملكية الفكرية
القواعد الخاصة بسياسة الاعتراض على التسجيلات الدفاعية للملكية الفكرية
قائمة مزودي خدمة حلول النزاعات المعتمدين
سياسة الاعتراض على المؤهلات

سياسة الاعتراض على المؤهلات (QCP) يتبعها نطاق TLD .pro المقيد غير المدعوم، الذي يقتصر استخدامه على الأعضاء المرخصين في مهن معينة . ويمكن تقديم الاعتراضات على التسجيل على أساس أن شركة التسجيل لم تضطلع بمؤهلات التسجيل وفقًا لسياسة QCP . ويستطيع أي صاحب مصلحة تقديم اعتراض على تسجيل ما وفقًا لسياسة الاعتراض على المؤهلات .

سياسة الاعتراض على المؤهلات
القواعد الخاصة بسياسة الاعتراض على المؤهلات
قائمة مزودي خدمة حلول النزاعات المعتمدين
سياسة حل نزاع القيود

تنطبق سياسة حل نزاع القيود (RDRP) على نطاق TLD .biz المقيد غير المدعوم . يجب استخدام القيود في نطاق .biz TLD أو قصد استخدامها في المقام الأول للأعمال أو الأغراض التجارية حسنة النية . ويمكن تقديم الاعتراضات على تسجيل ما أو على استخدام نطاق اسم محدد على أساس أنه لا يتم أو لن يتم استخدامه في المقام الأول للأعمال أو الأغراض التجارية حسنة النية وفقًا لسياسة RDRP . ويمكن تقديم الاعتراضات وفقًا لسياسة RDRP من خلال أي طرف يقوم برفع شكوى ضد مزود خدمة حلول النزاعات المعتمد .

سياسة حل نزاع القيود
قواعد سياسة RDRP الإضافية
قائمة مزودي خدمة حلول النزاعات المعتمدين
سياسة معارضة بدء تشغيل علامة تجارية

لقد كانت سياسة معارضة بدء تشغيل علامة تجارية (STOP) متاحة فقط لأصحاب الملكية الفكرية المدرجين في خدمة طلب IP أثناء مرحلة بدء التشغيل لسجل نطاق biz (في الفترة من 25 يونيو وحتى 21 سبتمبر 2001 ). ولم تعد سياسة STOP متاحة كسياسة لحل النزاع لأسماء نطاقات .biz . ويمكن عمل النزاعات وفقًا لسياسة UDRP ، أو RDRP ، أو المحاكم المتاحة . لمزيد من المعلومات، الرجاء الرجوع إلى موقع مشغل السجل .

سياسة الاعتراض على النشوء

لقد تم تطبيق سياسة الاعتراض على النشوء (SCP) فقط أثناء فترة نشوء نطاق .info TLD. وقد تمت إدارة الاعتراضات وفقًا لسياسة الاعتراض على النشوء من قبل مشغل السجل (Afilias) . ومع انتهاء فترة النشوء التي مدتها مائة وعشرون (120) يومًا، يمكن للأطراف المتنازعين بشأن صلاحية تسجيل النشوء استخدام سياسة UDRP أو من خلال المحاكم المتاحة . لمزيد من المعلومات، الرجاء الرجوع إلى موقع مشغل السجل .

سياسة حل نزاع الانتقال

تنطبق سياسة حل نزاع الانتقال (TDRP) على المعاملات التي يقوم فيها مالك اسم النطاق بنقل أو محاولة نقل اسم نطاق إلى مُسجل جديد . وتتعلق سياسة TDRP بنزاعات المسجلين وفقًا لسياسة الانتقال الداخلي بين المسجلين ، التي تتبعها نطاقات TLD المتمثلة في .biz, .com, .info, .name, .net, .org, and .pro . ويمكن تقديم الإجراءات وفقًا لسياسة TDRP ضد مشغل السجل المناسب أو ضد مزود حل نزاع مستقل . ويستطيع أي مسجل معتمد من قبل ICANN اتخاذ إجراء من إجراءات سياسة TDRP ضد مسجل آخر من خلال إرسال شكوى طبقًا للقواعد الإضافية لمشغل السجل المحدد أو مزود حلول النزاعات .

سياسة حل نزاع الانتقال
قائمة مزودي خدمة حلول النزاعات المعتمدين
إجراءات

قائمة الإجراءات مرتبة حسب تاريخ البدء
أداة بحث خاصة بفهرس إجراءات سياسة UDRP (محدثة يوميًا)
أداة بحث خاصة بقرارات سياسة UDRP (نص كامل ، محدّثة أسبوعيًا)
ملخص إحصائي للإجراءات
عملية الموافقة على مزودي خدمة حل النزاع

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

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

أن يكونوا على دراية بالسياسة ذات الصلة والقواعد المتعلقة بها .
أن يرسلوا طلب تقديم بواسطة البريد الإلكتروني إلى العنوان ( [email protected] ) وبواسطة البريد العادي :

Dispute Resolution Service Provider Applications
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292-6601 USA
ويجب أن يحتوي الطلب على ما يلي :

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

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

استفسار خطورة ربط ريسلر الدومينات بسكربت WHMCS

أدوات الموضوع ابحث في الموضوع
ابحث في الموضوع:

البحث المتقدم
طرق العرض


الساعة معتمدة بتوقيت جرينتش +3 . الساعة الآن : 18:51.
المعهد غير مسؤول عن أي اتفاق تجاري أو تعاوني بين الأعضاء
فعلى كل شخص تحمل مسئولية نفسه إتجاه مايقوم به من بيع وشراء وإتفاق وأعطاء معلومات موقعه
التعليقات المنشورة لا تعبر عن رأي معهد ترايدنت ولا نتحمل أي مسؤولية قانونية حيال ذلك (ويتحمل كاتبها مسؤولية النشر)

جميع الحقوق محفوظة Traidnt 2019
  • 00966138651070
  • 00966138648289
  • 2051033691
Powered by vBulletin® Version 3.8.11 .Copyright ©2000 - 2019, Jelsoft Enterprises Ltd
SEO by vBSEO ©2011, Crawlability, Inc.