要約

  • draft-ietf-ivy-entitlement-inventory-05 は、組織が持つ権利、資産への紐付け、installed 参照、機能を支える権利、allowed、in-use、制約を別々に表す。
  • 提案モジュールは全ノードが読み取り専用であり、権利を実際に変更・執行する外部経路、同期、期限通知はモデルの外に残る。
  • 安全な判断には、データの生産者と時刻に加え、装置での受理、利用者権限、設定、運用状態、サービス結果までの連続した証跡が必要だ。

交換した装置に権利は移ったのか

故障したルーターを予備機へ交換したとする。資産管理者はライセンスを旧シリアルから新シリアルへ付け替えた。中央の entitlement は active。新しい network element への attachment も正しい。監視画面には installed の参照が現れ、機能は allowed=true と表示される。

ところが装置は機能を有効化しない。ローカルに必要なトークンが届いていない、ライセンスサーバーが旧装置の貸出を解放していない、あるいは新しいラインカードには別の add-on が必要だった。中央の操作は完了している。装置側の受理は完了していない。

逆に、旧装置が猶予期間中に動き続けることもある。台帳から外れたからといって、その瞬間に転送が止まるとは限らない。どちらの状態も、単一の「ライセンス済み」という語では扱えない。

2026年9月29日付の A YANG Module for Entitlement Inventory revision 05 は、この分断を構造化する。想定ステータスは Standards Track、失効日は2027年4月2日である。ただし現時点では IETF Network Inventory YANG WG の Internet-Draft であり、RFCでも、製品実装や相互接続性の証拠でもない。

一つの権利を九つの観測に分ける

最上位には組織の entitlement がある。識別子、製品、ベンダー、状態、開始日、期限、制約を持つ。次に、その権利を組織・利用者・network element・componentへ結び付ける attachment がある。資産側には installed-entitlements があり、別の枝には装置の capability がある。capability は supporting entitlement を参照し、allowed と in-use を報告できる。さらに全体または機能ごとの max/current value がある。

その先に、設定の受理、プロセス、隣接、経路、FIB、パケット、顧客サービスが続く。

所有、割当、装置内受理、依存関係、許可、利用、上限、実行、結果は九つの異なる命題だ。IDが同じでも、証明対象は同じにならない。

installed の意味は観測者で変わる

revision 05 は作業中の文書らしい語義の揺れを残している。scope では installed entitlement を資産へ割り当てられた権利とし、実機への直接 provision だけでなく中央システム上の論理割当も含み得ると説明する。一方、定義ではローカルに activate され機能が利用可能な権利とされる。後段では資産へ現在の権利を与える active な参照として扱われる。

将来の版で整理されるかもしれない。現在の運用で必要なのは、単語の意味を推測することではなく、誰が報告したかを保存することだ。

資産台帳は割当を知る。ライセンスサーバーは貸出を知る。装置はローカル受理を知る。コントローラーは最後の照会結果を知る。共通IDは照合を可能にするが、観測点を統合しない。

したがって installed には producer、意味、観測時刻、検証経路、cache age が必要になる。名前だけを信頼すると、論理割当が物理的な受理へ変換されてしまう。

無いことと分からないこと

presence container は報告能力そのものを表す。installed-entitlements が存在し空であれば、情報システムはこの資産に installed entitlement が無いと報告している。container が無ければ、報告できない可能性がある。

in-use の欠落も false とは限らない。supporting-entitlements が存在して空なら特別な権利が不要という意味になり得るが、container 自体が無ければ依存関係を報告できない。

ETLが欠落を一律に false や空配列へ変えると、unknown が deny または unrestricted に化ける。自動化では true、false、explicit empty、not reported を区別し、version と producer を添えるべきだ。

五段階の実装範囲

Level 1 は中央カタログ、Level 2 は資産の installed entitlement、Level 3 は capability、Level 4 は supporting entitlement と allowed/in-use、Level 5 は制約である。実装は対応レベルと差分を文書化するよう求められる。

Level 1 の製品は購入済み権利を管理できても装置内受理を答えられない。Level 3 は技術的に可能な機能を示せても利用権を答えられない。Level 4 は許可を示せても共有poolの競合を扱わないかもしれない。

調達では「対応」という一語ではなく、各レベルの実データ、欠落時の意味、更新周期、断線時動作を要求すべきである。

allowed は計算された判断

一つの capability が複数の entitlement を必要とする場合、allowed は全ての効果を合わせて表す。必須項目が無い、expired、revoked なら false が推奨される。

この値を検証するには、依存関係の完全な集合、各状態の鮮度、組合せルール、判断主体が要る。grace period を知るサーバーと知らないcontrollerは異なる答えを出せる。どちらのBooleanも、入力より強い証拠にはならない。

また allowed=true は管理者の権限ではない。RFC 8341 の NACM は NETCONF/RESTCONF principal の操作・データアクセスを制御する。entitlement は組織が機能を使う権利を扱う。ライセンスは利用者を昇格させず、管理者権限はライセンスを生成しない。

装置が権利を認めても、software version、メモリ、hardware、設定、topology が不適合なら機能は動かない。

in-use のセンサーは何か

installed entitlement と capability の両方に in-use を持てる。両者があれば整合すべきだが、利用をどう観測したかは別問題だ。

license server は seat の貸出を利用と呼ぶ。装置は設定の存在を利用と呼ぶかもしれない。controller は前回値を再掲する。運用者はセッションや実トラフィックを見る。それぞれの evidence radius は違う。

利用証跡には、状態を変えたイベント、観測方法、有効期間、無効化条件が必要だ。routing capabilityなら、設定、process、adjacency、route、FIB、packetを順に確認する。in-use は入口であって結論ではない。

制約値は予約ではない

モデルは installation数、帯域、connection、tunnelなどのmax/current valueを表現できる。だが current 80 / max 100 は、新しい20を確約しない。値が古い、二つのcontrollerが同じ余白を使う、configured capacityとactive usageの単位が違う、といった事情がある。

parent entitlement による階層も持てる。YANG制約は直接の自己参照を防げても、深いcycleを全て見つけられない。管理系がA→B→Aを検証しなければならない。schema-validなデータでも権利graphは不正になり得る。

制約証跡にはscope、unit、window、source、timestamp、reset rule、reservation stateを添える。atomicな予約が無いcurrent valueは観測であり、将来の許可ではない。

読み取り専用の外側で状態は書かれる

提案モジュールは全て config false である。基礎状態を変更するlicense serverやasset platformとの通信は文書の範囲外だ。

NETCONF/RESTCONFを相互認証し暗号化しても、古い状態は正しく運べてしまう。security considerations は、外部経路が侵害されると偽のentitlement stateが注入され、capabilityが誤ってallowedまたはrestrictedに見えると警告する。

中央記録、ローカルinstalled、actual usageの不一致検知は推奨されるが、万能の優先順位や鮮度は定義されない。期限日は出せても事前通知は管理applicationの責任である。cacheが必要なら、最終成功refreshをstatusの一部にするべきだ。

実行可能な権利の証跡列

必要なのは、grant、assignment、activation、dependency closure、permission、NACM access、usage、restriction enforcement、service outcome の九つである。各証跡はactor、object、timeを持ち、前後を参照する。

一つのdatabaseに統合する必要はない。むしろ別々のauthorityが同じ結論へ到達したことが価値になる。共通inventoryの役割は、異なる事実を結び、どこから先は自分が証明できないかを明示することだ。

情報源