Кратко

  • OPSAWG приняла VELOCE и 25 августа 2026 года опубликовала версию 00 как документ Рабочей группы. Это ещё не RFC, не BCP и не окончательное правило IETF.
  • Приписываемое участникам резюме встречи говорит, что указатель IANA подтверждён; версия 00 прямо утверждает, что действий IANA нет. Pull request 49 с состояниями, хешами и путями утверждения к концу исследования оставался открытым и неслитым.
  • Итог проектной встречи не заменяет консенсус Рабочей группы, подтверждённый в списке рассылки. Слияние в GitHub не заменяет утверждение группы, Area Director или IESG. Строка IANA способна зафиксировать утверждённую версию, но не вправе сама решать её нормативный смысл.
  • Проект уже исключает ссылку на изменчивую вершину ветки: RFC должен вести к конкретной помеченной версии. Осталось связать утверждение последующей версии, получение и проверку IANA и версию, по которой реализация заявляет соответствие.

Принятие документа не означает принятия каждого будущего механизма

В итоге призыва к принятию председатели OPSAWG зафиксировали достаточную поддержку и попросили переиздать индивидуальный текст как draft-ietf-opsawg-veloce-yang-00 без иных изменений. Datatracker показывает версию 00 как документ группы, одобренный 25 августа. Это передаёт текст в ведение группы. Но такой шаг не утверждает заранее каждую будущую деталь о реестре, получении файла или сопровождении.

Идея VELOCE состоит в том, чтобы не помещать модуль YANG в RFC. RFC ссылался бы на конкретную отмеченную версию репозитория. Главная ветка может измениться уже после публикации; именованный commit или tag позволяет будущему читателю получить и проверить именно те байты, на которые ссылалась публикация. Проект также допускает обновление принятого модуля в репозитории IETF с изменением в RFC лишь ссылки на новую версию. Это отвечает реальной проблеме стоимости сопровождения: ограниченная, тщательно проверенная правка не обязана всякий раз влечь полную замену RFC.

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

Авторы задали эти вопросы публично ещё до IETF 126. В обсуждении указателя спрашивается, должен ли RFC вести к Git tag, записи IANA или иному объекту; что должен означать указатель на последнюю версию; какую версию должны брать разработчики; и как сохранять проверяемость соответствия после обновления. Протокол OPSAWG на IETF 126 оставляет разные взгляды на GitHub, среду под контролем IETF, публикацию IANA, архивирование и восстановление. Отведённое время закончилось, и обсуждение продолжилось в списке. Это доказательство открытого вопроса проектирования, а не обвинение участникам.

Резюме от 25 августа добавляет, что для эксперимента сохраняется GitHub-репозиторий, участники могут открывать issues и pull requests, мнения двухнедельных встреч будут сводиться в списке, а возражения до слияния потребуют дальнейшего обсуждения. Оно же говорит о подтверждении модели с IANA. Но нельзя утратить масштаб этого источника. Это приписываемый участникам отчёт о проектной встрече, а не формальный призыв к консенсусу Рабочей группы и не решение IESG. RFC 8874 говорит, что работа в GitHub не имеет особого статуса и что решения консенсуса группы должны подтверждаться в списке рассылки. Встреча может подготовить выбор, но не подменяет подтверждение.

В самой версии 00 сказано, что действий IANA нет. RFC 8126 рассматривает явный раздел без действий как сознательное установление того, что IANA не должна ничего делать для данного текста. Это не запрещает следующей версии добавить действительное поручение. Но это не позволяет описывать направление, обсуждённое на встрече, как уже готовую регистрационную инструкцию.

PR49 — проект следа, а не уже действующий реестр

