要点

  • draft-ietf-green-power-and-energy-yang-04は2026年9月9日に公開された。GREEN作業部会のI-D Exists段階にあるInternet-Draftで、RFCでも承認済み標準でもない。
  • 新設された説明は、RFC 8348のuuidをsource-component-idに使い、装置、管理システム、管理ドメインを越えてEnergy Objectを対応づけるとしている。
  • しかし同版のYANGは、そのleafを/hw:hardware/hw:component/hw:nameへ参照させる。YANG 1.1ではpathが参照先と値空間を決めるため、モデルが選ぶのは別leafのUUIDではなくローカル名である。
  • まず本文とスキーマを同じ識別子に合わせるべきだ。Daniel Kadeは、その後の交換・再対応づけのために保護されたidentity-binding receiptも提案する。草案の要件ではない。

04版で強くなった主張と、変わらなかった一行

IETFの最近の文書一覧には9月9日付で04版が載る。DatatrackerではGREEN作業部会文書、状態はI-D Existsであり、履歴は表示上の-0700で05:30:49に新しい版が利用可能になったことを記録する。YANG検証がエラーなしでも、文書の説明と参照先が同じ意味かどうかまでは保証しない。

新しいHardware Component Identification節は、RFC 8348のname、physical-index、uuidを比較する。nameはその装置の中でだけ意味を持ち、physical-indexは機能の実装状況に左右され、全域で一意なのはuuidだけだと整理する。そのうえでsource-component-idはuuidに結び付き、ローカル命名規則に依存せず管理ドメイン間で相関できると述べる。

ところがモジュール本体のleaf定義は/hw:hardware/hw:component/hw:nameをpathに持ち、descriptionもcomponent nameへの参照としている。03版からこのpathは同じで、公式diffではUUIDに関する説明だけが明確になった。

片方は世界で一意な識別子、もう片方は装置内リストのkeyである。同じ名前の二つの電源部品を、文章だけでは区別できない。

YANGを読む機械は説明文からUUIDを推測しない

RFC 7950によれば、leafrefのpathは参照されるleafまたはleaf-listを特定し、参照元はその値空間を受ける。04版のpathはnameなので、スキーマに従う処理系が扱うのはnameのstringである。

RFC 8348ではhardware component listのkeyがnameであり、uuidは独立したoptionalかつread-onlyのyang:uuidである。同RFCのモデルは単一server上のhardware managementを対象にする。装置内で正しいnameと、管理システムを越えて同じ物体を示す証拠は別物だ。

ここから既存製品の不具合を推定することはできない。実装者が独自のmappingを持つか、文章を優先するか、改版を待つかは資料にない。またUUIDがあっても、所有者、設置継続、制御権限は証明されない。確認できるのは、現在の一つの版が同じleafについて異なるidentity contractを示すという点までである。

複数装置がpsu-1を持つことも、交換後に同じnameを使うこともできる。各値はlocal listでは妥当でも、長期の電力曲線を同じcomponentとしてつなぐ根拠にはならない。

観測のsubjectを誤ると、精度もアクセス制御も救えない

GREEN frameworkは階層関係を使った測定の集約と検証を描き、use casesはlifecycle reporting、間接計測、energy controlを扱う。これらに共通する前提は、観測対象が一貫していることだ。精度等級の高い値でも、別の部品に結び付けば信頼できる証拠ではない。

制御側では04版がadmin power stateと実際のoper stateを分ける。別のcontrol参照にはrequire-instance falseが使われ、Energy Objectがまだ存在しない時や消えた後でも設定を残せる。対象がない間、その設定は効果を持たない。Security Considerationsは、adminへの不正なwriteが重要設備の停止、hardware damage、monitoring妨害につながり得るとし、NACMで権限を絞るよう求める。通信手段としてはNETCONFとRESTCONFが挙げられる。

しかし認証された操作者であっても、保存済みintentの参照先が交換後も正しいとは限らない。アクセス権とsubject continuityは別の検査である。

仕様の一致と運用上の再対応づけ

標準化上の修正は限定できる。cross-system identityを目標にするなら、moduleがuuidを直接持つか曖昧なく参照する必要がある。local nameを残すなら、本文の主張をそのscopeに縮め、別の明示的mappingを定義すべきだ。

運用では、次の要素を持つ保護されたidentity-binding receiptが役立つ。

  1. 採用したdraft/module版とdigest。
  2. Energy Object id、device scope、administrative domain。
  3. local component nameと観測したuuid。uuidがなければ明示的null。
  4. mappingを示したsource、authority、observation time。
  5. 利用可能なserial、asset、replacement evidence。
  6. disappearance、replacement、reassignment、mergeの記録。
  7. objectに残るadmin power intent。
  8. rebindを承認したauthorityとdecision time。
  9. telemetry aggregationやcontrol再開前のvalidation result。

このreceiptを公開台帳にする必要はない。草案自身が、細かなpower dataやobject relationshipはworkload、capacity、customer activity、高価値の電力topologyを漏らし得ると警告する。hashとscope付きidentifier、結果codeは認可された管理面に保持できる。

Heng Luのminimum initial specification論に従えば、共有すべきなのは全内部情報ではなく相互運用に必要な境界である。The Policy Mirrorが示すように、自動化後もどのruleとidentityが動作を起こしたかを見失ってはならない。

これは私の提案であり、04版にもGREEN作業部会の合意にも含まれない。

証拠の範囲

資料が示すのは、9月9日版の説明とleafrefの不一致である。実装済み製品が誤ったcomponentを選んだこと、energy dataが混同されたこと、休眠中のpower commandが再実行されたことは示さない。RFC 8348のuuidはoptionalであり、uuidだけで所有権やcontrol authorityは成立しない。次版で整合される可能性もある。

現時点の結論は単純だ。説明はUUIDによるdomain横断相関を約束し、moduleはcomponent/nameを選ぶ。ガバナンスの最初の成果は、この二つを一つの契約にすることである。

出典