إشعار ICANN بإنهاء اعتماد IPIP يضم قائمتين — واحدة فقط تسمي المخالفات

الخلاصة

• أصدرت ICANN في 28 أغسطس 2026 إشعارًا بإنهاء اتفاق اعتماد شركة التسجيل IPIP INC. بموجب البند 5.5.4، وحددت 13 سبتمبر تاريخًا لسريان الإنهاء.
• أساس الإجراء المعلن هو عدم معالجة أربع مخالفات بحلول 26 أغسطس: خدمة RDAP، وإيداعات بيانات شركة التسجيل لدى جهة الضمان، ورسوم الاعتماد المتأخرة، ورابط آلية طلب كشف بيانات التسجيل غير العامة.
• استخدمت الوثيقة لاحقًا وصف «مخاوف إضافية» لمسائل أخرى، ثم عرضت نقل الأسماء وإلغاء ترخيص الشعار والالتزامات المستمرة بوصفها نتائج منفصلة.
• سجل علني لمعالجة كل بند يمكن أن يربط السلطة بالدليل والمهلة والرد والقرار، من دون كشف مراسلات خاصة أو بيانات شخصية.

قرار صدر ونتيجة لم تبدأ بعد

يوجد في هذا الخبر تاريخان لأن هناك حالتين مختلفتين.

في 28 أغسطس، وجهت ICANN إلى IPIP INC.، صاحبة رقم شركة التسجيل 3774 لدى IANA، إشعارًا بإنهاء اتفاق اعتماد شركات التسجيل لعام 2013 بموجب البند 5.5.4. وتقول الفقرة نفسها إن الإنهاء يصبح نافذًا في 13 سبتمبر، أي بعد 16 يومًا تقويميًا من الإشعار، وفق البند 5.6.

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

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

القائمة الأولى: أربع مخالفات ذات وظائف مختلفة

يقول إشعار الإنهاء إن IPIP لم تعالج المخالفات الواردة في إشعار 5 أغسطس قبل مهلة 26 أغسطس، ثم يسمي أربع مخالفات باقية.

الأولى تتعلق بخدمة دليل RDAP. وبحسب ICANN، لم تشغّل IPIP خدمة تعيد بيانات التسجيل المطلوبة لجميع أسماء gTLD النشطة التي ترعاها، وفق دليل التنفيذ وملف الاستجابة الجاريين. وكان إخطار 5 أغسطس قد قال إن الشركة سجلت عنوانًا أساسيًا للخدمة، إلا أن استعلامات النطاقات التي اختبرتها ICANN لم تُعد بيانات التسجيل.

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

هذه ليست أربعة أسماء لعطل واحد. فـRDAP خدمة وصول عامة إلى بيانات التسجيل، وضمان البيانات أداة استمرارية لدى طرف معتمد، والرسوم التزام مالي تعاقدي، ورابط الكشف هو مدخل عام للطلب يفرضه القسم 10.1 من Registration Data Policy. يختلف المستخدم المتأثر والدليل المطلوب ومعيار المعالجة في كل حالة.

يمكن مراجعة قواعد الضبط نفسها. تقول ICANN إن ملف gTLD RDAP الصادر في فبراير 2024 أصبح إلزاميًا في 21 أغسطس 2025. كما أصبحت مواصفة ضمان بيانات شركات التسجيل لعام 2025 نافذة في اليوم نفسه. وتوجب سياسة بيانات التسجيل أن توضح صفحة الكشف صيغة الطلب وطريقة الرد والمدة المتوقعة.

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

القائمة الثانية لا تحمل الاسم نفسه

بعد البنود الأربعة تغير الوثيقة تركيبها. تبدأ فقرة جديدة بعبارة «In addition» وتقول إن IPIP لم تعالج «additional concerns» — مخاوف إضافية.

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

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

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

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

التسلسل الزمني يثبت الإجراء لا الدافع

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

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

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

ما يأتي بعد القرار فئة ثالثة

ينتقل الإشعار بعد ذلك من الأساس إلى الأثر. تقول ICANN إنها ستتبع De-Accredited Registrar Transition Procedure لنقل الأسماء التي تديرها IPIP إلى شركة تسجيل معتمدة ومؤهلة. ويلغى ترخيص استخدام شعار ICANN اعتبارًا من 13 سبتمبر. كما تبقى بعض أحكام RAA بعد الإنهاء، ومنها حفظ بيانات التسجيل، والرسوم، وتسوية النزاعات، وحدود التعويضات المالية، فيما تظل الرسوم المتأخرة والمبالغ المحددة واجبة الدفع.

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

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

صف واحد لكل مسألة

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

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

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

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

تفيد كتابة Heng Lu هنا بوصفها ضابطًا للتحليل فحسب: حين تكون للسلطة المؤسسية آثار كبيرة، ينبغي ربطها بسلطة محددة ودليل ومسؤولية ومراجعة. مصدر سلطة ICANN هو العقد، لا المقالة النظرية. أما فائدتها فهي التنبيه إلى ألا توسع إعادة السرد العلني نطاق السلطة أو نطاق النتيجة من دون تصريح.

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

المصادر

1. ICANN — إشعار إنهاء IPIP INC.، 28 أغسطس 2026
2. ICANN — إشعار مخالفة IPIP INC.، 5 أغسطس 2026
3. ICANN — إشعارات المخالفة والتعليق والإنهاء وعدم التجديد
4. ICANN — اتفاق اعتماد شركات التسجيل والمواد المرتبطة
5. ICANN — Registration Data Policy
6. ICANN — gTLD RDAP Profile
7. ICANN — برنامج ضمان بيانات شركات التسجيل
8. ICANN — نهج وإجراءات الامتثال التعاقدي
9. ICANN — إنهاء الاعتماد
10. ICANN — De-Accredited Registrar Transition Procedure
11. Heng Lu — عندما تنفصل سلطة السجل عن المسؤولية