الخلاصة

  • توثّق واجهة NIR API العامة لدى APNIC الطلب POST /nir-delegations/asn ومهمة غير متزامنة قد تنتهي بالحالة SUCCESSFUL، لكن الدليل يصف العملية بأنها تفويض من مخزون NIR. أما خريطة الطريق فتتحدث عن تفويض ASN مباشرة إلى أصحاب حسابات NIR عبر MyAPNIC وNIR API. لا يجوز اعتبار العبارتين دلالة واحدة من دون نسخة وتاريخ إصدار.
  • قالت مواد المجلس التنفيذي في سبتمبر 2024 إن تحديث سجل APNIC الأساسي وNIR API كان قيد التنفيذ، ثم وضعت مواد ديسمبر مشروع «التعيين المباشر لـASN لدى NIR» في الاختبار النهائي. تسجل خريطة الطريق الحالية المشروع في 2025، لكنها تترك target وchangelog فارغين. لا يثبت ذلك فشل المشروع أو إلغاءه أو عدم نشره، بل يثبت فقط غياب رابطة عامة بين هذه المراحل والإنتاج.
  • يستطيع APNIC نشر إيصال صغير للإصدار والضمان، موقع أو قابل للعنونة بالتجزئة، يربط هوية عنصر خريطة الطريق، ونسخة API والمخطط، ووقت التحويل، ونطاق NIR، ومعنى مصدر المورد، ومجموعات الهجرة، ونتائج المطابقة المجمعة بين السجل الأساسي وWhois وRDAP.

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

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

تكتسب المسألة أهميتها لأن ASN ليس حقلاً إدارياً صغيراً. إنه معرّف عالمي لنظام مستقل يعلن المسارات وفق سياسته. ويعني تخصيصه أن سلسلة من القرارات صارت نافذة: الأهلية، ومصدر الرقم، وصاحب الحساب، وجهات الاتصال، والأساس السياسي، ومكان التسجيل العلني.

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

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

من العمل الجاري إلى الاختبار النهائي، ثم فراغ في الرابط

تقدم مقالة APNIC عن تسوية بيانات NIR في 2019 خلفية مفيدة من IPv4. شرحت أن التفويضات بعد نموذج اتحادي أقدم انتقلت منذ 2004 إلى تخصيصات وتعيينات من المخزون الإقليمي المشترك، تسجل مباشرة في سجل APNIC. ومع ذلك بقيت كتل موروثة، واحتاجت التواريخ وأصحاب الموارد والتحويلات المفقودة إلى تسوية لاحقة.

لا تثبت هذه القصة كيف صمم APNIC مسار ASN. الاستنتاج المشروع أضيق: مصدر المخزون، ومسؤولية خدمة العضو، ومكان الكتابة، وترحيل البيانات القديمة يمكن أن تتغير كل منها على نحو مستقل. ولذلك لا تكفي كلمة «مباشر» وحدها لوصف بنية السلطة.

في سبتمبر 2024، سجلت مواد المجلس التنفيذي أن تحديثات السجل الأساسي وNIR API الخاصة بالتعيين المباشر لـASN لدى NIR كانت قيد التنفيذ. يشير ذلك إلى عمل في سطحين تنفيذيين، لا إلى مجرد تحرير وثيقة. لكنه لا يحدد تاريخ التحويل أو NIR التي شملها.

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

ما زالت حزمة فبراير 2025 تعرض المشروع ضمن أعمال خريطة الطريق الجارية. أما بيانات خريطة الطريق الحالية فتضعه في 2025، وتسمي فريق Registry، وتربطه بـARMS وMyAPNIC. وتقول إن الحل المقترح يستخدم MyAPNIC وNIR API للتفويض المباشر إلى أصحاب حسابات NIR.

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

يقول التقرير السنوي لـAPNIC لعام 2025 إن أهداف خريطة المنتجات الفصلية تحققت. ويسمي أمثلة محددة، منها تحديث تفويض Whois، وكائنات RPKI Signed Checklist، ونموذج أولي لبنية RDAP الجديدة. لا يرد اسم مشروع التعيين المباشر لـASN في النص الكامل المحفوظ.

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

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

نقطة النهاية تثبت شكلاً قابلاً للاستدعاء، لا معنى الإصدار

يشرح توثيق NIR API العام أن NIR تستخدم الواجهة لإدارة معلومات التسجيل للحسابات الفرعية. ويعرض درس ASN إرسال POST /nir-delegations/asn مع بيانات اتصال ستستخدم في Whois وRDAP، ثم استلام موقع لمهمة غير متزامنة. وتشرح الإرشادات العامة متابعة حالة المهمة واستخدام Idempotency-Key.

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

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

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

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

لـIdempotency-Key وظيفة محددة أيضاً. فهو يقلل خطر تنفيذ النية نفسها مرتين عندما يعيد العميل الإرسال. لا يثبت أن النية عولجت وفق نسخة السياسة الصحيحة، أو أن المخزون الصحيح اختير، أو أن NIR دخلت مجموعة الهجرة الصحيحة. يمكن للعملية القديمة أن تنفذ مرة واحدة بدقة كاملة.

