Кратко

  • RFC 9907 — это BCP 216, опубликованный в марте 2026 года. Он задаёт правила для авторов и рецензентов документов с моделями данных YANG, включая модули, которые ведёт IANA.
  • Документ отменяет RFC 8407 и обновляет RFC 8126. Границы программных компонентов, уникальные имена, связь ревизии с RFC, семантика NMDA и порядок работы с реестром становятся предметом обязательной проверки.
  • RFC 9907 не меняет протокол обмена и не гарантирует совместимость реализаций. Его практическая сила — в дисциплине, которая позволяет обнаружить двусмысленность до публикации.

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

Нормативные модули и подмодули YANG в Internet-Draft или RFC должны быть заключены между тегами CODE BEGINS и CODE ENDS. Для автора это точная граница компонента кода, а для рецензента — однозначный объект проверки. Имена опубликованных модулей должны быть уникальными: нормативные модули IETF начинаются с ietf-, а модули-примеры — с example-. Пример остаётся пояснением и не становится нормативным только потому, что включён в документ.

Заголовок модуля должен содержать актуальное заявление об авторских правах IETF Trust и указывать реестр YANG Parameters. Внешние ссылки, не покрытые импортированными модулями, должны находиться в соответствующих операторах reference. Для каждой опубликованной ревизии требуется оператор revision со ссылкой на документ, в котором содержится данный модуль. Это превращает извлечённый код в проверяемый артефакт, а не в бесхозный фрагмент текста.

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

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

Контрольный список перед публикацией

  1. Ограничен ли каждый нормативный компонент кода тегами CODE BEGINS и CODE ENDS?
  2. Уникально ли имя модуля и начинается ли оно с ietf- для нормативного модуля IETF или с example- для примера?
  3. Содержит ли заголовок заявление IETF Trust и указание на реестр YANG Parameters?
  4. Находятся ли внешние ссылки в надлежащих операторах reference?
  5. Связана ли каждая опубликованная ревизия с документом, содержащим модуль?
  6. Различены ли модель данных, отдельный модуль и ненормативный пример?
  7. Описаны ли хранилища NMDA, конфигурация, состояние и жизненный цикл?
  8. Проверены ли язык, примеры, анализ безопасности и раздел IANA Considerations?
  9. Следует ли изменение модуля, который ведёт IANA, процедуре реестра, а не прямому редактированию сгенерированного текста?

Решение оператора о принятии

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

Источники