要約

  • draft-nottnick-ietf-decisions-01 は、作業部会がIETF全体のより広い決定を覆すことはできない一方、その決定が自らの状況に適用されるかを判断できると述べる。
  • 同草案は、適用外という判断が配備環境についての仮定に依存しがちであり、その種の仮定は後年しばしば誤りと判明すると警告する。
  • 01版はRFC系列、担当Area Director、Last Call、IETF合意を持たない個人Internet-Draftである。提案された手続は現行BCPではない。
  • 「閉域」「単一管理」といった名称だけでは環境を証明できない。到達性、管理権、利用者、ゲートウェイ、依存関係、実装、変更統制を検証可能な条件に分解する必要がある。
  • Daniel Kadeは、上位原則、当該判断、環境条件、証拠、反証条件、責任者、見直し契機、後継判断を結ぶ「適用前提レシート」を提案する。
  • これは免除証書でも配備承認でもない。日付のある判断が、事実上の境界を失った後も恒久的な例外として流通するのを防ぐための記録である。

権限の線引きより難しいのは、適用範囲の線引きだ

『Making Decisions in IETF Working Groups』で最も重い一節は、権限の説明の途中にある。草案はまず、作業部会の合意はチャーターの範囲内でなければならないとする。続いて、より広いIETFレベルですでに決着した事項を、部会内の合意だけで退けることはできないと線を引く。

ここまでは明快だ。難題は、その原則が個別案件に「適用されるか」である。

一般的なIETF方針は、対象となる領域では拘束力を持ちながら、目の前の設計が本当にその領域に入るのかという問いを残す。01版は輻輳制御を例に挙げる。プロトコルが一般原則の及ばない環境だけに配備できるなら、作業部会は適用外と判断し得る。理由は明示して記録し、異議と不服申立ての余地も残すべきだという。そして草案は、そこで止まらない。こうした判断は通常、配備環境についての仮定に依存し、その仮定は時の経過とともに誤りだと分かることが多い、と注意する。

「管理環境」と書けば例外が発生するわけではない。チャーターが上位の合意を廃止する権限を与えるわけでもない。これは原則と具体的な領域の関係についての解釈であり、有効性はプロトコル本文の外にある事実にかかっている。

文書は固定できる。環境は固定できない。その非対称性が統治問題の中心にある。

この草案は現行手続を説明する権威ではない

内容を使う前に、文書自体の地位を限定しておく必要がある。Datatracker上で01版は有効な個人Internet-Draftである。RFC系列、担当Area Director、telechatは記載されず、状態はI-Dが存在するという段階にとどまる。表紙がBest Current Practiceを目標とし、成立すればRFC 2418を更新すると述べていても、それは著者の提案であって既成事実ではない。

したがって、公開済みのBCP基盤としてRFC 2418があり、合意形成を論じるInformational文書としてRFC 7282があり、標準化手続と不服申立ての枠組みとしてRFC 2026がある。01版は、現在検討されている手続案を精密に表現した資料として有用だが、作業部会が今日すでに新しい規則を実施できる根拠にはならない。

これは形式論ではない。権限を扱う文書ほど、分かりやすく新しいというだけで借り物の権威を帯びやすい。草案の主張を引用するなら、草案の状態も同じ記録に置くべきである。

「環境」という一語には、検査されていないモデルが入っている

技術者は効率のために「閉域網」「単一管理者」「データセンター内部」「実験室」「管理端末」「インターネット外」といった語を使う。設計会議のたびにシステム全体を再説明しないための便利な圧縮だ。

しかし、一般原則を適用外とする根拠に使うなら、圧縮語のままでは足りない。少なくとも次のような命題へ展開する必要がある。

  • 通信は公共網や独立した管理境界を越えられない。
  • すべての端点が一つの変更権限に継続して従う。
  • 外部サービスへ変換するゲートウェイがない。
  • 利用者集団と脅威モデルが限定されている。
  • 依存先が上位原則の対象となる条件を持ち込まない。
  • 実装は想定領域外での動作を拒否する。
  • いずれかの条件が崩れたことを運用者が観測できる。

プロトコル名が変わらなくても、条件は変わる。クラウド中継が追加され、隔離された制御面が相互接続され、ライブラリが別用途へ転用される。単独運用が連合運用になり、デバッグ口が統合面になり、当然あるはずだった境界検査を実装が省くこともある。

その全期間を通じて、古い合意記録は一字も変わらないかもしれない。だから記録には保管だけでなく、寿命の設計が要る。

個別判断を携帯可能な免除へ変えてはいけない

三つの決定主体を混同してはならない。

第一に、上位原則そのものがある。例えばRFC 7258は、広範な監視を攻撃とみなすIETFの技術的合意を記録し、設計者に関連性と対応を説明するよう求める。RFC 2914は輻輳制御原則を記録する。新草案が作業部会の限界を説明する際に指しているのは、この種類の決定である。

第二に、作業部会は定義された条件のもとで、その原則が特定の問いには適用されないと判断できる。これは原則と領域の対応関係についての判断で、原則の取消しではない。

