Кратко

  • draft-ietf-netconf-yp-transport-capabilities-07 позволяет узнать поддерживаемые транспорты, форматы кодирования и протоколы защиты для уведомлений YANG из данных времени реализации или от работающего сервера.
  • Такая запись — меню возможностей. Она не выбирает точный набор, не даёт локального разрешения, не настраивает получателя, не принимает establish-subscription и не доказывает доставку.
  • Предварительные сведения и чтение во время работы отличаются происхождением и свежестью. Автоматизация не должна сжимать их в один признак «поддерживается».
  • Квитанция решения от возможности до подписки должна связать наблюдение, выбор, политику, получателя, запрос, исход и резервный путь. Это редакционное предложение, а не требование IETF.

Строка правдива, а зелёный статус вводит в заблуждение

Редакция 07 документа YANG Notification Transport Capabilities решает разумную задачу. До запроса уведомлений система управления может узнать механизмы, объявленные сервером. Модель добавляет запись для каждого транспорта, а внутри неё — списки форматов кодирования и протоколов безопасности.

В примере HTTPS сопровождается XML и JSON, TLS 1.2 и TLS 1.3. Для UDP-notif указаны JSON и CBOR, DTLS 1.2 и DTLS 1.3. Оркестратору не приходится предлагать вариант, о котором устройство ничего не заявляло.

Ошибка начинается, если интерфейс превращает дерево в зелёную отметку «уведомления доступны». В ней смешиваются обнаруженная возможность, выбранная комбинация, одобрение политики, принятие издателем и доставка получателю. У каждого состояния свой владелец, время и доказательство.

Редакция 07 опубликована 17 августа 2026 года. Datatracker обновлялся 8 сентября; на тот же день приходился срок комментариев последнего призыва IETF, объявленного 25 августа. На момент исследования 9 сентября документ оставался активным Internet-Draft с предполагаемым статусом Proposed Standard, переданным в IESG и ожидающим действия директора области. Окончание срока не делает его RFC и не означает окончательного одобрения.

У слова «поддерживает» два источника времени

Базовый RFC 9196 предусматривает два способа сообщать возможности. Разработчик может заранее опубликовать файл YANG instance data, не зависящий от живого узла. Работающий сервер может выдать сведения по NETCONF или RESTCONF.

Информация времени реализации нужна разработчикам NMS, интеграторам и покупателям. Она описывает продуктовый тип или реализацию. Данные времени работы нужны модельным приложениям и могут учитывать лицензию, аппаратные ограничения и эксплуатационные изменения. RFC 9196 прямо называет живое чтение способом проверить, реализовал ли издатель то, что было заявлено раньше.

Поэтому две честные записи способны различаться. Продуктовый файл не обязательно знает установленную плату. Ответ, верный в десять часов, может устареть через пять минут. Если возможности меняются в ходе работы, RFC рекомендует on-change-уведомления для контейнера. Потребитель всё равно должен принять изменение и связать его с уже сделанным выбором.

Журнал автоматизации должен хранить тип и адрес источника, способ получения, редакцию модуля, устройство и сборку, момент наблюдения и правило устаревания. Без этих координат слово «поддерживает» может быть верным, но недостаточным для машинного полномочия.

Множество кандидатов не является протоколом выбора

Список transport-capability использует транспортный протокол как ключ. В каждой записи находятся отдельные leaf-list для security-protocol и encoding-format. Это удобное представление области поиска, но не след состоявшейся комбинации.

Нельзя и приписывать проекту непоказанный дефект. Раздельные списки сами по себе не доказывают, что сервер ошибочно обещает работу любого декартова сочетания. Надёжный вывод уже: наличие транспорта, кодирования и защиты в соответствующих множествах не подтверждает, что выбранная тройка доступна на данном экземпляре сейчас. Её нужно назвать, испытать и записать исход.

