Кратко

  • Редакция 04 draft-ietf-green-power-and-energy-yang стала доступна 9 сентября 2026 года. Это Internet-Draft рабочей группы GREEN в состоянии I-D Exists, а не RFC или утверждённый стандарт.
  • Новый раздел утверждает, что source-component-id привязан к uuid из RFC 8348 и потому позволяет сопоставлять Energy Object между устройствами, системами управления и административными доменами.
  • Модуль той же редакции оставляет leafref на /hw:hardware/hw:component/hw:name. В YANG 1.1 path определяет целевой узел и пространство значений, поэтому исполняемый контракт выбирает локальное имя, а не отдельный leaf UUID.
  • Сначала текст и модель должны выбрать одну идентичность. Daniel Kade также предлагает защищённую квитанцию привязки для замены и повторного связывания. Проект её не требует.

Семантика стала сильнее, схема осталась прежней

Список недавних документов IETF датирует редакцию 9 сентября. Текущая карточка относит её к активным документам GREEN, а история фиксирует доступность новой версии в 05:30:49 в показанной зоне -0700. Статус остаётся I-D Exists. Успешная YANG-валидация говорит о синтаксисе, но не сравнивает смысл абзаца с выбранным leafref.

Новый раздел идентификации различает три поля RFC 8348. name имеет смысл внутри конкретного устройства, physical-index зависит от поддержки MIB, а глобально уникальным назван только uuid. Затем текст сообщает, что source-component-id использует UUID и даёт однозначную связь между устройствами, платформами и административными доменами.

Сам модуль сохраняет type leafref, путь /hw:hardware/hw:component/hw:name и описание ссылки на имя компонента. Так было и в редакции 03. Официальное сравнение показывает новое обоснование UUID, но не переносит на него ссылку.

Для leafref решающим остаётся путь

RFC 7950 определяет path как указатель на целевой leaf или leaf-list. Ссылающийся узел получает пространство значений цели. В опубликованной редакции целью является name.

В RFC 8348 name служит строковым ключом списка аппаратных компонентов. uuid — другой, необязательный, доступный только для чтения leaf типа yang:uuid. Модель RFC предназначена для управления аппаратурой одного сервера. Поэтому одинаковый psu-1 на двух устройствах может быть допустим локально, но не подтверждает единство физического объекта.

Это не доказательство ошибки в реализации. Разработчики могли создать частную таблицу, следовать замыслу текста или ждать исправления. UUID тоже не доказывает владение, непрерывность установки или право менять питание. Доказан только внутренний разрыв в неизменяемой версии документа.

Субъект связывает измерение с командой

Архитектура GREEN использует иерархию для проверки и суммирования энергометрик. Сценарии включают отчётность жизненного цикла, косвенные оценки и управление питанием. Если два локальных имени объединены как один компонент, класс точности не исправит ошибочно выбранный объект.

Проект разносит запрошенное административное и наблюдаемое рабочее состояние питания. Для другой ссылки управления require-instance false позволяет хранить конфигурацию до появления Energy Object или после его исчезновения; при отсутствии объекта она не действует. Раздел безопасности предупреждает, что несанкционированная запись может выключить критическую инфраструктуру, повредить оборудование или нарушить мониторинг. Для ограничения операций по NETCONF и RESTCONF указан NACM.

NACM устанавливает право автора команды. Он не подтверждает, что сохранённое намерение после замены снова связано с тем же физическим субъектом. Такое связывание требует отдельного решения.

Согласовать модуль и сохранить решение о связи

Для стандарта выбор прост. Если нужна межсистемная идентичность, YANG должен не двусмысленно переносить UUID или ссылаться на него. Если нужен локальный name, междоменное обещание следует ограничить и определить явное отображение.

Защищённая операционная квитанция могла бы включать:

  1. точную редакцию модуля и её digest;
  2. Energy Object id, устройство и административный домен;
  3. локальное имя и наблюдаемый UUID либо явное отсутствие;
  4. источник, полномочие и время установления связи;
  5. серийный номер, инвентарные или заменяющие доказательства, если есть;
  6. исчезновение, замену, переназначение или объединение;
  7. сохранённое административное намерение питания;
  8. орган и время одобрения новой связи;
  9. результат проверки до возобновления агрегации или управления.

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

Принцип минимальной начальной спецификации Heng Lu предлагает стандартизовать лишь общую границу, а не весь внутренний архив. The Policy Mirror добавляет: после автоматического действия должны оставаться видимыми правило и субъект решения.

Это моя редакционная рекомендация. В редакции 04 её нет, и рабочая группа GREEN её не принимала.

Граница доказательств

Источники подтверждают несоответствие абзаца и leafref. Они не подтверждают внедрение, неверную атрибуцию, повторное выполнение старой команды или ущерб. UUID в RFC 8348 необязателен и сам по себе не предоставляет полномочий. Следующая редакция может устранить расхождение.

Точный вывод таков: новый текст обещает корреляцию по UUID, а текущий модуль выбирает component/name.

Источники