Кратко

  • draft-ietf-netconf-error-registries-00 предлагает два реестра IANA для тегов и идентификаторов ошибок YANG; начальная редакция ещё неполна и не превращает имя в доказательство первопричины.
  • Автоматизация должна хранить сессию, операцию, заявителя, решение о доступе, целевой путь, идентификатор с модулем, структурированные подсказки, итог транзакции, исправление, контрольное чтение и результат сервиса.

Система получает invalid-value и запускает повтор.

Решение выглядит строгим: написание стандартизировано, условие легко внести в правило. Но в RESTCONF один и тот же тег может сопровождать HTTP 400, 404 или 406. При контроле доступа сервер вправе вернуть 404 вместе с invalid-value, чтобы не подтверждать существование защищённого ресурса. Ответ верен именно потому, что не раскрывает всю реальность.

Эту границу показывает draft-ietf-netconf-error-registries-00, опубликованный 30 сентября 2026 года. Активный документ рабочей группы NETCONF предлагает «YANG Protocol Error List» и реестр «YANG Protocol Error Identities». Авторам протоколов и реализаций больше не придётся собирать якобы канонический список по нескольким RFC.

Редакция 00 предназначена для Standards Track и истекает 3 апреля 2027 года. Это не RFC, не утверждённый реестр IANA, не свидетельство реализации или совместимости. Пять страниц открывают работу над управлением, а не завершают её.

Первый реестр должен содержать error-tag, допустимые error-type и error-severity, error-info, описание и ссылку. Второй — имя идентификатора, базовый идентификатор, дополнительную информацию и ссылку. Для обоих заявлена политика IETF Review.

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

Но редакция 00 также показывает требуемую точность. Описания первых трёх полей пока помечены TBD. Текст утверждает, что начальный набор взят из Appendix A RFC 6241, однако приводит лишь in-use, invalid-value, too-big, missing-attribute и bad-attribute. Далее в приложении есть access-denied, resource-denied, rollback-failed, data-missing, operation-not-supported, operation-failed, malformed-message и другие теги.

В списке идентификаторов тоже видна первая редактура. filter-unsupported, insufficient-resources и no-such-subscription повторяются. Часть идентификаторов из указанных RFC отсутствует: RFC 8639 содержит stream-unavailable, suspension-timeout, unsupportable-volume; RFC 8641 — cant-exclude, no-such-subscription-resync, on-change-unsupported, on-change-sync-unsupported, sync-too-big. Для процедуры указан RFC 5226, хотя действующая редакция BCP 26 — заменивший его RFC 8126.

Это не приговор будущему стандарту. Это наблюдение о revision 00. До машинной зависимости нужны уникальность, полнота, актуальные ссылки и ясная семантика полей. Частные таблицы, которыми клиенты молча заполняют пробелы, вернут ту же фрагментацию.

Даже безупречный реестр не станет протоколом расследования.

RFC 6241 допускает несколько элементов <rpc-error> в одном ответе NETCONF. Элемент может включать концептуальный слой, протокольный тег, серьёзность, прикладной тег модели или реализации, XPath целевого узла, сообщение и структурированные данные. Это отдельные измерения доказательства.

RFC 8640 показывает иерархию для подписок. filter-unsupported отображается в широкий тег invalid-value, insufficient-resources — в resource-denied, on-change-unsupported — в operation-not-supported, sync-too-big — в too-big, unchanging-selection — в operation-failed. Точная идентичность передаётся в error-app-tag с модулем, например ietf-subscribed-notifications:no-such-subscription.

Даже её нельзя читать вне операции. Допустимая базовая идентичность зависит от того, устанавливала, изменяла, удаляла, завершала или повторно синхронизировала подписку RPC. При установке и изменении error-info может подсказать параметры будущего успешного запроса. Удалив RPC, модуль и подсказки, система превращает структуру доказательств в одно слово.

unchanging-selection особенно хорошо показывает намеренное сжатие. RFC 8641 разрешает эту причину, когда выборка указывает на несуществующие данные или на данные без права чтения. Она применима и после изменения разрешений, из-за которого ранее видимые обновления исчезают. Исправить путь, получить доступ и перестроить фильтр после смены политики — разные действия. Протокол объединяет случаи ради абстракции и конфиденциальности.

no-such-subscription охраняет ту же границу. По RFC 8639 идентификатор может не существовать, принадлежать другому подписчику или указывать на настроенную подписку, к которой RPC неприменима. Вызывающая сторона получает безопасный итог: операция не может работать с этим идентификатором. Она не получает права исследовать внутренний реестр.

insufficient-resources сжимает другую неопределённость. Издатель не может создать подписку, но имя не говорит, чего не хватает: памяти, CPU, полосы, очереди, лимита реализации или квоты. Оно не называет владельца ограничения, срок и разумное время повтора.

Реестр — власть над именами, а не оракул событий.

Минимальная квитанция начинается до ошибки: протокол и сессия, RPC, request ID, аутентифицированный субъект и решение авторизации. Затем идут datastore и путь, общий тег, идентификатор с модулем и базой, error-info, версии сервера и модулей, исход транзакции. После вмешательства сохраняются разрешённое изменение, контрольное чтение и наблюдаемый результат сервиса.

Цепочка не даёт строить ложные равенства. 404 не доказывает отсутствия. Точный идентификатор не доказывает физической причины. Принятый повтор не доказывает изменения состояния. Подтверждённое изменение не доказывает восстановления услуги.

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

Разделение слоёв реальности поддерживает ту же дисциплину. operation-failed — символ. Отсутствующий узел, отозванное право, переполненная очередь и недопустимый параметр — разные реальности. Символ может намеренно скрывать различие. Если объявить его самой реальностью, получится вымышленная определённость.

Приоритет работающего кода требует последней квитанции после исправления. Повторный вызов не равен восстановлению, даже если API его принял. Успешная запись тоже недостаточна. Нужно перечитать состояние и увидеть требуемый результат сервиса. Только тогда действие становится операционным фактом.

Источники