Кратко

  • draft-ietf-netmod-node-tags-11 описывал теги из определения модуля, от реализации и от пользователя, после чего точные значения из masked-tag удалялись из видимого operational-набора.
  • Оставшийся тег подтверждает лишь ответ конкретного сервера для данного селектора, datastore и контекста доступа. Он не подтверждает существование узла, свежесть данных, корректность реализации, принятие проекта или его эксплуатацию.

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

Так раскрывается главное ограничение YANG Data Model for Node Tags. Предложенный модуль ietf-node-tags содержит список связей с числовым id, node-selector типа nacm:node-instance-identifier, наборами tag и masked-tag. Селектор может указывать на узел схемы или экземпляр данных. Для обнаружения текст предлагает <get-data> в operational datastore и упоминает <get-schema> для узлов схемы. В приложении найденный путь затем используется в запросе establish-subscription.

Это иллюстрация возможной последовательности, а не отчёт о внедрении. Среди изученных источников нет свидетельств продукта, независимых реализаций, испытаний совместимости или промышленной эксплуатации.

Источники названы яснее, чем алгоритм

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

Но нумерованное построение operational view перечисляет только добавление system-origin тегов, назначенных при определении модуля, добавление пользовательских intended-origin тегов и удаление каждого значения, равного masked-tag. Отдельного шага для реализации нет.

Автоматические добавления реализации логично отнести к серверному или system-материалу. Это всё же интерпретация, соединяющая две части документа, а не явно записанный четвёртый шаг. Аудит не должен создавать более точную историю происхождения, чем исходный проект.

Маска тоже не переписывает прошлое. Она вычитает точную строку из видимого набора, но не доказывает, что тег никогда не существовал или был ошибочным. Сохранившийся vendor:critical, в свою очередь, не сообщает автора, дату, сборку ПО или наблюдение, на котором основана классификация.

Префиксы ietf:, vendor: и user: координируют пространства имён. Проект допускает и незарегистрированный префикс, рекомендуя обрабатывать такой тег. Регистрация подтверждает распределение имени, но не истинность утверждения после двоеточия.

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

Тип node-selector делает путь структурированным, но не самодостаточным. RFC 7950 определяет YANG. RFC 8525 описывает в YANG Library модули, редакции, features и deviations, образующие действующую схему. При изменении этого набора или mount-контекста та же строка может перестать разрешаться или указать на другую цель.

RFC 8342 отделяет intended от operational. Проект использует различие для пользовательской конфигурации и составного результата. Однако operational здесь означает представление datastore, сформированное сервером, а не непосредственную аппаратную или пакетную реальность.

RFC 8341 добавляет фильтр полномочий: NACM может скрыть связь или целевой узел. RFC 6241 и RFC 8040 дают транзакции NETCONF и RESTCONF, но успешный ответ показывает лишь то, что сервер отдал этой идентичности. Отсутствие по-прежнему совместимо с несколькими причинами.

RFC 7952 предлагает полезное сравнение. Metadata annotations сопровождают экземпляры данных, тогда как node-tags централизует связи вокруг селекторов. Ни один формат автоматически не создаёт авторство, время, цепочку хранения или свежесть.

Доказательства должны накапливаться по ступеням

Файл проекта доказывает, что редакция 11 была предложена. Datatracker доказывает её документальный жизненный цикл. Зарегистрированный префикс доказывает распределение пространства имён. Ответ с тегом доказывает, что сервер показал итог композиции в конкретном контексте доступа и datastore.

Разрешение селектора по зафиксированному снимку YANG Library связывает путь с узлом в этой схеме. Авторизованное чтение доказывает ответ сервера в этой операции. Для свежести, полноты, верной реализации, доставки уведомлений, состояния FIB, прохождения пакетов и результата услуги нужны другие наблюдения.

RFC 8639 и RFC 8641 поддерживают subscriptions и YANG-Push. RFC 9195 и RFC 9196 описывают экземпляры данных и возможности. Они не превращают классификацию в доказательство полной доставки или правильного исполнения. Идентификаторы поставщика в RFC 9371 также улучшают порядок имён, но не сертифицируют поведение продукта.

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

Соседний RFC не передаёт свой статус

Редакция 11 датирована 21 октября 2023 года и должна была истечь 23 апреля 2024 года. Datatracker отмечает её как Expired Internet-Draft, Expired & archived и Dead WG Document; состояние IESG — Expired. Предполагался Proposed Standard, но RFC не появился.

Проверка YANG показывает ноль ошибок и ноль предупреждений. Это свидетельство прохождения указанных инструментальных проверок, а не принятия, совместимости, внедрения или правильной operational-композиции.

RFC 8819 — ближайший опубликованный Standards Track документ о тегах целых модулей YANG. Он различает вклад определения, реализации, пользователя и масок. Node-tags пытался перенести схему на узлы. Статус RFC 8819 не наследуется истёкшим проектом.

Тексты Heng Lu о минимальной спецификации, власти, силе реализации, слоях реальности и running code используются лишь как редакционная оптика. Они помогают отделить символы координации от наблюдаемого исполнения и не создают требований IETF. Практический вывод — оставить тег подсказкой для поиска и не позволять ему заимствовать авторитет документа, реестра или сервера.

Источники

Основная запись: редакция 11, текущий статус Datatracker и история.

Модель и доступ: RFC 6241, RFC 7950, RFC 7952, RFC 8040, RFC 8341, RFC 8342, RFC 8407, RFC 8525 и RFC 8526.

Теги, подписки и соседние модели: RFC 8639, RFC 8641, RFC 8819, RFC 9195, RFC 9196 и RFC 9371.

Аналитическая оптика: Minimum Initial Specification, On Authority, Implementation Power, Reality Layers и Running Code Primary.