要約

  • draft-ietf-opsawg-veloce-yang-00 は、変動するブランチの HEAD ではなく、特定のタグまたはコミットを RFC から参照する案を示す。これは内容同一性の強い証拠だが、マージや CI 成功だけでワーキンググループの合意にはならない。
  • 公開後も、判断記録の保存、リリースの保管経路、装置が報告する実際の module-set、代表的な操作、サービス結果を別々に確かめる必要がある。

同じコミットを見ているのに、話が食い違うことがある。

編集者は「変更はマージ済み」と言う。レビュー担当者は「検証は通った」と言う。リリース担当者は「タグを切った」と言う。運用者は「その revision は装置にない」と答える。全員が正しい可能性がある。答えている質問が違うからだ。

この違いを制度設計の問題として扱うのが VELOCE である。draft-ietf-opsawg-veloce-yang-00 は、YANG モジュールのソースを説明文書から分離する実験を提案する。モデルの説明、IANA、セキュリティ、運用上の考慮、参照は文書に残す。一方、モジュールはソースコード管理リポジトリで開発・保守する。

狙いには現実性がある。YANG は文章であると同時に、パーサ、validator、依存関係、feature、deviation、SID ファイルに接続するコードである。小さな修正を差分で確認し、自動検査を行い、再現可能な環境で試す方が、長い文書全体を毎回扱うより適切な場合が多い。

凍結した版は 2026 年 8 月 25 日付の OPSAWG ワーキンググループ Internet-Draft である。本文ヘッダーは Intended status を Experimental と記す一方、Datatracker の要約欄には予定 RFC status がない。履歴には 00 版だけがある。RFC でも、完了した実験でも、導入実績でもない。新規モジュールは二年、増分的な -bis は一年という目標も、これから評価する仮説である。

中核となる提案は明快だ。YANG モジュールを文書へ挿入せず、ブランチの HEAD ではなく特定タグまたはコミットハッシュへのリンクを必須にする。公開時点のモジュールを後から取得し、検証できるようにするためである。

これは可変リンクよりはるかに強い。main は移動するが、コミットは一つの状態を指す。YANG Doctor、実装者、監査者が同じ対象を検査できる。

ただし、固定されたのは対象であって、権威ではない。

RFC 8874 は、GitHub で行われた作業に特別な地位はなく、その成果はワーキンググループが承認、拒否、変更できると明記する。リポジトリの文書が常に完全な合意状態を映す必要もない。編集者には作業を進める裁量があるからだ。

リポジトリの画面はこの距離を短く見せる。issue は Closed、pull request は Merged、check は Passed と表示される。has-consensus というラベルさえ付けられる。しかし表示は管理状態であり、名前そのものから正統性は生まれない。

RFC 8874 は合意判断をメーリングリストで確認するよう求め、最終的な評価を議長に置く。RFC 2418 も rough consensus は 51% の投票ではないとする。会合で得た判断はリスト上で再確認し、異なる参加経路の意見を考慮する。

したがって、正当なマージであっても、必ずしも WG 判断の最終受領証ではない。編集者が通常の変更を進める一方、設計や相互運用性に関わる変更では議長が合意確認までマージを待つよう求められる。

保存すべきなのは、技術課題、採用した解決、議長による範囲を限定した合意判断、そしてそれを実装した正確なコミットを結ぶ線である。判断とコードを別々に残すだけでは、後日それらが同じ決定だったと証明できない。

CI は別の有用な受領証を出す。RFC 8874 は文書生成、形式言語の検証、テスト実行を例示する。VELOCE は YANG validator と、ローカルでも再現できるコンテナ環境を推奨する。

緑の結果は、指定された入力に指定された検査が通ったことを示す。その範囲はコミット、validator の版、import、feature、設定、コンテナイメージ、テスト集合で決まる。存在しないテストの成功や、異なる実装間の同一動作までは証明しない。

自動化を弱める必要はない。むしろ分母を保存すべきだ。「検証済み」という言葉に、何を、何で、どの依存関係と例外の下で検査したかを添える。

公開はさらに別の境界である。VELOCE の特定参照により、審査対象と RFC が名指すモジュールを一致させられる。これは規範上の同一性を強くする。しかし RFC がベンダーのパッケージを作るわけでも、装置の datastore を更新するわけでもない。

その間には、リポジトリの管理、リリース生成、署名、依存選択、ベンダー統合、イメージ作成、配布、ローカル有効化がある。規範的なタグが正確でも、製品には古いモジュールが残り得る。

しかもコードの保全と意思決定文脈の保全は違う。RFC 8874 は Git の複製がリポジトリ内容を守る一方、issue、PR の議論、レビュー、wiki は失われやすいと警告する。外部サービス障害や権限アカウントの侵害も対象だ。RFC 8875 は組織管理とバックアップを補う。

コミットだけが残り、「なぜこの変更を採ったのか」が消えれば、内容は保存されても権威の由来は保存されない。

実行時の最初の受領証は装置から得る。RFC 8525 の YANG Library は、datastore に関連する module-set、revision、feature、deviation をサーバーが報告する仕組みを定める。公開タグと装置が主張するスキーマ環境を比較できる。

一致しても結論ではない。YANG Library はサーバーの主張であり、すべての制約や RPC が正しく働く証拠ではない。代表的な NETCONF/RESTCONF 操作、状態の再取得、サービスの独立観測が必要だ。

Heng Lu の running-code の視点は、規格を否定するためではなく、証拠の順番を守るために使える。タグはリポジトリ層、合意は意思決定層、RFC は公開層、ロード済みスキーマと挙動は運用層に属する。

最小初期仕様の原則は、VELOCE の速度を損なわずに境界を守る。共通化するのは、正確な内容、再現可能な検証、追跡可能な合意、不変の公開参照という最低限の結合でよい。ツールや製品化の方法はローカルに残し、独立実装と自発的採用に最終的な価値を示させる。

もう一つの注意は参加の見え方だ。issue を毎日追う人は自己選択された集団であり、メーリングリストだけを見る専門家もいる。活発な画面を代表性と取り違えないために、RFC 8874 は場を再接続している。

「モジュールは完成した」という言葉を聞いたら、何が完成したのかを問うべきだ。バイト列か、WG の判断か、出版か、製品化か、稼働結果か。タグが答えるのは、そのうち一つである。

情報源