Кратко

  • draft-ietf-netmod-yang-xml-00 выносит XML-кодирование YANG-данных из спецификации языка: имена и namespaces, порядок списков, значения типов, metadata и ссылки.
  • Well-formed XML, schema validation и равные canonical bytes подтверждают лишь слой представления. Эффективное дерево, defaults, приём RPC, изменение datastore и внешний результат — другие утверждения.

Система сравнения получает две резервные копии. Первая использует default namespace, вторая — локальный prefix. После canonicalization исчезают различия пробелов и порядка атрибутов, хэши совпадают. Но первый сервер скрыл default leaf в режиме trim, а во втором такое же значение было записано клиентом. Сегодня экран одинаков; после смены default история решений окажется разной.

Ревизия 00 XML Encoding of Data Modeled with YANG датирована 8 июня 2026 года. Она переносит нормативные правила XML из RFC 7950 и охватывает configuration, state, параметры RPC/action и notifications. Это Internet-Draft Standards Track со сроком до 10 декабря 2026 года; разделы IANA и Security Considerations всё ещё содержат FIXME. Документ нельзя выдавать за готовый RFC или доказательство реализации.

Prefix локален, namespace определяет имя

Экземпляр узла YANG кодируется XML-элементом. Local name равен идентификатору узла, namespace задаёт определивший его module. Верхний элемент объявляет namespace; ребёнок из другого augmenting module должен переключиться на его пространство имён.

Разные prefixes могут связываться с одним URI. Текстовый diff создаёт ложное различие. Но переписывание prefixes без сохранения bindings способно создать ложное равенство.

Значение identityref — имя, квалифицированное namespace; одна identity допускает разные локальные prefixes. В instance-identifier каждое имя узла имеет явный prefix, однако он тоже локален для экземпляра. Для разрешения нужен правильный schema. Успешное разрешение строки не доказывает существование цели в нужном datastore.

Порядок зависит от типа узла

Дети обычного container могут идти в любом порядке. Input/output RPC или action следуют порядку schema. Keys списка идут первыми. Элементы ordered-by user сохраняют порядок пользователя, system-ordered получают порядок от реализации.

Сортировка всех siblings перед сравнением убирает шум, но может стереть приоритет или first-match policy. Учет любого перемещения как изменения создаёт противоположную ошибку. Нужны YANG path, правило ordered-by, исходная последовательность и server readback.

Отсутствующий default может действовать

Ревизия 00 не задаёт режимы NETCONF для defaults. RFC 7950 определяет, когда default находится in use, и требует поведения как при существующем узле; when или if-feature могут это отменить. RFC 6243 задаёт report-all, trim, explicit и report-all-tagged.

Отсутствие leaf в XML не означает его семантического отсутствия. Явное значение, равное default, не говорит, кто его создал и хранится ли оно. Перед diff следует назвать view: wire bytes, stored configuration, accessible tree с действующими defaults или конкретный ответ with-defaults.

Canonical XML не канонизирует YANG-смысл

Canonical XML 1.1 стабилизирует кодировку символов, порядок атрибутов и declarations namespaces. W3C прямо указывает: общая XML-процедура не охватывает правила эквивалентности приложения. Разные canonical forms могут быть равны для приложения; одинаковые формы не приобретают внешние правила автоматически.

YANG добавляет revision, features, deviations, lexical и canonical forms типов, defaults, order, constraints и resolution ссылок. C14N не выбирает modules, не разворачивает defaults и не проверяет leafref.

YANG Library из RFC 8525 сообщает schema-set сервера, но сообщение надо связать с действительно загруженными байтами. RFC 8528 разрешает разные mounted schemas у разных экземпляров одного mount point. Вырванный XML fragment теряет этот контекст.

Metadata RFC 7952 передаются XML-атрибутами. Посредник может удалить неизвестные attributes, оставить обычные данные валидными и потерять важную аннотацию происхождения. Для schema-less anydata и anyxml также нельзя обещать общий обратимый переход XML–JSON–XML.

За протоколом остаётся работа устройства

Валидный файл не доказывает получение NETCONF RPC. RFC 6241 разделяет <rpc-reply>, <rpc-error> и <ok>. <ok> означает обработку без error или warning и без возвращаемых данных, а не любой последующий физический эффект.

Запись изменения связывает request, message-id, аутентифицированную session, capabilities, YANG Library, reply и datastore before/after. RFC 8342 различает running, intended и operational, поскольку валидная конфигурация, преобразованное намерение и применённое состояние расходятся. Внешний эффект требует независимого измерения.

Стандарт определяет ожидаемый смысл. Running code показывает наблюдаемое последствие. Ни один из этих источников не заменяет другой.

Источники