YANGサービスのライフサイクルが分岐するとき

Summary

ONSENの問題記述を扱う個人Internet-Draftは、YANG構文と、ライフサイクル、validity、duration、feedbackというサービスの運用上の意味を分けている。-01は2026年8月19日に失効しており、WG採用文書でもIETF合意でもない。
注文受理、intended configuration、applied configuration、観測されたhealth、商取引上のcloseは別の命題である。一層の成功表示は「active」「expired」「rollback」「closed」の全層共通の意味を証明しない。
Daniel Kadeは、正確なintent、状態語彙、時間基準、分解、変換、実行証拠、決定権限、終結証明を結ぶservice-semantic receiptを提案する。これは編集上の提言で、ONSENの要件ではない。

一つの時刻に複数の終わりがある

攻撃者も壊れたparserも要らない。顧客が二拠点間の高帯域接続を一定時間だけ注文する。BSSが注文を持ち、service orchestratorがnetwork serviceへ分解し、controllerがsegmentとdevice configurationへ落とす。telemetryとassuranceは結果を観測する。

終了時刻に、BSSのcompleteは課金停止だけを意味し得る。expiredは更新不可、decommissioningは削除要求の発行、activeは設定がまだ適用中という意味かもしれない。古いmeasurementに基づくhealthは、最後のintent変更後もしばらく良好に見える。

どの記録も局所的には真であり得る。policy mirrorはその接合部に現れる。dashboardが異なる権限範囲の事実を一色へ圧縮し、最も表示しやすい層へサービス全体の解釈権を暗黙に与える。

YANGはnode、type、constraint、operation、notificationを精密にできる。しかし同じschemaを受け入れる二つの製品が、transitionの発効点、時計、partial failure、rollback、close権限まで共有するとは限らない。

ONSEN文書を現在地より先へ進めない

draft-xie-onsen-problem-statement-01はservice semanticsをYANG構文ではなく、lifecycle behavior、validity、duration、feedbackという運用上の意味と定義する。同様のmodel由来のAPIでもvendorやdeploymentごとに解釈が異なり、OSS/BSS側へ個別統合を強いると述べる。

DTS-I例は大量データを高帯域で予測可能な時間内に運ぶ一時的サービスで、異種・複数domainの調整を要する。注文例にはstart、end、bandwidthがあり、BSS、orchestrator、controller、access、VPN、data-centre egressを横断する。一つの意図が別々の時計を持つ複数objectになる。

草案はinstantiation、monitoring、troubleshooting、modification、decommissioningの分断を挙げる。activation time、duration、expiration、rollbackが抽象にない場合があり、似たmetricでもdefinition、unit、scope、update frequencyが異なる。configuration中心のAPIは、要求した振る舞いが適用され、今も有効かを十分に返せない。

revisionは2026年2月15日付で、本文上の失効日は8月19日である。調査時のDatatrackerはactive individual draftと表示したが、標準化過程でformal standingはない。Operational ConsiderationsとSecurity Considerationsは未完成で、具体的solution、protocol、data modelを提案しないと明記する。

ONSEN WG自体はapproved charterを持つactive WGで、抽象modelの更新やYANG service APIとOSS/BSSのinterfaceを扱う。charterは作業範囲を承認するもので、関連する個人draftの採用を遡って証明しない。

Schemaは状態の条約ではない

RFC 8969はcustomer service、network、device modelを分け、意図を下げoperational informationを上げる構造を示す。IETF合意のInformational RFCだが、全実装へ一つのstate machineを与える文書ではない。

RFC 8342はintended configuration、applied configuration、system stateを分ける。transformation、resource不足、delay、protocol interactionによって値と寿命はずれる。commit成功からservice fulfillment成功を導くことはできない。

RFC 9417は、configurationが適用済みでもserviceが期待通り稼働するとは限らないとする。assurance graphはservice instance、subservice、health、symptomを結び、RFC 9418が対応moduleを与える。差異は見つけられるが、購入時間やclose権限は別に接続しなければならない。

RFC 8299のcustomer-facing L3VPN service modelとRFC 9182のoperator-facing network modelは視点が違う。field mappingは必要でも、下位transitionが上位義務を満たした証明ではない。RFC 9834もadministrative statusとoperational statusを分離し、両方を見るよう求める。

緑の表示を動詞へ戻す

acceptは要求を受け入れたこと、validateは境界が知る制約を通ったこと、commitはtransactionを記録したことを示す。intendedは適用しようとする値、appliedは実際に使う値、observed healthは特定時刻・範囲・規則のmeasurementである。

