الخلاصة

  • ذكر صاحب ACSP 2026.4 أنه أنشأ Detailed Reassignment من NET تابع له إلى منظمة أخرى، ثم رُفض طلب GET للمقبض باستخدام مفتاح الجهة الأصلية، بينما نجح مفتاح المنظمة المستلمة. وقال إن الأصل ظل قادراً على DELETE وعلى GET عبر mostSpecificNet عند تقديم عنواني البداية والنهاية الدقيقين.
  • أغلقت ARIN الاقتراح في 30 مارس 2026 بعد مناقشة أدوات أخرى لاسترجاع المعلومات وخطط تطوير مستقبلية، وقررت أن تغيير الصلاحيات غير ضروري آنذاك. لا تؤكد الإجابة كل خطوة في رواية المرسل، وحالة Closed ليست شهادة نشر أو إصلاح.
  • هناك مبرر قوي للفصل: المستلم في إعادة التخصيص التفصيلية يدير سجله، بينما يحتفظ المسجل المباشر بسلطة الاسترداد. كما أن بيانات Whois/RDAP العامة ليست حمولة NET الموثقة نفسها.
  • يمكن سد الفجوة من دون توسيع السلطة، عبر معاينة حذف تعرض هوية ثابتة، وعلاقة الأصل، ووجود فروع، ومسار التذكرة، والآثار، ورمز إصدار؛ مع مصفوفة قدرات تربط الفاعل والعلاقة ونوع NET والمسار والفعل والحقول والشرط والنتيجة.

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

تفرق إرشادات ARIN لإدارة سجلات الموارد بين reassignment البسيطة والتفصيلية وreallocation. لا يحصل العميل البسيط على إدارة مباشرة. أما المنظمة المستلمة لإعادة تخصيص تفصيلية فتحصل على سلطة إدارة، مع بقاء سلطة reclaim لدى المسجل المباشر. وقد تتوزع بعض صلاحيات DNS العكسي وIRR بين الطرفين. وفي reallocation يستطيع المستلم أن يعيد التوزيع لاحقاً.

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

إذن ليس صحيحاً أن DELETE يجب دائماً أن يفتح GET، أو أن GET يفتح PUT. لكن الفعل المسموح يحتاج إلى دليل يساوي غرضه. ولأن الاسترداد قد يكون تدميرياً، فلا بد أن يشمل الحد الأدنى من الدليل هوية الهدف الحالية.

ما تقوله الوثيقة الرسمية وما لا تقوله

قُدم ACSP 2026.4 في 3 مارس 2026. وصف صاحبه إنشاء Detailed Reassignment من شبكة يملكها إلى Org أخرى. وقال إن طلب GET للشبكة الفرعية بالمقبض فشل مع مفتاح الأصل لغياب الإذن، وإن مفتاح المنظمة المستلمة وحده نجح.

وأضاف أنه يستطيع حذف الشبكة نفسها، والحصول عليها إذا استخدم البداية والنهاية الدقيقتين في mostSpecificNet، والعثور على المعلومات العامة في Whois بالمقبض أو عنوان IP. ثم طالب بمنح الأصل GET وPUT، بحجة أن من يستطيع الحذف وإعادة الإنشاء يستطيع الوصول إلى أثر مشابه.

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

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

لكنها تكفي لطرح سؤال عقدي: هل يستطيع المشغل أن يعرف، من الوثائق والواجهات، أي علاقة ومسار وحقول تحكم نتيجة العملية قبل تنفيذها؟

الطريق البديل يحتاج معرفة مسبقة

تعرض وثائق Reg-RWS GET بواسطة NETHANDLE، وGET عبر mostSpecificNet/STARTIP/ENDIP، وDELETE وPUT بالمقبض. يعيد مسارا GET حمولة NET، بينما يعيد DELETE حمولة طلب مرتبط بتذكرة، ويتلقى PUT حمولة NET ثم يعيد الحالة المعدلة.

هذه الطرق لا تبدأ من المعرفة نفسها. المقبض هو هوية ثابتة في السجل. أما النطاق الدقيق فيتطلب من المتصل أن يعرف حدَّي الشبكة مسبقاً. وWhois/RDAP سطح عام يجيب عن سؤال اكتشاف مختلف.

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

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

أثر DELETE يتبدل بوجود الشبكات التابعة

تقول الوثائق إن DELETE يطبق على reassignment أو reallocation فقط. إذا لم توجد شبكات موزعة تحت الهدف، فقد يُعالج الطلب تلقائياً ويعيد معلومات عن الشبكة المحذوفة. وإذا وُجدت فروع، ينشأ طلب عبر تذكرة، ويجب انتظار نجاحه قبل منح المساحة لعميل آخر.

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

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

معاينة استرداد لا حمولة إدارة

يمكن أن تحتوي المعاينة على ثمانية عناصر فقط:

  1. مقبض NET ثابت ونطاق عناوين موحد؛
  2. فئة الكائن وعلاقته المباشرة بالأصل؛
  3. نوع المستلم من دون معلومات اتصال خاصة؛
  4. وجود NET فرعية؛
  5. توقع المعالجة الآلية أو عبر تذكرة؛
  6. ملخص أثر DNS وIRR وكائنات التوجيه؛
  7. الإخطارات وأثر التدقيق المتوقع؛
  8. رمز إصدار قصير العمر.

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

إلى جانبها، يجب نشر مصفوفة قابلة للإصدار تكون وحدتها:

دور الفاعل × العلاقة × فئة NET × مسار التعريف × الفعل × مجموعة الحقول × الشرط المسبق × النتيجة

تفصل المصفوفة بين reassignment البسيطة والتفصيلية وreallocation، وبين الابن المباشر والنسل الأبعد، وبين المقبض والنطاق والدليل العام، وبين الحمولة الكاملة والعامة والمقتضبة. وتبين الحقول الثابتة والنتيجة التلقائية أو المرتبطة بتذكرة وطريق التصحيح الآمن.

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

الإغلاق يخص الاقتراح لا الحقيقة التقنية كلها

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

لكن Closed لا يعني أن كل نتيجة أُقرت، أو أن تحديثاً نُشر، أو أن السؤال لن يعود. وعبارة أن التغيير غير ضروري «في ذلك الوقت» تحد القرار بدقة.

إذا كان القصد أن الأصل يستطيع reclaim من دون قراءة NET Payload الكامل بالمقبض، فينبغي أن يظهر ذلك في مصفوفة القدرات. وإذا كان النطاق الدقيق أو ARIN Online هو الفحص المعتمد قبل الحذف، فيجب بيان ما يفترضه من مخزون وما يثبته من هوية.

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