Кратко

  • RFC 6643 преобразует модули SMIv2 в YANG для чтения через NETCONF. Исходное объявление возможности записи не превращает полученный узел в конфигурационный автоматически.
  • В SNMP сохранность значения может определяться описанием объекта или свойствами строки. В NETCONF существенны свойства хранилища конфигурации; одинаковое значение не доказывает одинакового обязательства по его сохранению.
  • Документированные отклонения позволяют сделать конфигурационными отдельные узлы с совместимой семантикой. Это не означает, что все управляющие операции перенесены и прежнюю систему можно отключить.

Остаточная зависимость бывает почти незаметной

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

Это условная ситуация приемки, а не описание конкретного внедрения. В ней нет обязательного противоречия: перенос чтения действительно мог завершиться, тогда как перенос управления остался частичным. Ошибка возникает, если первая часть автоматически считается доказательством второй и на этом основании снимается поддержка старого пути.

Именно такую возможность различения сохраняет RFC 6643, опубликованный в июле 2012 года. Документ определяет автоматическое преобразование модулей MIB на SMIv2 в YANG с целью доступа только для чтения через NETCONF. Он не обещает универсального перевода всех прежних операций записи в новый конфигурационный интерфейс.

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

Старое описание доступа не командует новой схемой

В SMIv2 свойство MAX-ACCESS описывает характер доступа к объекту. Исходная декларация может содержать read-write или read-create. При преобразовании эта информация сохраняется в расширении smiv2:max-access.

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

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

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

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

Сохранность определяется не именем поля

Раздел 11 RFC 6643 объясняет основное препятствие автоматическому созданию конфигурационных узлов. В SNMP устойчивость значения может задаваться описанием самого объекта, свойствами концептуальной строки или колонкой с текстовым соглашением StorageType. В NETCONF соответствующие свойства связаны с хранилищем конфигурации.

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

Определение StorageType в RFC 2579 показывает, насколько существенны детали. Изменчивая, не сохраняемая при перезапуске строка типа volatile теряется после перезагрузки. Ряд других типов опирается на устойчивое хранение, но их правила изменения неодинаковы. Строку permanent можно менять, однако нельзя удалять; строку readOnly нельзя ни менять, ни удалять.

Дополнительные ограничения действуют и на запись в объект, который представляет сам тип хранения. Поэтому постоянство строки не следует понимать как неизменность каждой ее колонки. Устойчивое хранение также не является разрешением конкретному пользователю менять содержимое. Это разные свойства, даже если интерфейс показывает их рядом.

В RFC 6241 базовая модель NETCONF включает текущую конфигурацию, running. Дополнительные хранилища зависят от возможностей, которые объявляет устройство. Прямая запись в running тоже имеет соответствующую возможность, а не следует из одного наличия протокола.

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

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

Есть и более ранняя граница. Операции редактирования и копирования конфигурации из RFC 6241 не являются универсальным способом произвольного изменения оперативного состояния. Не всякое читаемое значение следует воспроизводить как настройку. Прежде чем переносить запись, надо выяснить, какое действие эта запись вообще представляет.

Конфигурируемое исключение должно быть объяснимым

RFC 6643 оставляет возможность реализовать некоторые полученные узлы как конфигурационные, если семантика сохранения согласована между двумя системами. Такое отличие от результата только для чтения рекомендуется формально описывать отдельным модулем отклонений YANG.

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

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

Это замечание нельзя смешивать с обычным наследованием config, когда свойство не указано. Более поздний RFC 7950, спецификация YANG 1.1, описывает такое наследование, запрещает конфигурационные узлы под узлом состояния и требует, чтобы после применения объявленных отклонений модель оставалась допустимой. Для понимания возможностей нужна действующая схема целиком, а не отдельная строка базового файла.

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

Само описание отклонения при этом не заменяет доказательств работы и не выдает полномочий пользователю. Оно делает заявленную особенность реализации обозримой. Ее можно связать с версией, проверить в нужном контексте и передать следующему владельцу системы вместе с объяснением.

Повторная генерация проверяет качество передачи знаний

RFC 6643 советует вносить необходимые изменения в исходный SMIv2, обновлять сведения о ревизии и повторять преобразование, а не редактировать сгенерированный YANG напрямую. Отдельные расширения и отклонения при этом остаются допустимыми.

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

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

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

Из него следует необходимость проверить соответствующий случай генерации. Не следует вывод о завершенной миграции управления. Аналогично, карточка RFC 6643 у RFC Editor позволяет установить контекст публикации, но не подтверждает поведение определенного устройства или продуктовой версии.

Два пути могут быть нормальным конечным состоянием

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

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

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

Есть и отдельная граница раскрытия информации. RFC 6643 отсылает к чувствительности объектов исходных MIB и к контролю доступа NETCONF. Невозможность менять данные через преобразованную модель не означает, что эти данные допустимо показывать всем. Безопасность чтения не тождественна запрету записи.

На чем основана интерпретация

Статья использует различие Lu Heng между символическим представлением и исполнимой силой и его анализ контроля, отделенного от последствий. Применение этой оптики к переносу управления является выводом Daniel Kade, а не приписываемой Lu Heng оценкой SNMP или YANG.

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