الخلاصة

  • رصد 26 أكتوبر 2026: يعلن AS139620 بادئتي IPv4 بـ512 عنوانًا و/48 واحدة؛ الرؤية 269/269 و257/257؛ سبعة جيران مرصودين، اثنان يسار المسار وخمسة يمينه.
  • في السجل يكتب الاسم PUBLIC COMPANY ويكتب حقل الشكل القانوني private_company، ودرجة 0.95 تقوم على شهادتين بقيمة 0.82، إحداهما لم تُفتح هذه المرة. ونص data_gaps في السجل نفسه ما زال يطلب التحقق من بلد الكيان القانوني.
  • ما يعنيه ذلك لمن يقرر: يؤكد السجل أن رقم AS موجود، وأن نظام التوجيه يراه منذ 4 سبتمبر 2019، وأنه كان ما يزال معلنًا في صباح 26 أكتوبر. ولا يؤكد الحجم ولا الملكية ولا الإدارة ولا أي رابطة قانونية. و512 عنوانًا هي عرض ضلع ترانزيت واحد، لا شبكة الشركة بأكملها.

ما رأته أجهزة التوجيه صباح 26 أكتوبر

أبدأ بالأرقام. يسجّل استعلام حالة التوجيه في RIPEstat وقت الاستعلام 2026-10-26T00:00:00 ونافذة الرصد 2026-10-26T08:00:00 (حالة التوجيه في RIPEstat). وفي هذا السجل قيمتان تستحقان التوقف: بلغت رؤية IPv4 269 من 269 من أقران RIS، ورؤية IPv6 257 من 257. علامة كاملة.

العلامة الكاملة بذاتها ليست خبرًا. مصدر بادئتين فقط، ما دام مشغّله الأعلى يمرّر المسارات على نحو طبيعي، لا يفوته أي مراقب. القيمة الإخبارية في المجموعة التالية: الفضاء المعلن بادئتا IPv4 بـ512 عنوانًا، وبادئة IPv6 واحدة بطول /48؛ والجيران المرصودون سبعة. ضُمّ هذه الثلاثة معًا فلا تظهر شبكة اتصالات وطنية، بل حافة ترانزيت مدلاة إلى الخارج.

قائمة البادئات هي هذه (البادئات المعلنة في RIPEstat): 103.142.144.0/24، و103.142.145.0/24، و2001:df1:4780::/48. ولكل منها خط زمني من 2026-10-12T08:00:00 إلى 2026-10-26T08:00:00. وهنا يجب القراءة بدقة: تشير ملاحظة في الاستجابة نفسها إلى استبعاد المسارات التي يراها أقل من عشرة أقران تغذية كاملة في RIS. أي أن الخط الزمني يقول إن البادئات الثلاث بقيت على هذه القائمة أربعة عشر يومًا؛ ولا يثبت أن شيئًا تغيّر في 12 أكتوبر.

من /23 واحدة إلى /24 اثنتين

يعطي السجل نفسه الرصد الأول والرصد الأخير. الأول بادئة 103.142.144.0/23 في 2019-09-04T16:00:00. والأحدث 103.142.145.0/24 في 2026-10-26T08:00:00.

بوصل النقطتين تظهر واقعة هندسية محددة: في سبتمبر 2019 كان المرئي تجميعًا واحدًا بـ512 عنوانًا؛ وفي صباح 26 أكتوبر 2026 صار المرئي بادئتي /24 بـ256 عنوانًا لكل منهما معلنتين منفصلتين. الحساب يستقيم. فـ/23 واحدة هي بالضبط اتحاد البادئتين /24، دون عنوان زائد أو ناقص.

لماذا فُصلت، لا يجيب الرصد. تقسيم البادئات قد يكون هندسة حركة على مستوى البادئة، أو فصلًا بحسب المشغّل الأعلى أو بحسب الموقع، أو مجرد إعداد قديم لم يجمعه أحد. وفي الاتجاه المعاكس، لو عادت البادئتان /24 إلى /23 واحدة يومًا، فذلك أيضًا تغيير يستحق التسجيل، وليس «لم يحدث شيء». والموقف الصحيح أن تُقرأ صيغة الإعلان كصيغة، لا كدافع.

سبعة جيران واتجاهان، وقبل أن نسمّيهم عملاء

توزّع بيانات التجاور (جيران AS في RIPEstat) الجيران السبعة على مجموعتين.

يسارًا اثنان: AS38082 بقوة 568 و1007 أقران IPv4 و0 أقران IPv6؛ وAS4651 بقوة 1109 و1230 قِرن IPv4 و499 قِرن IPv6. ويمينًا خمسة: AS139595 (قوة 248، 318، 0)، وAS139692 (248، 562، 0)، وAS139719 (44، 162، 0)، وAS151482 (248، 319، 0)، وAS154481 (309، 275، 205).

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

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

