Кратко

  • draft-ietf-opsawg-veloce-yang-00 требует ссылаться на определённый тег или commit, а не на изменяемый HEAD. Это сильная квитанция идентичности контента, но merge, закрытая issue или зелёный CI сами по себе не становятся консенсусом рабочей группы.
  • После публикации остаются другие звенья: сохранённое решение, происхождение релиза, фактический module-set из YANG Library, представительные операции и наблюдаемый результат сервиса.

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

Зелёная проверка сообщает, что тест завершился успешно. Состояние Merged сообщает, что изменение вошло в ветку. Тег сообщает, какой объект получил устойчивое имя. Ни одна из этих отметок не говорит автоматически, что рабочая группа приняла техническое решение или что маршрутизатор исполняет этот код.

Именно эту границу делает видимой VELOCE. Проект draft-ietf-opsawg-veloce-yang-00 предлагает разделить сопровождающую прозу и модуль YANG. Описание модели, ссылки, действия IANA, вопросы безопасности и эксплуатации остаются в документе. Сам модуль разрабатывается в репозитории исходного кода с diff, issues, pull requests, проверкой и воспроизводимой контейнерной средой.

Подход соответствует природе YANG. Модуль читают люди, но его также обрабатывают парсеры, серверы и клиенты. Он имеет imports, revisions, features, deviations и иногда SID-файлы. Небольшое изменение удобнее анализировать как код, чем заново пропускать через длинный публикационный цикл всю прозу.

Зафиксированный материал — активный Internet-Draft рабочей группы OPSAWG от 25 августа 2026 года. В заголовке указано Intended status: Experimental, хотя сводное поле Datatracker не показывает предполагаемый RFC-статус. В истории есть только версия 00. Это не RFC, не завершённый эксперимент и не доказательство внедрения. Сроки в два года для нового модуля и один год для инкрементального -bis — критерии предлагаемого опыта, а не результат.

Ключевое правило запрещает вставлять модуль в документ. Документ должен ссылаться на конкретный тег или hash commit, а не на HEAD ветки. Тогда состояние модуля на момент публикации можно будет постоянно извлечь и проверить.

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

Но точность объекта не создаёт легитимность решения.

RFC 8874 прямо говорит, что работа в GitHub не имеет особого статуса. Рабочая группа может принять, отклонить или изменить результат. Копия документа в репозитории не обязана в каждый момент идеально отражать консенсус: редакторам нужна свобода ведения работы.

Интерфейс маскирует эту разницу. Pull request имеет бинарное состояние Merged. Issue — Closed. Проверка — Passed. Метка может называться has-consensus. Это записи действий пользователей с конкретными правами, а не самостоятельные источники полномочий.

RFC 8874 требует подтверждать решения о консенсусе через список рассылки и отдаёт итоговую оценку председателям. RFC 2418 поясняет, что rough consensus не равен голосованию большинства, а вывод встречи должен быть проверен в списке. Председатель учитывает разные площадки и смещения их аудитории.

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

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

CI выдаёт другую квитанцию. RFC 8874 упоминает сборку документов, проверку формальных языков и тесты. VELOCE рекомендует YANG-валидацию и контейнерную среду, чтобы участники могли повторить её локально.

Зелёный статус доказывает прохождение названных проверок на названных входах. Объём утверждения определяется commit, версией валидатора, импортами, features, конфигурацией, образом и набором тестов. Он не доказывает успешность ненаписанных тестов или одинаковое поведение разных продуктов.

Не нужно ослаблять автоматизацию; нужно сохранять её знаменатель. Манифест проверки должен фиксировать инструменты, версии, зависимости, параметры и исключения.

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

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

Контекст решения требует отдельного хранения. RFC 8874 отмечает: распределённые Git-объекты защищены лучше, чем обсуждения issues, pull requests, reviews и wiki. Сбой внешнего сервиса и компрометация привилегированных учётных данных тоже важны. RFC 8875 дополняет правила администрирования и резервирования.

Если код сохранился, а причина его принятия исчезла, остаётся результат без полного доказательства полномочий.

Первая runtime-квитанция приходит от сервера. RFC 8525 позволяет YANG Library сообщать module-sets для datastores, включая revisions, features и deviations. Оператор может сравнить это заявление с опубликованным тегом.

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

Принцип running-code расставляет уровни по местам. Тег относится к репозиторию, консенсус — к решению, RFC — к публикации, загруженная схема и поведение — к работающей системе. Ни один уровень не отменяет другой и не может говорить за него.

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

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

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

Источники