RFC 8639 проводит следующую границу. Динамическая подписка не существует у издателя только потому, что подписчик отправил запрос. Она возникает после принятия establish-subscription. Издатель может отказать по разным причинам и вернуть структурированные подсказки для более вероятного успеха новой попытки.

Принятие также не доказывает устойчивую доставку. Оно фиксирует создание состояния у издателя. Получатель может быть недоступен, поток может остановиться, а первое уведомление — не прийти. Рабочая панель должна различать «обнаружено», «выбрано», «разрешено политикой», «принято» и «доставляется».

Настроенный вход управления не создаёт выход уведомлений

Проект предполагает доступную сеть управления между оркестратором и устройством. Управленческая связь и конечная точка устройства уже должны быть настроены. Поэтому дерево можно прочитать.

Предпосылка не настраивает получателя уведомлений и не разрешает любой идентичности, прошедшей взаимную аутентификацию NETCONF или RESTCONF, создавать поток к любому адресу. Аутентификация отвечает, кто находится у интерфейса. NACM и локальная политика определяют разрешённые действия. Профиль безопасности, платформа приёма и маршрут могут принадлежать разным командам.

В распределённой организации каждая сторона легко считает, что решающую часть одобрила другая. Сетевой оператор видит возможность, служба безопасности ожидает выбора только предпочтительного протокола, платформа думает, что устройство проверило адрес. Без общего следа эти разумные предположения образуют действие без ответственного.

Новые узлы модели описаны как доступные только для чтения и не содержащие чувствительных сведений. Проект ожидает защищённые взаимно аутентифицированные NETCONF или RESTCONF и контроль NACM. Не нужно превращать меню в секрет. Риск иной: даже несекретный факт может стать несанкционированной командой. Прочитать поддержку TLS 1.2 не значит разрешить её для конкретного получателя.

Процессные свидетельства не доказывают службу

На 8 сентября Datatracker показывал ноль ошибок и ноль предупреждений проверки YANG. Текущая проверка безопасности имела оценку «Ready», транспортная — «Almost ready»; IANA требовала действий, экспертные проверки были согласованы. Это точные признаки процесса, не показатели эксплуатации.

Раздел реализации говорит, что Huawei применила документ для издателя YANG-Push в VRP, а Cisco — в IOS XR. Тот же раздел должен быть удалён RFC Editor перед публикацией. Заявления показывают наличие кода, но не публичную матрицу совместимости редакции 07, долю развёртываний, сертификацию или успешность всех троек.

Идентификатор dtls12 показывает ещё одну границу. Его описание называет DTLS 1.2 устаревшим и не рекомендует включать. Отсюда не следует запрет TLS 1.2, присутствующего в примере HTTPS. Политика обязана различать идентичность протокола и применимый стандарт, а не реагировать на строку «1.2».

Квитанция связывает возможность с последствием

Предлагаемая квитанция решения от возможности до подписки может жить в операционной системе и не менять YANG. Она начинает с устройства, семейства продукта, редакции модуля и сборки. Затем указывает, была ли это предварительная instance-data или живая выдача NETCONF/RESTCONF, где и когда её получили и когда она считается устаревшей.

Квитанция сохраняет объявленную транспортную запись и действительно выбранную тройку: транспорт, кодирование, безопасность. К ней добавляются действующая идентичность, получатель и endpoint, версия политики, параметры и время запроса. Исходы разделяются на принятие, отказ, тайм-аут, позднее прекращение и принятие без первой доставки.

Структурированные подсказки, повторная попытка, запасной вариант и тот, кто разрешил более слабый выбор, остаются рядом. Иначе автоматизация способна повысить успешность незаметным откатом и назвать его совместимостью.

The Policy Mirror предлагает найти поле, которое управляет результатом: дерево пишет возможность, политика — разрешение, издатель — существование, получатель — полезность. Running-Code Primacy требует соединить эти следы выполнения. Reality, Not Advocacy сохраняет меру: проект предлагает лучшее меню, но не обещает автоматическую доставку. Оператор отвечает за выбранный пункт.

Источники