الأسطر التي يرسمها السجل

يرسم نص WHOIS لدى APNIC (APNIC WHOIS) ما يلي: aut-num هو AS139620، وas-name هو MTNPCL-AS-AP، وdescr هو MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY LIMITED، وcountry هو MM. ويعيد الاستعلام نفسه (استجابة استعلام APNIC) معرّف المنظمة ORG-MTNP1-AP.

ويعطي نظرة عامة AS في RIPEstat (نظرة عامة AS في RIPEstat) السلسلة نفسها للحائز، ويضع الرقم في الكتلة 139578-140601 الموصوفة بـAssigned by APNIC، ضمن سجل أرقام الأنظمة المستقلة 32-بت لدى IANA، ويبلّغ announced true لنافذة 2026-10-26T08:00:00.

والجدير بالانتباه هو الطريق الذي لا يمرّ. فكائن RDAP الخاص بـAPNIC نفسه (APNIC RDAP autnum) لم يُعِد سجلًا مقروءًا في هذا التحقق. أي أن تاريخ التخصيص وحالة الكائن وremarks — وهي ما يُقرأ عادة في RDAP — غير متاحة هنا في أي حقل. ومن يسأل في أي يوم خُصّص الرقم يحصل من هذا النص على أن الجواب غير موجود، لا على سنة مُقدَّرة.

وثيقتان ودرجة واحدة

الآن السجل نفسه. يعرض confidence_score بقيمة 0.95. وقائمة evidence_basis فيه تضم شهادتين فقط، ثقة كل منهما 0.82: وثيقة autnum على rdap.org موسومة Public registry record، ونظرة عامة AS في RIPEstat موسومة public routing data.

المشكلة ليست في الاستشهاد بمصدرين. الاستشهاد بمصدرين تصرّف أمين. المشكلة في كيف يصير 0.82 و0.82 درجةَ 0.95. فالسجل لا يذكر قاعدة التجميع. والأمر الأكثر عملية للقارئ هو أن الوثيقة المشار إليها على rdap.org (rdap.org autnum) لم تُحلّ في هذا التحقق، وكانت نتيجة الجلب inaccessible والمقتطف فارغًا.

من وثيقتين مذكورتين قُرئت واحدة ولم تُقرأ الأخرى، ومع ذلك ارتفعت الدرجة الجامعة من 0.82 إلى 0.95. هذا ليس اتهامًا بتلفيق، بل مشكلة قابلية إعادة الإنتاج. الرقم 0.95 يُقرأ كأنه «تمّت مطابقة وثيقتين مستقلتين»، وما جرى فعلًا هو «مدخلان بقيمة 0.82، أحدهما لم يُفتح هذه المرة». والعرض الأمين إما أن يعلن قاعدة التجميع، وإما أن يُبقي الدرجة عند حدّها الأدنى ما دامت الشهادة لا تُفتح.

تصادم الاسم والحقل

سلاسل السجل هي هذه: legal_name هو MYANMAR TELECOMMUNICATION NETWORK PUBLIC COMPANY L؛ والاسم البديل TELECOMMUNICATION NETWORK PUBLIC COMPANY L؛ وlegal_type هو private_company؛ وhq_country وregistration_jurisdiction كلاهما Myanmar (Burma)، وhq_country_code هو MM.

في الاسم PUBLIC COMPANY، وفي الحقل private_company. هذا تعارض بين سلسلتي نص. وأتوقف هنا. فلم أحصل على وثيقة تأسيس ولا مستخرج سجل تجاري ولا إثبات للشكل القانوني، ولذلك لا يمكن القول أي السلسلتين تخالف الواقع، ولا حتى استبعاد أن تكون كلتاهما صحيحة تحت تعريف قانوني ما. وكتابة أن الشركة «تنتحل صفة شركة مدرجة» هو بالضبط ما يرفضه هذا النص.

وفي البطاقة نفسها التماس ثانٍ. فهي تملأ الاختصاص القضائي بـMyanmar (Burma)، وتطلب في الوقت نفسه في data_gaps التحقق من «بلد الكيان القانوني»، ثم تتبع ذلك بالخدمات الحالية والأصول المرئية وصلات الشركة الأم أو التابعة وجهات الاتصال القيادية المسؤولة. قيمةٌ موضوعة وإقرارٌ في الوثيقة نفسها بأنها لم تُتحقَّق. هذا ليس دليل إدانة، بل ترتيب بناء البطاقة وقد بقي في المنتج النهائي.

والتماس الثالث أدقّ. الاسم القانوني في البطاقة ينتهي بحرف L منفردًا، ويكتب descr لدى APNIC الكلمة LIMITED. هما كتابتان لحائز واحد، ولا أشك في ذلك. أما أيّهما يطابق وثيقة التأسيس، فلا أعرف. لواحق أسماء الشركات تُختصر كثيرًا في الأسماء الدولية وتُكتب كاملة كثيرًا؛ ولا واحد من الأمرين مشكلة بذاته. تصبح مشكلة حين يجب نقل الاسم إلى حقل الطرف في عقد.

