Кратко

  • RFC 9899 разрешает менять defined set без переопределения родительской ACL; неизменное правило не фиксирует фактический набор совпадений.
  • Воспроизводимая история связывает авторизованное изменение, полное разрешение ссылок, intended/operational каждого устройства, attachment, счётчики и независимый результат.

Во время отката команда восстановила прежний файл ACL. Проверка показала нулевой diff, и операцию закрыли. Но общий prefix set остался в новой версии. Формально правило вернулось; семантически — нет.

RFC 8519 задаёт основу: ACL — упорядоченный список ACE, где условия сопоставления соединены с действиями accept, drop, reject, count или police. Фильтрация начинается после применения ACL к attachment point.

RFC 9899 добавляет именованные наборы IPv4/IPv6-префиксов, портов, протоколов и типов ICMP, а также aliases для комбинаций параметров. Он расширяет модель payload-, MPLS-, VLAN-, I-SID-, fragment- и TCP-flags-сопоставлением и rate-limit.

Ключевая особенность — раздельное управление. Члены списка можно добавлять или удалять, не переопределяя родительское правило. ACL и наборы могут жить на уровне административного домена и связываться со многими устройствами. Маленькое изменение объекта становится большим изменением всех его потребителей.

Поэтому история должна хранить не имя, а разрешённый граф: родительскую ACL, порядок ACE, все транзитивные члены наборов и aliases, ревизии модулей, capabilities, устройства и точки применения. Иначе одинаковый идентификатор описывает разные политики.

Время распространения входит в смысл. Если набор изменён в 10:05, контроллер подтвердил запрос в 10:07, первое устройство применило его в 10:08, второе в 10:13, то пакет в 10:10 встречает две политики. Родительская ACE при этом одинакова.

RFC 8342 разделяет <running>, <intended> и <operational>. Intended — преобразованная конфигурация, которую система пытается применить. Сравнение с конфигурационной частью operational показывает, что реально используется. Возможны inactive, remnant, задержка и неуспешное применение.

Desired state контроллера — свидетель намерения, но не состояния устройства. Templates, defaults, features и augmentations меняют разрешение. Нужен readback по каждому target и времени.

Ответ управления тоже ограничен. В RFC 6241 NETCONF <ok> означает обработку RPC без ошибок и предупреждений и без возвращаемых данных. RFC 8040 использует 201 или 204 для создания или изменения RESTCONF-ресурса. Это доказательство транзакции, не совпадения будущего пакета и не результата сервиса.

RFC 8341 определяет NACM-права read, write и execute. RFC 9899 защищает чувствительные наборы через nacm:default-deny-write, поскольку несанкционированное изменение может ошибочно разрешить или запретить трафик. Право записать конфигурацию не является исполнением ACL.

Счётчики RFC 8519 дают runtime-сигнал: matched-packets и matched-octets по ACE и иногда интерфейсу. Рост означает, что устройство отнесло трафик к ACE. Но без scope, reset epoch, часов, attachment и разрешённого набора число не восстанавливает событие и не доказывает личность или end-to-end результат.

Ноль также неоднозначен: отсутствие match, неподдерживаемая функция, reset, пропущенное окно, неверное устройство, отсутствие attachment или старая версия. Отрицательный вывод требует описания границ наблюдения.

Для payload matching RFC 9899 задаёт offset, длину, бинарный pattern и operator. На незашифрованных данных фильтрация может быть детерминированной; при шифровании она зависит от неизменного видимого шаблона. Возможность описать условие не создаёт наблюдаемых байтов.

RFC 7950 делает YANG 1.1 строгим языком configuration, state, RPC и notifications. Валидность схемы подтверждает представление. Применение, match и эффект требуют отдельных доказательств.

Надёжная цепочка хранит аутентифицированного actor, session, NACM decision, request, datastore и response; затем ACL, ACE, членов, ревизии, capabilities, targets, attachments и intended/operational. Далее идут счётчики с reset-историей, logs и при необходимости packet/flow. Приложение фиксирует собственный результат.

Last-known-good должен включать ссылки и их содержимое. Возврат только родителя не откатывает политику. Возврат объекта в контроллере без operational-проверки каждого устройства не завершает восстановление.

Running-Code Primacy Heng Lu ограничивает свидетелей: менеджер доказывает транзакцию, устройство — состояние и counters, sensor — трафик, application — результат. Reality Layers не позволяют стабильному имени заменить изменяемый объект. Data Sovereignty отделяет технический контроль от общей власти. Minimum Initial Specification сохраняет общий слой тонким, а rollout и rollback — локально проверяемыми.

Руководству нужен ответ не на вопрос «вернули ли правило», а на вопрос: какую полностью разрешённую политику выполняло устройство, что оно зафиксировало и какой независимый журнал подтверждает следующий результат?

Sources