Кратко

  • Редакция 14 проекта NMOP разделяет сетевой цикл raisedupdatedcleared и операторский цикл acknowledgeddiagnosedresolved; один вызов разрешения может включать несколько инцидентов.
  • Успех приходит позже отдельным асинхронным уведомлением. Рецензия YANG Doctors указала, что уведомление невозможно связать с конкретным RPC, результатом которого оно является.
  • Квитанция от команды до cleared должна соединять запрос, полномочие, цели, исполнение, уведомление, тикет и проверку услуги. Это редакционное предложение, а не требование IETF.

Идентификатор объекта не является идентификатором причины

Проект NMOP объединяет сигналы разных слоёв — аварии, показатели и аномалии — в сетевые инциденты, с которыми можно работать через общие операции. Клиент подтверждает инцидент, запрашивает диагностику и пытается его разрешить.

В incident-resolve передаётся список incident-no. После успешного разрешения сервер формирует отдельное уведомление и переводит запись в cleared. Конкретный способ устранения проект не определяет.

Номер помогает понять, какая запись изменилась. Он не обозначает один вызов. Если два контроллера обращаются к одной записи, клиент повторяет запрос после тайм-аута, сервер сам восстанавливается или условие исчезает независимо, уведомление остаётся корректным, но его причинная принадлежность не установлена.

Для панели этого может быть достаточно. Для проверки полномочий, безопасного отката и разбора ответственности — нет.

Два жизненных цикла сохраняют важное различие

Сетевая сущность проходит состояния raised, updated, cleared. Работа оператора проходит подтверждение, диагностику и разрешение. Симптом может исчезнуть до конца расследования. Обходной путь может вернуть доступность, оставив вероятную первопричину. Оператор может завершить действие, пока мониторинг ещё видит влияние.

Операционные соображения добавляют третью шкалу — внешний тикет OSS. Проект предлагает детерминированно отображать состояния модели в Open, Assigned, In-Progress и Resolved, чтобы сеть и тикет не показывали противоположное закрытие.

Детерминированность устраняет случайное расхождение интерфейсов, но не создаёт причинную связь. Правило может безошибочно превратить cleared в Resolved и тем самым распространить уверенность, которой не было в исходной записи.

Рецензент указал на разрыв, а не на аварию

Ранняя рецензия YANG Doctors от 31 августа оценила документ как Almost Ready, но отдельно отметила: результаты RPC передаются уведомлениями, однако способ определить, какое уведомление относится к какому RPC, отсутствует. Тот же вопрос поставлен для диагностической операции.

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

Следовательно, это точный вывод о рассмотренном интерфейсе, а не доказательство сбоя у оператора, злонамеренного действия или дефекта будущей версии. Протокол NMOP на IETF 126 также фиксирует вопросы о ключе списка, номере и ID инцидента, но не заменяет итоговое решение.

Аутентификация отвечает за вход, корреляция — за последствие

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

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

Личность, разрешение, принятие запроса, исполнение, наблюдаемый статус и восстановление услуги — разные утверждения. Нельзя заставлять NACM доказывать всё сразу.

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

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

Пусть один вызов содержит номера 111, 112 и 113. Первый очищается после запрошенного действия, второй — после локального переключения, третий меняется при обновлении топологии. Позже все три перестают быть активными, но команда доказанно объясняет только один исход.

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

Устаревшая топология, по тексту, ухудшает установление вероятной причины и оценку влияния. Иногда меняется знание об инциденте, а не сеть под действием команды. Если эти пути слиты, автоматизация учится на ложной причинности.

Процесс стандартизации тоже имеет границы

Последнее рассмотрение рабочей группы завершилось 3 сентября. На зафиксированную дату 9 сентября Datatracker продолжал показывать In WG Last Call, без ответственного AD и даты IESG telechat. Редакция 14 — активный Internet-Draft, нацеленный на Standards Track, а не RFC и не окончательное решение IETF.

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

Квитанция без обязательной легенды об успехе

Квитанция от команды до cleared присваивает уникальный ID вызову. Она фиксирует целевые инциденты и их редакции, субъект и роль, версии NACM и политики изменений, предполагаемое воздействие, согласование и безопасную альтернативу.

Затем сохраняются принятие или ошибка по каждой цели, версия сервера и модели, повтор, разделение и резервный путь. Каждое уведомление связывается с вызовом, помечается как независимое изменение либо получает честный статус «корреляция неизвестна».

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

The Policy Mirror показывает разные места записи власти: NACM разрешает, RPC выражает намерение, хранилище наблюдает, тикет формулирует организационный вывод, проверка услуги сверяет его с реальностью. Running-Code Primacy требует соединить следы исполнения. Reality, Not Advocacy ограничивает вывод: проект даёт полезный словарь, но cleared не доказывает собственную причину.

Источники