Кратко

  • Наблюдение 26 октября 2026 года: AS139620 анонсирует два префикса IPv4 на 512 адресов и один /48; видимость 269/269 и 257/257; замечено семь соседей — два слева и пять справа по пути.
  • В карточке в названии стоит PUBLIC COMPANY, в поле правовой формы — private_company, а оценка 0,95 держится на двух свидетельствах по 0,82, причём запись rdap.org на этот раз не открылась. Собственный текст в 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, это изменение, а не «ничего не произошло». Правильная позиция — читать форму анонса как форму, а не как мотив.

Семь соседей, две стороны и соблазн назвать их клиентами

Данные о смежности (RIPEstat соседи AS) распределяют семь замеченных соседей на две группы.

Слева двое: AS38082 — power 568, 1007 пиров IPv4, 0 пиров IPv6; AS4651 — power 1109, 1230 пиров IPv4, 499 пиров IPv6. Справа пятеро: AS139595 (power 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 (RIPEstat обзор AS) даёт ту же строку держателя, помещает номер в блок 139578-140601 с описанием Assigned by APNIC, под реестром 32-битных номеров автономных систем IANA, и сообщает announced true для окна 2026-10-26T08:00:00.

Заслуживает внимания путь, который не проходит. RDAP-объект самого APNIC (APNIC RDAP autnum) в этой проверке не вернул читаемой записи. Значит, дата выделения, состояние объекта и remarks — то, что обычно читают в RDAP, — здесь недоступны ни в одном поле. Кто спросит, в какой день номер был выделен, получит от этого текста ответ, что ответа нет; не вероятный год.

Два документа, одна оценка

Теперь сама карточка BTW. Она показывает 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 — вещь осязаемая в URL, в запросе и в таблице маршрутов, но карточка классифицирует ресурс как виртуальный. Что 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 подтверждение выделения, потребовать сверяемый регистрационный документ, попросить список контактов с SLA. Доказательство — это бумага с подписью, а не оценка, которую кто-то поставил.

Что опрокинуло бы этот вывод

Текст о границах доказательств должен назвать и собственные условия опровержения.

Первое: если RDAP-объект APNIC снова станет читаемым и даст дату выделения и состояние объекта, утверждение «даты выделения нет» сразу отпадает, и разговор о хронологии придётся переписать.

Второе: если справочник изменит legal_type на public_company или кто-то предъявит учредительный документ, напряжение между названием и полем снимается — в любую из двух сторон.

Третье: если появится новый префикс или два /24 снова сойдутся в /23, число 512 перестанет быть «текущим» и станет «снимком на ту дату».

Четвёртое: если документ на rdap.org снова откроется, арифметическая проблема между 0,95 и 0,82 останется, но утверждение «он не открывался» перестанет быть верным.

Пятое: если изменится набор соседей, описание левой и правой сторон придётся измерить заново. У измерения есть дата; у описания есть срок годности.