要約

  • draft-ietf-ivy-entitlement-inventory-05 は、利用権、装置機能、制約を記述する読み取り専用 YANG モデルの提案である。現時点では Internet-Draft であり、RFC でも導入実績の報告でもない。
  • 草案の installed entitlement は、装置内での有効化だけでなく、中央システム上の論理的割り当ても指し得る。したがって「誰が報告したか」は値そのものと同じくらい重要だ。
  • allowed、in-use、実際のサービス動作は別々の主張である。台帳は関係を記述できるが、一つの主張を別の主張の証明に変えることはできない。

同じ形の二つのレコードを考える。どちらにも「ルーター r9 に entitlement ent-47 がインストール済み」とある。一方では、装置がライセンスを受け取り、検証し、ローカル状態として報告している。もう一方では、資産管理データベースが r9 に権利を割り当てただけで、装置は外部契約に依存し、ライセンス自体を保持していない。文字列は同じでも、実行層の証拠は違う。

改訂 05 は、この差を意図的に包含している。適用範囲では、installed entitlement を特定のネットワーク資産へ割り当てられた権利とし、「インストール」は装置・コンポーネントへの直接プロビジョニングでも、中央システム上の論理的割り当てでもよいとしている。一方、用語定義では、ネットワーク要素上でローカルに有効化され、その機能が利用できる権利と説明する。これは単なる文言上の問題ではない。一つの可搬なラベルが、異なる証拠経路を覆う設計上の境界である。

三つの配備モデルを見れば、境界はさらに明確になる。権利を装置内に置いてローカルに制限を実施する方式、外部ライセンスサーバーへ問い合わせる方式、そして商業契約だけが存在し、遵守管理が装置外で行われる方式である。最後の方式では、装置が entitlement を知らなくても動作し得る。装置、ライセンスサービス、監視基盤はいずれも同じモデルの一部を報告できるが、どれか一つが自動的に唯一の証人になるわけではない。

この不均一な現実に合わせ、モデルは部分実装を前提にする。レベル 1 は組織の entitlement 台帳、レベル 2 は資産への割り当て、レベル 3 は資産の機能、レベル 4 は機能と supporting entitlement の対応および allowed と in-use、レベル 5 はインストール数、帯域、接続数などの制約を扱う。

各レベルは成熟度の飾りではなく、回答可能な問いの範囲を決める。レベル 1 は組織が何を管理するかを示せるが、特定装置に何が届いたかは示せない。レベル 2 の割り当てだけでは装置の能力は分からない。レベル 3 の能力一覧だけでは、それを支える権利を特定できない。レベル 4 で関係が結ばれ、レベル 5 で上限や利用量が見える。部分的なツリーを完全な事実として表示すれば、消費側が存在しない証拠を作ることになる。

presence container は「この情報を報告できる」という宣言に使われる。コンテナがない場合、それは実装が報告できないという意味であり、現実に権利、機能、制約が存在しないことの証明ではない。この区別を自動化が失うと危険だ。欠落を false に変換すれば利用可能な機能を止め得る。欠落を true に変換すれば根拠のない処理を進め得る。正しい値はしばしば「不明」である。

レベル 4 の二つのブール値にも限界がある。複数の entitlement が必要な機能では、allowed は必要条件の合成結果を表す。いずれかが欠落、期限切れ、失効なら false とすべきだ。in-use は機能が現在稼働中かを報告する。しかし、どちらも読み取り専用台帳の報告値である。設定トランザクション、機能の有効化命令、独立したテレメトリ、顧客向けサービス成功の不変ログではない。

草案自身も三つの層が食い違う可能性を認めている。中央の entitlement レコード、ローカルにインストールされた entitlement、実際の機能利用の不整合を検出する仕組みを実装すべきだとしている。三者が同じなら照合は不要だ。モデルの価値は、それらを一つのグラフに置きつつ、一つの出来事として偽装しない点にある。

機能の粒度も情報源依存である。ベンダーは Advanced Services のような大きな束を一機能として出すことも、MPLS、BGP、QoS を個別に列挙することもできる。したがって allowed: true は、機能定義、ベンダーの語彙、対象資産の範囲と一緒でなければ解釈できない。共通スキーマが標準化するのは関係であって、あらゆる製品の商業的な境界ではない。

自動検出は今回の範囲外だ。関連付けはライセンスサーバーや資産データベースに投入される場合も、装置の管理インターフェースから報告される場合も、棚卸しで手入力される場合もある。期限切れ通知も定義されない。日付は提供されるが、別システムが期限接近を検出して通知を届けなければならない。日付は通知の受領証ではなく、割り当てもローカル有効化の受領証ではない。

セキュリティ面でも同じ境界が残る。NETCONF や RESTCONF は保護されたセッションで情報を運び、NACM は機密性の高い契約・機能情報の閲覧者を制限できる。しかし、それは報告へのアクセスを守る仕組みであり、外部ライセンスサーバーや資産管理基盤の内容が正しいことを証明しない。草案は、外部経路への虚偽状態の注入により、実際の権利と異なる allowed や制限が表示され得ると警告する。

標準化状況にも同じ精度が必要だ。改訂 05 は 2026 年 9 月 29 日付で Standards Track を意図するが、まだ Internet-Draft である。YANG ツリーや将来の登録は共通語彙を作れる。それだけで IETF 承認、ベンダー実装、完全な対応、データの鮮度、特定ネットワークの状態を証明することはない。

この草案は不確実性を消すのではなく、不確実性を配置する場所を作る。組織台帳、資産への割り当て、装置内での有効化、許可状態、報告された利用、制約、実動作を別々の主張として扱える。危険なのは、ダッシュボードがその全てを「ライセンス済み」という一つの緑色表示に押し込めた瞬間だ。

情報源