Кратко

  • В draft-feng-netmod-naim-01 авторитетным источником является Canonical JSON; Markdown View производен для людей, а LLM Context View намеренно сокращён для модели.
  • Соответствие JSON Schema, успешный round trip, исправление после retry и прохождение YANG-валидатора подтверждают конкретные проверки. Они не доказывают по отдельности полноту требований, принятие NETMOD, реализацию сервером, авторизацию, применение конфигурации или итог для сети.

Представим сгенерированный модуль, который прошёл все синтаксические тесты. Он содержит when, листовой ключ и ссылку leafref. Но исходное требование не уточняло момент переключения, внешний модуль в целевой системе добавляет augment, а сервер объявляет deviation. Валидатор мог корректно ответить на поставленный ему вопрос и всё же не проверить тот контракт, который реально исполняется.

NAIM revision 01 предлагает Natural AI Interface Modeling как семантическое промежуточное представление между естественным языком и YANG. Авторы проблемы перечислены точно: прямое преобразование вынуждает угадывать различие конфигурации и состояния, ключи списков, выражения ограничений, операционные предусловия и связи между модулями.

Статус документа задаёт первый предел. Datatracker показывает активный индивидуальный Internet-Draft Chong Feng, обновлённый 18 июля 2026 года, без stream, без зарегистрированного intended RFC status, в состоянии I-D Exists. Заголовок самого проекта отдельно содержит Intended status: Standards Track. Это заявленное направление автора, а не принятие рабочей группой NETMOD, одобрение IETF или RFC. История фиксирует редакции, не внедрение.

Каноническая запись и два производных вида

Canonical JSON объявлен единственным нормативным источником содержания NAIM. Совместимые инструменты должны отдавать ему приоритет. Markdown View детерминированно строится для рецензирования и контроля версий. Если Markdown принимается как вход редактирования, представленные поля должны сохранять смысл при обратном преобразовании, поля только из JSON нельзя молча удалять, а конфликт должен решаться явно.

Следовательно, отчёт «round trip успешен» недостаточен. Нужны точные байты и hash JSON, версия схемы, идентичность конвертера, отпечатки результатов, перечень непредставленных полей и решения по конфликтам. Тест доказывает сохранность проверяемой проекции, но не истинность первоначального замысла.

LLM Context View создан для другой цели. Он включает имена, семантические типы, обязательность, ограничения, возможность записи, видимость, операции, предусловия и побочные эффекты. Ради экономии контекста исключаются детали построения NETCONF/RESTCONF, внутренние metadata, сырой JSON Schema, объявления deviation и определения extension. Этот вид не авторитетен и не должен восстанавливать Canonical JSON.

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

Разные функции Specification, Skill и Tool

Specification задаёт формат, схему и правила видов. Skill охватывает процессы ИИ: диалоговое моделирование, резюме, генерацию YANG и обратный анализ. Tool — обычное детерминированное ПО для проверки, преобразования, извлечения и генерации из подтверждённых данных. Стабильный формат и сменяемые Skills позволяют повторить работу без пожизненного доверия одной модели.

Validation-Reflection-Retry после ошибки выдаёт структурированный отчёт с путём и ожидаемым условием, добавляет его в контекст и повторяет генерацию. Число попыток ограничено; затем система должна остановиться, превратить остаток в адресные вопросы и сохранить историю.

Успешная новая попытка означает лишь прохождение повторённых правил. Модель могла удалить сложное необязательное поле, выбрать правдоподобный ключ или перенести неразрешённое условие в описание. В доказательство должны входить исходный запрос, вопросы, предположения, defaults, удаления, диагностика и версии Skill, Tool и schema.

RFC 7950 определяет семантику must, when, leafref, augment, features и ограничений экземпляров. При полном наборе модулей, deviations и положительных и отрицательных тестах валидатор даёт сильное локальное свидетельство. Он не решает, правильно ли фраза превратилась в XPath, есть ли augment на сервере и уполномочен ли пользователь. RFC 8407 даёт рекомендации по проектированию, а не свидетельство принятия.

YANG Library из RFC 8525 фиксирует заявление сервера о модулях, features и deviations. Его нужно связать с исходными байтами, трассой разрешения клиента и fingerprint эффективной схемы. RFC 8342 отделяет intended от operational state: принятая конфигурация ещё не равна применённой и успешной. RFC 8259 аналогично ограничивает смысл валидного JSON синтаксисом и обменом, не истинностью описания.

NAIM прямо не считает себя JSON-кодировкой или заменой YANG. Runtime-intent вынесен в отдельный NAIM-OP draft. Revision 01 не определяет модель, prompts, confidence score и сетевое исполнение.

Производственное утверждение должно связывать: запрос и неясности; точный Canonical JSON; оба вида, исключения и конфликты; YANG, полный closure и тесты; декларацию сервера, разрешение клиента и авторизацию; intended/operational наблюдения, телеметрию, rollback и результат.

Идея Lu Heng о минимальном детерминированном общем слое помогает оценить NAIM: общую валидность следует проверять локально, а принятие возникает через реализацию. Приоритет работающего кода и слои реальности отделяют документ от исполнимого эффекта. Это аналитическая рамка BTW, а не утверждение, что Lu Heng рецензировал NAIM.

Источники