要約

  • OPSAWGは2026年8月25日にVELOCEを採用し、第00版をWG文書として公開した。これはRFC、BCP、または最終的なIETF規則ではない。
  • 同日のプロジェクト会合要約はIANAポインターを確認したと記すが、第00版はIANA作業なしと明記する。ハッシュ、状態、管理連絡先、承認経路を提案するPR49も、調査期限時点では未マージだった。
  • プロジェクト会合での方向づけは、メーリングリストで確認されたWG合意ではない。GitHubのマージもWG、Area Director、IESGの承認ではない。IANAの登録行は承認済み版を記録できるが、その規範的意味を承認する権限は持たない。
  • 草案はすでに移動するブランチ先頭を避け、特定のタグ付き版を参照する。次に必要なのは、後続版の承認、IANAによる取得・検証、実装者が適合性を主張できる版を結ぶ記録である。

採用、会合、草案、提案中のPRは別の出来事である

採用結果では、OPSAWGの議長が十分な支持を認め、個人草案を他の変更なしに draft-ietf-opsawg-veloce-yang-00 として再提出するよう求めた。Datatrackerは第00版を8月25日承認のWG文書と表示する。これは文書をWGの検討対象に置く行為であり、その後に現れるすべてのポインター設計を先取りして承認する行為ではない。

第00版の考え方は、YANGモジュールをRFC本文に入れないことだ。RFCはリポジトリの特定タグ付き版を指す。mainのようなブランチは公開後も動くが、指定されたタグまたはコミットなら、将来の読者は公開時に指されたバイト列を取得し検証できる。さらに草案は、採用済みモジュールをIETFリポジトリで更新し、RFCではモジュールへの参照だけを更新することを想定する。狭く検証可能な修正であれば、RFC全体の改訂を毎回求めない利点がある。

ただし、モジュールをRFCの容器から外すと、その容器が黙ってまとめていた事実も分けて扱わなければならない。誰が認めたのか。認めたのはどのバイト列か。どこに保存されるのか。実装者がどの版で適合性を試験するのか。著者たちはIETF 126前の公開討論で、RFCがGitタグ、IANAエントリ、別の対象のいずれを指すべきか、「最新」ポインターが何を返すべきか、どの版を実装対象にすべきかを問うた。IETF 126のOPSAWG議事録はGitHub、IETF管理環境、IANA、アーカイブ、復旧について競合する見方を残し、予定時間が尽きてリスト討論へ続いたことを示す。これは未解決の設計論点であり、参加者の不当行為を意味しない。

8月25日の要約は、実験ではGitHubリポジトリを維持し、issueやpull requestを受け付け、隔週会合の意見をメーリングリストに要約し、異議があればマージ前にさらに議論すると述べる。そしてIANAの間接参照モデルを確認したとする。この資料は重要だが、形式を大きく見せてはならない。これはプロジェクト会合の帰属付き要約であり、正式なWGコンセンサス・コールでもIESG判断でもない。RFC 8874はGitHubでの作業に特別な地位を与えず、WGの合意決定はメーリングリストで確認されるべきだとする。会合は案を前進させても、その確認を置き換えない。

同じ時点の草案には「本文書にはIANA actionsはない」とある。RFC 8126では、明示的なno-action節は、その文書についてIANAに行わせることがないという意識的な判断を記録する。後の版が有効なIANA指示を追加することを妨げるわけではない。しかし会合の方向を、既に実行可能なIANA依頼であるかのように扱うことはできない。

PR49は台帳の完成ではなく、台帳の設計案である

PR49は期限時点でオープンかつ未マージだった。そこではYANG File/Module References registryを置き、permanentとproposedの状態、正確なURL、SHA-256、管理連絡先、IESGその他の承認経路を扱う案が示される。ハッシュはバイト列を固定し、状態は候補と現行を分け、連絡先は保守の所在を表し、承認経路は誰が内容判断を担うかを表す。この分離は合理的である。

だが、提案された列は現行のIANA規則でも登録行でもない。現在のIANA YANG Module Names registryはRFC Requiredで、名称、ファイル、名前空間、prefix、参照、注記などを示す。VELOCE案のハッシュ、承認状態、管理責任者、決定受領記録の列は現時点で見当たらない。従って、IANAがその新レジストリを作った、方針を受け入れた、またはVELOCE版を取得したとは言えない。

ここで守るべきは動詞の主語である。著者が変更を提案する。査読者と保守者がリポジトリで処理する。WGが合意を形成する。指定されたArea DirectorまたはIESGが承認する場合がある。IANAが限定された登録を実行する。登録行が版の同一性を残す。タグ、マージ、合意、承認、登録は互いに役立つ証拠になり得るが、一つが他を自動的に証明するものではない。

これは速度への反対ではない。第00版はブランチ先頭を禁じ、粗い合意の手続を残している。PR49もIANAに無制限の裁量を与えるのではなく、ハッシュと承認経路を置こうとしている。早いWG版が未解決の議論を完全に反映していないことも自然である。問題は、未完成の橋を完成した制度として読んだり、逆に未完成だから無価値と扱ったりすることにある。

決定からポインターまでの薄い受領記録

VELOCEに必要なのは、各後続変更について公開で結べる一枚の記録である。そこには少なくとも次を置ける。

  1. 変更が主張する規範的効果と、管理するWG;
  2. リスト上の合意コール、開始・終了時刻、重要な異議、議長の処置;
  3. 登録を求める正確な草案または承認文と承認主体;
  4. リポジトリURL、固定コミット、タグ、SHA-256;
  5. 著者、査読者、マージ者、承認権者を分けた記録;
  6. IANAへの依頼者と時刻、取得URL、取得バイト列、検証結果;
  7. 前後の登録行、有効時刻、置換関係;
  8. 公開時版、最新承認版、実装の適合性試験対象版;
  9. 互換性、試験、ミラー、バックアップ、復旧試験、撤回と巻戻し; および
  10. 登録とは別に保つ実装・運用採用の証拠。

この記録は新しい拒否権ではない。建設的な会合を合意と呼び替えるものでもない。後で行われた正式確認を接続し、IANA取引を内容判断へ変えないためのものだ。承認権者が候補を現行にしてよいと決め、IANAは合意済み方針に従って承認済み成果物を検証・記録する。Heng LuのNote 63は、VELOCEやIANAの事実ではなく制度設計の視角を与える。記録者は決定を監査可能にできるが、決定者を演じてはならない。

適合性にも同じ区別が要る。RFC 9907は今なお公開済みBCPであり、規範的YANG記述をRFC本文の規範文と同様に扱い、新規・更新モジュールの登録をIETF XMLとYANG Module Namesに求める。VELOCEは違う保守方式を提案できるが、期限時点でこの基準を置き換えてはいない。RFC参照版、最新承認版、IANA現行版、試験済み版が一致する場合もあるが、一致を推定してはならない。

出典

  1. OPSAWG charter
  2. VELOCE Datatracker record
  3. IETF 126 OPSAWG minutes
  4. Pull request 49
  5. Heng Lu Note 63
  6. IANA YANG parameters
  7. OPSAWG VELOCE adoption result
  8. VELOCE pointer discussion
  9. 25 August VELOCE call summary
  10. draft-ietf-opsawg-veloce-yang-00
  11. RFC 8126
  12. RFC 8874
  13. RFC 8875
  14. RFC 9907