Кратко
- RFC 9911 пересматривает общие модули
ietf-yang-typesиietf-inet-types, сохраняя их имена и пространства имён, но публикуя новую ревизию. Это Proposed Standard IETF от декабря 2025 года, который отменяет RFC 6991. - Стабильное пространство имён не означает неизменность семантики: могут измениться множества значений, канонические представления, шаблоны и описания, от которых зависят модели и инструменты.
- Добавлены типы даты и времени, длительности, языковой метки, номера протокола, link-local-адреса, адреса с префиксом, имени хоста и электронной почты. Тип
yang-identifierприведён в соответствие с YANG 1.1; ряд шаблонов и описаний исправлен или уточнён.
Практический вывод: общий модуль типов — это интерфейс для множества зависимых систем. Последствия определяются конкретной импортированной ревизией, моделью и реализацией. Источники не подтверждают всеобщее внедрение ревизии 2025 года и не дают оснований считать все значения RFC 6991 недействительными.
Показательный пример — date-and-time. В соответствии с семантикой RFC 9557 записи Z и +00:00 обе обозначают UTC, но только +00:00 утверждает, что UTC является местной точкой отсчёта. Буква Z такого утверждения в том же смысле не делает. Один разборщик может принять обе записи, другой — выбрать только одну как каноническую или отклонить пограничный вариант. Поэтому нужно проверять не только схему приложения, но и существующие данные, ответы хранилища и результат XML- или JSON-сериализации.
Новая ревизия также вводит типы для дат и времени, длительностей, языковых меток, номеров протоколов, link-local-адресов, адреса с префиксом, имени хоста и электронной почты. Исправленные шаблоны точнее выражают правила, а улучшенные описания меняют то, как тип должен пониматься разработчиком и оператором. Для нескольких типов явно указана эквивалентность с текстовыми соглашениями SMIv2, а для других — неэквивалентность. Совпадение названий само по себе ничего не доказывает.
Миграция начинается с инвентаризации импортов и ревизий: какие модели используют тип, какие значения уже лежат в хранилище, какие клиенты их записывают и читают. Затем следует воспроизвести обычные и пограничные значения в сервере, валидаторе, клиентской библиотеке и сериализаторе. Проверять нужно именно согласованное поведение разных реализаций, а не только то, что имя модуля осталось прежним. Поведение конкретного поставщика нельзя выводить из одного текста RFC без отдельного подтверждения.
Журнал доказательств с учётом ревизий
| Утверждение | Источник | Что это доказывает и чего не доказывает |
|---|---|---|
| Два модуля пересмотрены, RFC 6991 отменён | RFC 9911, аннотация и раздел 1 | Устанавливает новый нормативный ориентир, но не распространённость реализации. |
| Добавлены типы, изменены шаблоны и описания | RFC 9911, разделы 2 и 3 | Показывает поверхность изменений, но не делает все старые значения недействительными. |
yang-identifier согласован с YANG 1.1 |
RFC 9911; RFC 7950 | Связывает правила идентификаторов с семантикой YANG 1.1. |
Различие Z и +00:00 |
RFC 9911; RFC 9557 | Обе формы обозначают UTC, но только вторая задаёт UTC как местную точку отсчёта. |
| Имя модуля сохраняется при новой семантике | RFC 9911, разделы 3 и 4 | Непрерывность имени не гарантирует семантическую совместимость. |
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