أما SUCCESSFUL فهو حقيقة معاملة. يخبر العميل بأن المهمة وصلت إلى نهاية ناجحة وفق تعريف الخدمة. لكنه لا يشرح هل شمل النجاح تحديث السجل الأساسي فقط، أم إسقاط Whois وRDAP، أم تسوية لاحقة. ولا يحمل الأدلة التي استخدمتها NIR للموافقة، ولا يحدد النسخة الدلالية التي فسرت الطلب.

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

الكتابة المباشرة لا تلغي طبقة NIR

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

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

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

لكن المكسب يرفع أيضاً قيمة تفسير السلسلة. يجب أن يعرف المراجع ما الذي أصبح «مباشراً»: هل هو مصدر ASN من المخزون الإقليمي؟ أم عملية تسجيل القرار؟ أم النقل بين نظام NIR وAPNIC؟ أم العناصر الثلاثة معاً؟ لا يجوز أن تجيب كلمة واحدة عن أسئلة مختلفة.

تضيف السجلات القديمة تعقيداً آخر. هل انتقلت ASN القائمة إلى بنية الحسابات الفرعية الجديدة؟ هل بقيت مجموعات تاريخية مرتبطة بمخزون NIR القديم؟ هل استمر مسار التوافق لبعض الجهات؟ من دون تاريخ هجرة وإصدار، قد تكون سجلات صحيحة حالياً لكنها ناتجة عن سلاسل سلطة مختلفة لا تظهر للقارئ.

تقول سياسة أرقام APNIC الحالية إن طالب ASN يستطيع التقدم إلى APNIC أو إلى NIR المناسبة، وإن كل ASN معين يجب أن يسجل علناً في قاعدة Whois لدى APNIC أو NIR المعنية. تحدد السياسة النتيجة المؤسسية المطلوبة، لكنها لا تسجل البرنامج الذي أنتج كل نتيجة.

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

برنامج المراجعة العام يقيس مجموعة أخرى

لدى APNIC برنامج لمراجعة تفويض الموارد. تشمل مادته العامة تحليل البيانات، وعينات الالتزام بالسياسة، وتقييم الإجراءات، ودقة سجلات الحسابات، ودعم NIR، وإمكان مراجعة الاتفاقات مستقبلاً. وفي تحديث الربع الثاني من 2026، قالت APNIC إن العمل اكتمل مع JPNIC وTWNIC وKRNIC، بينما استمر تحليل NIR أخرى.

هذا مرفق مهم للمساءلة، لكن نطاقه العام المعلن محدد: عشر سنوات من تفويضات IPv4 وتحويلاتها. ولا تعرض المادة العامة هذا البرنامج بوصفه مراجعة لمعاملات ASN الجديدة، ولا تنشر عدد التفويضات المباشرة أو الجهات المتبنية أو نسبة اختلاف الطلب عن مخرجات Whois وRDAP.

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

المقام هو ما يمنح النسبة معناها. فمراجعة تفويضات IPv4 التاريخية تستطيع كشف مشاكل في تاريخ العناوين. وعدّ مهام API يستطيع وصف حجم المعالجة. وحالة خريطة الطريق تستطيع وصف التقدم الإداري. حتى لو كانت المقاييس الثلاثة صحيحة، فهي لا تجيب عن السؤال نفسه.

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

إيصال صغير يكمل السلسلة

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

تبدأ الوثيقة بهوية عنصر خريطة الطريق ومعرّف إصدار لا يتغير، ووقت التحويل الإنتاجي، ونطاق النشر، وحالة الرجوع، ونسخة API، ونسخة المخطط. ويجب أن تعرّف بوضوح الدلالة القديمة والجديدة، بما فيها ما إذا جاء ASN من مخزون NIR أو مباشرة من المخزون الإقليمي الذي تديره APNIC.

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

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

وأخيراً، يربط الإيصال بخريطة الطريق، وملاحظة الإصدار، وتوثيق API الخاص بالنسخة، ونتيجة الضمان اللاحقة. إذا صححت APNIC خطأ، تضيف إصداراً أو تصحيحاً بدلاً من محو الحد التاريخي الذي اعتمد عليه المشغلون.

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

بالنسبة إلى مهندس NIR، يقل وقت البحث بين تذاكر الدعم ومحاضر الاجتماعات وسلوك الشفرة. وبالنسبة إلى عضو APNIC، تصبح حدود المسؤولية مفهومة. وبالنسبة إلى الباحث، لا يعود توثيق testbed دليلاً عرضياً على الإنتاج. أما المراجع اللاحق فيستطيع اختيار المجموعة الصحيحة قبل حساب أي نسبة.

لا يدّعي هذا التحليل أن نقطة النهاية الحالية خاطئة. ولا يدّعي أن المشروع لم ينشر. بل يقول إن الأدلة المتاحة تثبت أشياء مختلفة: قدرة API، ومرحلة مشروع، ونية خريطة طريق. لا تثبت أن هذه الأشياء الثلاثة هي الإصدار نفسه.

يملك APNIC معظم المكونات الصعبة بالفعل: سياسة مؤسسية، وAPI موثقة، ومهام غير متزامنة، ومفاتيح لعدم التكرار، وإسقاطات عامة إلى Whois وRDAP. العنصر الناقص أبسط من نظام جديد: ذاكرة عامة للإصدار تربط المكونات عند لحظة التغيير.

المصادر