Кратко

  • RFC 9984 определяет YANG-группировки для клиентов и серверов UDP, но не содержит доступных по протоколу узлов config false. Это модель настройки, а не перечень живых сокетов.
  • Имя узла ещё требует результата DNS, локальный порт 0 — выбора ОС, wildcard-адрес — подтверждения реального bind и listener.
  • Kent Watsen разделяет авторство с Alex Huang-Feng и Pierre Francois. Узкий общий слой остаётся полезным, если реализация отдельно доказывает инстанцирование, намерение, сокет, трафик и итог приложения.

Файл знал адрес, но процесс не знал интерфейса

Система управления приняла конфигурацию UDP-сервера. В ней был локальный адрес, которого ещё не существовало внутри сетевого namespace процесса. Валидация прошла, commit завершился, но bind() вернул ошибку.

Если отчёт читает только datastore, он покажет требуемый listener. Если он читает только таблицу сокетов, он покажет отсутствие. Это не спор источников: первый описывает намерение, второй — исполнение.

RFC 9984 проводит границу заранее. Документ, опубликованный в июне 2026 года как Standards Track, определяет ietf-udp-client и ietf-udp-server, но прямо говорит, что не создаёт доступных через протокол узлов config false. Он не берёт на себя наблюдение за runtime.

Повторно используемая схема ещё ничего не развернула

RFC 7950 определяет grouping как повторно используемый набор узлов схемы. Однако сама инструкция не является определением данных и не создаёт узлов в дереве. Конкретный модуль вызывает uses, после чего может применить refine и augment.

Отсюда следуют две разные проверки. Для артефакта нужны revision, namespace, запись IANA и хеш. Для инстанцирования нужны потребляющий модуль, место uses, активные features, refinements, augmentations и отпечаток итоговой схемы.

Реестр IANA перечисляет два имени модулей, файлы от 15 июня 2026 года, prefixes и namespaces. Он подтверждает идентичность общего компонента. Он не подтверждает загрузку на устройство, использование приложением или наличие процесса.

Метка «поддерживает RFC 9984» слишком широка для эксплуатационного вывода. Два приложения могут по-разному дополнить port semantics и всё равно корректно использовать одну группировку.

За именем скрыт выбор резолвера

В клиентской группировке remote-address обязателен, но допускает IPv4, IPv6 и hostname. Последний должен быть разрешён в адрес. На результат влияют view, cache, policy и время.

RFC 9984 рекомендует совместимость семейства разрешённого адреса с локальным, если локальный адрес указан. Полей для выбранного адреса, резолвера, момента и срока действия нет. Это позволяет разным приложениям выбирать одну из нескольких стратегий, не меняя общий блок.

Именно поэтому интерфейс не должен показывать настроенное имя как фактический peer tuple. После изменения DNS текущий ответ также не доказывает, какой адрес использовал уже созданный сокет.

remote-port не имеет default и не обязателен. Потребляющий модуль добавляет известный порт или делает поле обязательным в зависимости от протокола. Базовая группировка не всегда содержит полный адрес назначения.

Ноль и wildcard — это инструкции, а не наблюдения

При включённом local-binding локальный порт по умолчанию равен 0. RFC объясняет: ОС может выбрать любой свободный порт. Ноль делегирует решение и не появляется как реальный source port.

После перезапуска фактический порт может измениться, хотя конфигурация осталась прежней. Квитанция должна связывать настроенный ноль, эффективный порт, instance ID и время. Иначе после закрытия сокета восстановить историю нельзя.

Серверная группировка требует один или несколько local-bind, допускает IPv4, IPv6 и wildcard. Wildcard означает политику запроса к ОС, а не перечень интерфейсов. Container, namespace, набор адресов и dual-stack поведение завершают смысл.

Схема может быть валидна при занятом порте, отсутствующем адресе или недостаточных правах. Процесс может успешно связать сокет и тут же завершиться. Validation, commit, bind, удержание дескриптора и получение пакета — разные события.

Раздел безопасности RFC 9984 подчёркивает, что сами модули не открывают writable data, read-only state или RPC. Потребляющие модели отвечают за свои риски. Адреса и порты могут быть чувствительны, поэтому рабочий tuple требует ограниченного доступа и retention, а не безусловной публикации.

NMDA даёт разрыву точные названия

RFC 8342, среди пяти авторов которой есть Kent Watsen, различает настроенное значение и значение, реально используемое устройством. <intended> — преобразованная конфигурация, которую система пытается применить. Applied configuration — используемая часть. System state — временные данные runtime. <operational> объединяет applied configuration и system state.

Клиент может сравнить <intended> с config true частью <operational> и увидеть, какая часть намерения действует. Hardware, software, protocol interactions, нехватка ресурсов, transformations и задержка создают расхождения. При удалении connection, memory или file handle могут ещё оставлять remnant configuration.

RFC 9984 не заполняет эксплуатационные листья для UDP-сокета. Потребляющий модуль может их добавить, реализация может использовать отдельную telemetry. Свобода формата не даёт права назвать намерение исполнением.

Ценность коллективной работы — в точной границе

Открытый профиль IETF Datatracker, сохранённый 2 сентября 2026 года, описывает Kent Watsen как специалиста по управлению и безопасности сетей. Тогда он перечислял роли chair и reviewer и 21 RFC, включая 8040, 8342 и 9984. Это датированный снимок.

RFC 9984 подписали Alex Huang-Feng, Pierre Francois и Kent Watsen. Контактные блоки модулей называют Huang-Feng и Francois, acknowledgements — других рецензентов. Источники не делают Watsen единственным изобретателем, владельцем YANG или оператором конкретного продукта.

Для портрета важна другая линия: структурированный management access, архитектура datastore и повторно используемые endpoint-компоненты. Точная система управления должна не только описывать данные, но и признавать момент, когда право свидетельствовать переходит к ОС и приложению.

Running-Code Primacy Heng Lu требует проверять документ исполнением. Minimum Initial Specification объясняет, почему общий слой не обязан навязывать resolver policy, process supervision и application success всем будущим потребителям. Локальные решения допустимы, но их владельцы должны создавать проверяемые квитанции.

Шесть квитанций вместо одного зелёного статуса

Квитанция артефакта фиксирует revision, namespace, IANA reference и hash. Квитанция инстанцирования — consuming module, uses, features, refinements и augmentations.

Квитанция намерения сохраняет изменение, actor, transformations, время и снимок <intended>. Квитанция runtime сохраняет instance, resolution, эффективные tuples, bind result, открытие и закрытие.

Квитанция трафика сохраняет bounded window, пакеты, байты, первую и последнюю отметку, drops и errors. Квитанция приложения определяет peer identity, handshake, valid response или accepted transaction.

Тогда можно честно сказать: настроено, но не применено; связано, но без трафика; пакеты есть, а аутентификация не прошла; сервис доступен на одном адресе и отсутствует на другом. Общая модель остаётся компактной, а эксплуатация — доказуемой.

Источники