رقم AS واحد مصنّف virtual

يعدّد السجل موردًا واحدًا فقط: AS139620، مع resource_type بقيمة asn، وresource_class بقيمة virtual، وstatus بقيمة observed، وservice بقيمة ip_transit، والبلد Myanmar (Burma).

هناك كلمة لا أتجاوزها: virtual. رقم AS شيء ملموس في العنوان وفي الاستعلام وفي جدول المسارات، لكن السجل يصنّف المورد افتراضيًا. وما يعنيه virtual في منظومة الدليل هذه لم يتأتى الحصول على تعريفه في هذا التحقق. يمكن قراءته بمعنى «هذا المورد ليس كتلة عناوين مملوكة»، ويمكن قراءته بأي معنى تصنيفي آخر. وبلا تعريف، يبلّغ النص قيمة الحقل ولا يفسّرها بدلًا عن النظام.

وطبقة الخدمة واحدة أيضًا: roles بوصفها provider، والمنطقة MM، والخدمات ip_transit وmanaged_network. ومن بين الاثنتين لا تجد سوى ip_transit مقابلًا في شواهد التوجيه التي قرأتها: البادئات تُعلن، والجيران تمرّرها، وذلك هو الترانزيت. أما managed_network فيوجد حقلًا في السجل، لكن ليس له في المواد العامة المقروءة هنا مقابل قابل للتحقق. هو قائم كقيد في سجل، وليس بعدُ قدرةَ خدمة قابلة للاستشهاد.

الفراغ أعلى صوتًا من المكتوب

في هذه البطاقة يشغل الفراغ مساحة أكبر من المحتوى: relationships مصفوفة فارغة، وleadership_contacts مصفوفة فارغة، وrelated_events مصفوفة فارغة، وcontextual_references مصفوفة فارغة؛ وfirst_seen_at يساوي null، وexternal_id يساوي null، وsource_system يساوي null، وwebsite يساوي null، وprimaryDomain يساوي null. والحالة queued_for_profile_article، وlast_updated_at هو 2026-06-17T00:04:15.536Z.

هذه الفراغات ليست فضيحة، بل ترتيب بناء: يُرصد رقم AS أولًا، ثم تأتي الأشخاص والصلات والموقع. وصفحة الدليل هنا: مدخل دليل BTW للدائرة الاستراتيجية فقط. لكن لمن يريد أن يقرر بشيء منها، تحدّد الفراغات الأسئلة الممكنة أصلًا. فبلا leadership_contacts لا يمكن السؤال عمّن يردّ الهاتف عند عطل. وبلا relationships لا يمكن السؤال عمّن تكون الشركة قريبة له. وبfirst_seen_at مساوية null لا يمكن حتى القول متى دخل الكيان الدليل؛ وما يمكن قوله إن الرقم كان نظام التوجيه يراه في 4 سبتمبر 2019.

ما يحتاجه من يقرر فعلًا

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

والأربعة التي يحتاجونها فعليًا بسيطة على غير المتوقع: هل الشركة ما زالت تعمل؛ وهل تلك العناوين الـ512 ملكها؛ ومن المشغّلون الأعلى؛ ومن المسؤول إذا تعطّل شيء.

ما يقدّمه هذا التحقق: رقم AS موجود؛ ونظام التوجيه يراه منذ 2019-09-04T16:00:00؛ وكان ما يزال معلنًا في نافذة 2026-10-26T08:00:00؛ والرؤية تكاد تكون كاملة؛ والفضاء المعلن 512 عنوان IPv4 و/48 واحدة؛ وهناك سبعة جيران مرصودين، اثنان يسار المسار وخمسة يمينه.

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

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

ما يقلب هذا الحكم

نصٌّ عن حدود الشهادة ينبغي أن يقدّم شروط نقضه هو.

أولًا: إن عاد كائن RDAP لدى APNIC قابلًا للقراءة وأعطى تاريخ التخصيص وحالة الكائن، سقط فورًا قول «لا تاريخ تخصيص متاح»، ويجب إعادة كتابة الكلام على التسلسل الزمني.

ثانيًا: إن غيّر الدليل legal_type إلى public_company، أو قدّم أحد وثيقة تأسيس، فالتوتر بين الاسم والحقل يصير مفهومًا — في أي من الاتجاهين.

ثالثًا: إن ظهرت بادئة جديدة، أو اجتمعت البادئتان /24 في /23 واحدة، خرج الرقم 512 من «الحالي» إلى «لقطة تلك اللحظة».

رابعًا: إن عادت وثيقة rdap.org تُفتح، بقيت مشكلة الحساب بين 0.95 و0.82، لكن قول إنها لم تُفتح يسقط.

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