Skip to main content

تجديد اتفاقية سجل .com

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

  1. ملخص تنفيذي

    تنشر ICANN اليوم لإبداء التعليقات العامة اتفاقية Verisign المقترحة لتجديد اتفاقية سجل .com لعام 2006 بين ICANN وVerisign . هذا الاقتراح هو نتيجة مناقشات بين ICANN وVerisign ، وسينظر فيه مجلس إدارة ICANN بعد إبداء التعليقات العامة. وستنتهي صلاحية الاتفاقية الحالية في 30 نوفمبر 2012 . يمكن إرسال التعليقات العامة حتى 26 أبريل 2012 ، ورؤيتها على: http://www.icann.org/en/news/public-comment/com-renewal-27mar12-en.htm

    يصف هذا الملخص الجوانب المهمة من عملية تجديد اتفاقية السجل، ومحتويات تجديد الاتفاقية المقترح، وخلفية معينة عن الاتفاقية المقترحة. مرفق بهذا الملخص نسخة "بالخط الأحمر" من الاتفاقية وعدة مستندات تصف وتلخص الاقتراح. ستتبع الاتفاقيات القادمة التي من المتوقع تجديدها في عام 2012 مثل .biz و .info و .name و .org عملية مشابهة.

    1. عملية التجديد

      أحكام التجديد

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

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

      ستخضع الاتفاقيات القادمة التي من المتوقع تجديدها في عام 2012 مثل .biz و .info و .name و .org لأحكام مشابهة.

      مناقشات التجديد

      اتفاقية سجل .com المعدلة المقترحة هي نتيجة مناقشات بين ICANN وVerisign ، وسينظر فيها مجلس إدارة ICANN بعد إبداء التعليقات العامة. تلقت ICANN اقتراح Verisign حول أحكام التجديد، ثم تمت مناقشة التعديلات، واتفقت ICANN وVerisign على نشر أحكام الاتفاقية المقترحة، لتخضع لآراء المجتمع، واعتماد مجلسي إدارة ICANN وVerisign . تسعى معظم التعديلات المقترحة لتحديث اتفاقية .com وجعلها تتماشى مع gTLDs الأكبر والاتفاقيات الأحدث. لقد تم وضع التعديلات الأخرى لحماية وخدمة المشتركين بشكل خاص.

      التعليقات العامة

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

      مراجعة الالتزام التعاقدي

      كجزء من عملية التجديد، أجرت ICANN مراجعة لأداء Verisign مؤخراً بموجب اتفاقية السجل معه. وناقشت مراجعة الالتزام أربعة مجالات تشمل: توفر DNS ، والولوج المتكافىء للمسجلين إلى SRS ، والولوج إلى ملف المنطقة الجماعية، ودفع الرسوم المتطلبة، وإرسال التقارير الشهرية. لقد تم التحديد أن Verisign تمتثل لواجباتها التعاقدية. يمكن إيجاد التقييم على: http://www.icann.org/en/resources/compliance/reports/operator-verisign-com-27mar12-en.pdf [بي دي إف، 239 كيلوبايت]

    2. محتويات التجديد

      لقد تم اقتراح إجراء التعديلات على الاتفاقية من أجل تحقيق مايلي:

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

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

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

  2. وصف موجز بالتعديلات الأساسية

    لقد تم تنظيم هذا القسم بحسب:

    1. التغييرات لتحديث اتفاقية عام 2006 : على سبيل المثال، تبني معايير أمن واستقرار حديثة، وتحسين وسائل الالتزام، والتحسينات المتوقعة.
    2. التغييرات للتوافق مع اتفاقيات السجل الاخرى، بما في ذلك اتفاقية سجل .net لعام 2011 : على سبيل المثال، تحديث SLA وإضافة تحسينات متعلقة بالحماية والاستقرار.
    3. تغييرات أخرى: مثل الرسوم والالتزام بالتعاون مع أنشطة التزام المسجل التابع لـ ICANN .

    وتشمل أبرز التغييرات المقترحة مايلي:

    1. التغييرات لتحديث اتفاقية عام 2006

      1.1 . تمت مراجعة المواصفات الوظيفية ومواصفات الأداء لتحقيق مايلي:

      1.1.1 . تطلب دعم IPv6 : يجب أن يقبل مشغل السجل عناوين IPv6 على أنها غلو حيثما ينطبق الأمر، وعليه أن يقدم إلى IPv6 الولوج إلى نظام التسجيل المشترك (مثل EPP)، وWhois ، ومخادم DNS .

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

      1.1.3 . تطلب دعم DNSSEC : يجب على مشغل السجل تنفيذ امتدادات حماية نظام أسماء النطاقات Extensions (DNSSEC) لتوقيع ملفات منطقة TLD الخاصة به وقبول المواد الرئيسية للعامة من أسماء النطاقات الفرعية بطريقة محمية، وتوفير القدرة على التحقق من صحة البيانات المنشورة في DNS .

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

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

      1.1.6 . تطلب الالتزام بإرشادات IDNA وIDN : يجب على مشغل السجل الالتزام بأحدث المعايير الفنية فيما يتعلق بأسماء النطاقات الدولية، واتباع إرشادات تنفيذ ICANN IDN ، ونشر جداول IDN الخاصة به مع IANA .

      1.1.7 . السماح لـ ICANN باستخدام مواقع مراقبة متعددة لـ DNS ومراقبة استفسارات TCP : السماح لـ ICANN بتنفيذ نظام مراقبة اتفاقية مستوى خدمة جديد (يجب استخدامه مع gTLDs الجديدة أيضاً) لمراقبة خدمة DNS من مشغل السجل.

      1.2 . Whois : إضافة فقرة شرطية (في الملحق 5) تتطلب تبني بديل عن بروتوكول WHOIS ، إذا أو عندما يصبح معيارياً في IETF . من المتوقع أن يدعم هذا البروتوكول الجديد أسماء النطاقات الدولية وبياناتها، والاستفسار المعياري، والاستجابة، والتعامل مع الأخطاء... إلخ.

      1.3 . مواصفات التقارير الشهرية: تنسيق تقرير شهري خاضع للمراجعة (الملحق 4) لكي يتضمن المزيد من البيانات.

      1.4 . التدقيق: إضافة فقرة شرطية تمنح مجلس إدارة ICANN حقوق التدقيق التعاقدية لتسهيل جهود الالتزام التعاقدي.

    2. التغييرات للتماشي مع اتفاقيات السجلات الكبرى الأخرى

      2.1 . اتفاقية مستوى الخدمة: تعزيز مواصفات الأداء، بشكل يتوازى مع مواصفات الأداء المتطلبة في اتفاقية سجل .net الجديدة.

      2.2 . التهديدات على الأمن والاستقرار: إضافة فقرة شرطية جديدة ستسمح لمشغل السجل بالمنع المؤقت لتسجيل اسم أو أكثر في TLD من أجل الاستجابة لتهديد وشيك على أمن و/ أو حماية TLD أو الإنترنت.

      2.3 . استخدام بيانات المرور: التوضيح بأن استخدام بيانات المرور سيكون مقصوراً على بيانات نموذج السجل "الرقيق" حتى إذا كان ينبغي أن يتبع السجل نموذج السجل "السميك".

      2.4 . حظر الوظائف المتبدلة العالمية: التوضيح بأن حظر "SiteFinder " أو الوظائف المتبدلة العالمية الأخرى لا يحظر توفير خدمة الاسم أو أية خدمة أخرى غير خاصة بالسجل لمنطقة أو نطاق مستخدم لخدمات غير خدمات السجل.

      2.5 . التعويضات لـ ICANN : إضافة حقوق تعويضات مجلس الإدارة لمصلحة ICANN .

    3. تغييرات أخرى

      3.1 . رسوم السجل: استبدال المبلغ الإجمالي للرسوم ربع السنوية بناءً على 0.25 $ دولار أمريكي لكل معاملة في TLD . هذه زيادة كبيرة في مساهمة Verisign .

      3.2 . التعاون مع إجراءات الالتزام ضد المسجلين: إضافة فقرة شرطية تتطلب من مشغل السجل تنفيذ عمليات تعليق المشغل بشكل مؤقت التي تطلبها ICANN لتسهيل جهود التزام ICANN التعاقدي.

      3.3 . سقف الأسعار: لم يتم إجراء تغييرات جوهرية على الفقرة الشرطية المتعلقة بسقف الأسعار وزيادة الأسعار، تم تحديث الاتفاقية لتعكس سقف الرسوم الحالية البالغ 7.85 $ دولار أمريكي.

  3. الخلفية المتعلقة باتفاقية تجديد .com لعام 2012

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

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

    2. الانتقال إلى صيانة قاعدة بيانات Whois "السميكة": مسألة نقل سجل كبير حالي إلى Whois "سميك" يثير مسائل تشغيلية ومسائل أخرى تتطلب المزيد من المناقشات والاعتبارات. يقر GNSO بهذا، بصفته الهيئة التي وافقت مؤخراً على التعهد بعملية وضع سياسة (PDP ) حول المسألة (راجع، http://gnso.icann.org/resolutions/#201203). يمكن تنفيذ مثل هذا التغيير بشكل منفصل عن عملية التجديد.

    3. تسعير خدمات السجل: تسمح كلتا اتفاقيتي سجل .com الحالية والمقترحة للتجديد لـ Verisign بزيادة الأسعار التي تتقاضاها من المسجلين عن تسجيلات أسماء النطاقات أربعة مرات أثناء فترة الستة أشهر شريطة ألا تتخطى كل زيادة نسبة 7 %. لقد تم التفاوض على هذه الفقرة الشرطية بشكل أساسي بين Verisign من جهة، ووزارة العدل الأمريكية ووزارة التجارة الأمريكية من جهة أخرى. تحدد الاتفاقية الحالية (القسم 4.2) أن أحكام التسعير والتجديد (بالإضافة إلى أحكام أخرى) لا تخضع للتغيير عن طريق عملية تجديد الاتفاقية. إذا كان ينبغي تغيير أحكام تسعير سجل .com لكي تصبح متشابهة مع gTLDs الكبرى الأخرى، فمن الأرجح أن يسمح هذا لـ Verisign برفع الأسعار بنسبة 10 % سنوياً لكلسنة من سنوات الاتفاقية الستة، كما هو الحال في اتفاقيات مثل .biz و .info و .net و .org ملاحظة: إن اتفاقية سجل ICANN لـ gTLDs الجديدة واتفاقيات السجل لـ gTLDs الخاضعة للرعاية (.aero ، .asia ، .cat ، .coop ، .jobs ، .mobi ، .museum ، .post ، .pro ، .tel ، .travel ، و .xxx) لا تتضمن أية ضوابط تحكم.

    4. الحماية الجديدة للعلامة التجارية: إن اقتراح تجديد .com لا يتضمن متطلباً للالتزام بآليات حماية الحقوق (RPMs) التي تم وضعها لـ gTLDs الجديدة: التعليق السريع الموحد (URS)، وعملية حل النزاعات بعد التفويض (PDDRP)، ودار مقاصة العلامات التجارية. سنناقشها بترتيب معكوس، تعمل دارة مقاصة العلامات التجارية حالياً في فترة البدء التشغيلي للسجل، لذا فإنها لا تنطبق على com .

      لقد تم اعتماد التعليق السريع الموحد (URS) وعملية حل النزاعات بعد التفويض (PDDRP) حتى الآن ضمن سياق gTLDs الجديدة. إن التعليق السريع الموحد (URS) وعملية حل النزاعات بعد التفويض (PDDRP) هي جديدة وغير مختبرة، ويجب أن تتمتع بشكل مثير للجدل بفترة "تجربة" لضمان تصميمها وتنفيذها بشكل نشط قبل الطلب منها استيعاب عبء العمل الكامل لمساحة أسماء gTLD . ثانياً، تدبر المشتركون أسماء نطاقات في gTLDs الحالية وهم يفهمون معالم آليات حماية الحقوق (RPMs). تؤثر آليات حماية الحقوق (RPMs) على المشتركين، بالإضافة إلى السجلات والمسجلين. وثمة جدال بأنه ينبغي تطبيقها على gTLDs الحالية بعد مناقشة من الأسفل إلى الأعلى. وأخيراً، فإن آليات حماية الحقوق (RPMs) هذه غير موجودة في أية اتفاقية سجل أخرى، وليس لدى ICANN أي أساس لتطلبها – كما هو مبين أعلاه، ينبغي أن تكونا تفاقية التجديد مشابهة بالأحكام للسجلات الكبرى الأخرى.

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

    5. التكامل الرأسي: لم يتم اقتراح إجراء تغييرات على اتفاقية السجل فيما يتعلق بالتكامل الرأسي – حيث يكون سجل ومسجل gTLD مملوكين للهيئة نفسها، أو إذا كان ثمة تحالف بين السجل والمسجل. السبب بهذا هو مناقشة هذا الموضوع في نشر العملية التي وضعتها ICANN للنظر بإزالة قيود الملكية المشتركة <http://www.icann.org/en/resources/registries/removal-cross-ownership > والخطة لمواجهة المسائل المتبقية حول الموضوع كما هي مبينة في الرسالة المؤرخة في 12 مارس 2012 من ICANN إلى مجموعة السجلات المعنية GNSO http://www.icann.org/en/news/correspondence/icann-board-to-rysg-11mar12-en.pdf [بي دي إف، 107 كيلوبايت].

روابط الوثائق والمصادر

دخلت كل من ICANN وشركة VeriSign في اتفاقية سجل بلا رعاية في 1 مارس 2006 ، تقوم بموجبها Verisign بتشغيل اسم نطاق .com الأعلى. يمكن رؤية اتفاقية .com الحالية وملاحقها على: http://www.icann.org/en/about/agreements/registries/com

تدير شركة VeriSign أسماء النطاقات الأعلى العامة .com و .net و .name اعتباراً من نوفمبر 2011 ، أبلغت Verisign هن أكثر من 100 مليون اسم نطاق .com تحت الإدارة.


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