На дату отсечения pull request 49 была открыта и не слита. Она предлагает реестр ссылок на файлы и модули YANG с постоянным и предлагаемым состояниями, точным URL, SHA-256, контролирующими контактами и путями утверждения через IESG либо другого указанного участника. Эти поля разумно разделяют роли: хеш фиксирует байты, состояние отличает кандидата от текущей ссылки, контакт показывает ответственность за сопровождение, путь утверждения называет того, кто принимает содержательное решение.

Но предлагаемые поля ещё не являются общедоступной политикой реестра. Текущий реестр IANA YANG Module Names действует по правилу RFC Required и содержит имя, файл, пространство имён, префикс, ссылку и примечания. В нём сейчас нет предлагаемых VELOCE полей для хеша, состояния утверждения, контролирующего контакта или документа решения. Поэтому зафиксированные источники не позволяют сказать, что IANA уже создала этот реестр, приняла его правило или получила версию VELOCE.

У действий разные субъекты. Автор предлагает изменение. Рецензенты и хранители репозитория обрабатывают его в репозитории. Рабочая группа формирует консенсус. Area Director или IESG могут выполнить предписанную текстом роль утверждения. IANA осуществляет ограниченную регистрацию. Получившаяся строка сохраняет идентичность версии. Tag, merge, консенсус, утверждение и запись могут быть связаны, но ни одно из них автоматически не доказывает остальные.

Такое различение защищает, а не тормозит эксперимент. Версия 00 уже требует фиксированную помеченную версию и сохраняет процедуры консенсуса. PR49 пытается связать IANA хешами и именованными путями утверждения, а не дать ей неограниченное усмотрение. Ранняя WG-версия вполне может не успеть за ещё не разрешённой детальной дискуссией. Ошибкой было бы выдать временный разрыв за неявно полученную власть — или считать его доказательством нелегитимности самого опыта.

Короткий документ от решения к указателю

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

  1. заявленный нормативный эффект и ответственную Рабочую группу;
  2. призыв к консенсусу в списке, даты открытия и закрытия, существенные возражения и решение председателей;
  3. точный проект или акт утверждения, требующий регистрации, и утверждающего участника;
  4. URL репозитория, неизменяемый commit, tag и SHA-256;
  5. автора, рецензентов, выполнившего merge и носителя полномочия на утверждение как отдельные роли;
  6. заявителя IANA, время запроса, полученный URL и байты, результат проверки;
  7. прежнюю и новую строки реестра, момент действия и связь замещения;
  8. версию публикации, последнюю утверждённую и тестируемую версию соответствия;
  9. совместимость, тесты, зеркала, резервные копии, восстановление, отзыв и возврат; и
  10. отдельно — доказательства реализации и эксплуатационного принятия.

Эта запись не создаёт право вето и не переименовывает полезную встречу в консенсус. Она связывает её с последующим официальным подтверждением. Она также не превращает операцию IANA в технический суд: уполномоченный субъект решает, может ли кандидат стать текущим, а IANA проверяет и регистрирует утверждённый артефакт по установленному правилу. Заметка 63 Хэн Лу служит здесь институциональной линзой, а не источником фактов о VELOCE. Хранение и происхождение могут сделать решение проверяемым, не присваивая хранителю право его принять.

Такое же разделение нужно для соответствия. RFC 9907 остаётся опубликованной BCP-основой: нормативные утверждения YANG рассматриваются как нормативная проза RFC, а новые и обновлённые модули регистрируются в IETF XML и YANG Module Names. VELOCE может предложить другой порядок сопровождения, но на дату отсечения он не заменил эту основу. Версия, указанная в RFC, последняя утверждённая, текущая строка IANA и тестируемая версия иногда совпадут, но это совпадение нельзя просто предположить.

Sources

  1. OPSAWG charter
  2. VELOCE Datatracker record
  3. IETF 126 OPSAWG minutes
  4. Pull request 49
  5. Heng Lu Note 63
  6. IANA YANG parameters
  7. OPSAWG VELOCE adoption result
  8. VELOCE pointer discussion
  9. 25 August VELOCE call summary
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907