commercial closeは課金や顧客義務を止め得る。resource closeはtunnel、address、credential、monitoring subscriptionの解放確認を要する。一つの動詞で残りを代用しないことが自動化の出発点だ。

Service-semantic receipt

Daniel Kadeが提案するservice-semantic receiptは、重要なtransitionごとに語彙の境界を記録する。世界共通の状態名を強制する新標準ではない。

最初にorderとintentのdigest、model/module revision、feature、deviation、extension、前提状態を固定する。次にactivation target、duration、expiry、timezone、clock source、grace period、event timeとobservation timeを分ける。

decompositionはcustomer service、network instance、device instanceをstable identifierで結ぶ。adapterとtransformationにもversionを付ける。「18時までに転送完了」を「18時まで帯域予約」へ変えるなら、そのsemantic lossは実装詳細でなく承認対象になる。

evidenceはaccept、validate、commit、intended、applied、observedの時刻、admin/operational state、metricのunit、scope、freshness、symptomを並べる。矛盾を平均して緑にしない。

authority欄はactivate、modify、cancel、retry、compensate、rollback、closeを誰が決めるかを層ごとに記す。個人名でなく、検証可能なroleや範囲限定automationでもよい。closureは解放resource、remnant configuration、遅延証拠、課金停止、不明点を残す。receiptにも期限がある。

RFC 9968はIAB NEMOPS workshopの記録として、fragmentation、service-level modeling、observability、mapping、verifiable configurationを扱う。ただし参加者の見解は必ずしもIABの立場でなく、記録全体がconsensusを示すわけでもない。問題認識の証拠であり、この提案の権威ではない。

正確な時刻にも規則が要る

二つのsystemが同じtimestampを正しく読み、逆の行動を取ることがある。一方はendを利用可能な最後の瞬間とし、他方はdecommissionを始める最初の瞬間とする。一方はgrace period中に既存flowを完了させ、他方は境界で停止する。値は一致しても、時間を効力へ変える規則が一致していない。

receiptにはstartとendだけでなく、境界を含むか、timezone、clock source、許容skew、renewal条件、遅れたactivationの扱いを記す。event time、observation time、processing timeも分ける。遅配messageは受信順を変えるが、事実の発生順を変更しない。

retryにも独自のpolicyが必要だ。旧windowを継承すれば、作成直後に期限切れが近いserviceになり得る。新しい全期間を無断で与えれば、automationが契約を延長する。技術的な再実行に見える操作が制度上の期間変更を隠してはならない。

Composite serviceを一つの色にしない

DTS-Iのaccess、VPN、data-centre egressは別々にtransitionできる。aggregate activeでは全segmentが適用済みか、最小pathだけ動くのか、redundant componentが失われたのか分からない。failedも、完了部分とcompensation対象を区別しない。

receiptはcomponent stateとaggregation ruleを残す。全componentの成功が必要か、critical componentは何か、degradationが顧客義務を変えるか、どのremnantがclosureを妨げるかを示す。rule自体にもversionが要る。同じtelemetryでもaggregationを変えれば結論が変わるからだ。

operator間の証明は内部topologyや契約を公開する必要がない。範囲限定commitment、epoch、結果、責任interfaceを外へ示し、詳細は保護されたreferenceに置ける。confidentialityは開示量を制約するが、unknownをsuccessと表示する理由にはならない。

Rollbackは逆向きのcommitではない

新configurationを削除しても旧serviceへ戻るとは限らない。capacityは再配分され、credentialは失効し、dataは転送済みで、外部systemがsuccess notificationを受けて動いているかもしれない。controllerの復旧だけでBSS、assurance、隣接domainが旧epochへ戻るわけではない。

receiptはtechnical restoration、commercial compensation、evidence correctionを分ける。第一は復元可能state、第二は不可逆effectの責任、第三は元のdecisionを消さずcorrectionを追加する。これにより「rollback完了」が検証可能なscopeを持つ。

凍結sourceは特定operatorの障害、普遍的timeout、必須architectureを証明しない。証明できる結論は狭い。同じ構造が異なる制度的意味を運べる以上、自動化は各層の真実と、その翻訳、権限、終結を同時に残す必要がある。

YANGサービスモデルが一致してもライフサイクルの意味は分岐する

なぜ重要か

Summary

一つの時刻に複数の終わりがある

ONSEN文書を現在地より先へ進めない

Schemaは状態の条約ではない

緑の表示を動詞へ戻す

Service-semantic receipt

正確な時刻にも規則が要る

Composite serviceを一つの色にしない

Rollbackは逆向きのcommitではない

情報源

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説