第三に、具体的な実装や運用が今なおその領域内にあるかは、後の実装者と運用者が確かめる。作業部会は将来のトポロジー、製品統合、テナント構造、ゲートウェイをすべて審査できない。標準化時点で正しい判断でも、未知の配備に保証書は出せない。

この三層を「IETFが決めた」の一言へ畳むと、例外が移動を始める。ある設計のための文が製品説明に引用され、セキュリティ審査へコピーされ、名称だけ似た別環境で再利用される。やがて、条件が現在も成立するという証拠の代わりに、過去の権威が置かれる。

稼働実装は前提を試せるが、永続化はできない

RFC 7942は、Internet-Draftの著者が既知の実装を開示する仕組みを示す。これは有効な材料になり得る。実装が境界を強制し、未対応モードを拒み、特定のトポロジーで期待どおり動くことを示せるからだ。相互運用試験は、設計時に見えなかった前提も露出させる。

同時にRFC 7942は、実装情報には時間依存性があると明記する。提案された実装状況の節は通常RFC化の前に削除され、継続的な情報は外部で維持する必要があるかもしれない。恒久的な認証とは正反対である。

実装状況が証明できるのは、ある日付に、特定の実装について、何が報告されたかまでだ。すべての実装が同じ防護を持つことも、配備時に防護が有効であることも、周辺環境が閉じたままであることも保証しない。稼働コードはモデルを検査する証拠だが、周囲の世界を永久に定義するものではない。

適用前提レシートに残す九項目

実用になる最小記録は、九つの要素を結び付ければよい。

まず、上位原則の文書、版、該当節、公開状態を明記する。次に、ローカルな判断を特定する。問い、提案のスナップショット、判断日、合意を認定した者である。後の編集者が、実質的に変わった設計へ古い結論を無記録で移してはならない。

三番目に環境名を検証可能な条件へ分解する。四番目に各条件の証拠を結ぶ。実装挙動、試験結果、配備図、管理上の制約、既知のゲートウェイ、観測された運用限界などだ。機密情報は保護できるが、公開記録にも、どの種類の境界が論証を支えたか分かる輪郭が必要になる。

五番目は反証条件である。新しいゲートウェイ、複数運用者、インターネット到達性、脅威モデルの変更、強制検査の欠落が前提を崩すなら、先に書いておく。六番目は権限で、合意認定者、用いたチャーター解釈、不服申立て先を残す。

七番目は公開後の監視責任者だ。文書の編集担当と環境の監視担当は同じとは限らない。八番目は見直しの契機で、期日、新しい配備類型、プロトコル拡張、実装報告、事故、実質的な新情報を指定する。九番目は系譜である。後継判断は旧判断を参照し、当時なぜ合理的だったか、今どの事実が変わったかを残す。

巨大なコンプライアンス基盤は必要ない。決定記録に結び付いた短い表でもよい。重要なのは条件文を見える形へ戻すことだ。すなわち、この時点で、この証拠により、これらの条件が成立したため、上位原則を適用外と判断した、という文法である。

期限が切れるのは外部前提への信頼である

失効日という語は、日付が来るたびに技術論争を最初からやり直す制度だと誤解されやすい。提案はそうではない。

期限を設ける対象は、外部前提を未検査のまま信頼できる期間である。環境境界が構造によって強制され、その構造が変わっていないという証拠があれば、技術選択を再審議せず更新できる。プロトコルが想定領域の外へ出たなら、主張を狭め、緩和策を付け、上位原則を所有する場へ説明を求め、必要に応じて当該判断を再開すればよい。

歴史上の判断は削除しない。事情が変わっても、当時何が合理的だったかは残る。終わらせるべきなのは、その判断が未審査の新環境を支配する力である。

証拠の限界

確認した資料には、IETF作業部会が01版を利用して不当な例外を主張した事例はない。BCP 41への言及は個人草案の説明例であり、実際の不正な合意認定、プロトコル障害、不服申立て、利用者被害を示す記録ではない。

また、環境依存の判断すべてを同じ周期で失効させる根拠もない。構造上の条件は長く安定し得る一方、運用条件は短期間で変わる。見直しの強度は、結論を支えた事実が変化する速さに合わせるべきだ。

それでも草案の警告だけで、記録統制を考える理由は十分にある。環境仮定が時間とともに誤りになりやすいのなら、意思決定制度は結論だけでなく、その結論を許した事実上の境界も保存しなければならない。

出典

  1. Making Decisions in IETF Working Groups, revision 01
  2. Datatrackerの文書状態
  3. Datatrackerの改訂履歴
  4. RFC 2418 — IETF Working Group Guidelines and Procedures
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. RFC 8789 — IETF Stream Documents Require IETF Rough Consensus
  7. RFC 2026 — The Internet Standards Process
  8. RFC 8874 — Working Group GitHub Usage Guidance
  9. RFC 2914 — Congestion Control Principles
  10. RFC 7258 — Pervasive Monitoring Is an Attack
  11. RFC 7942 — Improving Awareness of Running Code
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  13. Lu Heng — The Policy Mirror