要約

  • FANN の議長は draft-dong-fann-problem-statement-00 を WG 文書として採択し、draft-ietf- 名での再提出を求めた。これは作業対象についての処分であり、ネットワーク動作への許可ではない。
  • 草案は動作の協調を追加検討かつ範囲外と明記する。通知はローカルな応答の材料になり得るが、受信者を選び、操作を許し、緩和の成功を証明するものではない。

採択されたのは何か

議長結論は、変わった範囲を正確に示している。呼びかけが終わったこと、個人草案が FANN WG 文書として採択されたこと、著者が別のファイル名で同じ版を提出すること、寄せられた意見を後続版で扱うこと。そのいずれも検証できる手続事実である。解決方式の選定、ルータ設定、トラフィック変更、可用性の保証を表すものではない。

最初の呼びかけも狭い問いだった。グループがこの問題記述を引き受けるべきか、という問いであり、回答期限があった。支持、異論、追加情報の要請、参加意思は、作業課題に関する証拠になり得る。しかし、後に通知を受け、運用データを守り、変更を行い、その失敗を負う組織からの委任状ではない。

現在の文書記録も独自の身分を保つ。Datatracker は draft-dong-fann-problem-statement-00 を active な個人 Internet-Draft とし、IETF の承認も標準化過程での正式な地位もないとする。議長が後継名を求めたことは、個人版、将来の WG 版、後続の決定、RFC を同じ事実にしない。どの版が呼びかけられ、どの版が再提出され、どの版が審査され、後に何が決まったかは、別々に追える必要がある。

通知は、それが促すかもしれない操作ではない

問題記述は最も重要な技術的境界を自ら引いている。対象はネットワーク状態の高速通知である。パケット損失の削減や速い緩和は通知を消費する動作の結果になり得るが、通知機構の目標や要件ではない、とする。情報が届くこと、情報を解釈すること、実系を変えることは三つの出来事である。

通知がミリ秒で届いても、問いは残る。誰が発信したのか。誰が処理できるのか。観測の範囲と確度は何か。どのローカル規則が動作へ結び付けるのか。どの操作が戻せるのか。部分導入で期待と異なる挙動が出たとき、誰が自動化を止めるのか。誤った経路変更、保護動作、負荷移動の損失を誰が負うのか。問題の採択は、これらを損失負担者の代わりに答えていない。

草案は動作協調の機構を今後の研究とし、本文の外に置く。特定の場面で受信者は設定またはシグナリングで決まり、役割や関心によって購読することもある。同じ通知を二つの受信者が受けても、同じ権限を得るわけではない。責任、契約、許容リスク、ロールバック能力が異なるからである。「ネットワークが反応する」という語で埋めるべき空白ではなく、実際の統制がある場所だ。

したがって通知を命令として扱ってはならない。メッセージ内の推奨にもローカルの受入規則が要る。別ドメインの発信者は、問題記述が採択されたことで信頼を得ない。もっともらしい観測はトラフィック変更を許可しない。一つの場所で得られた改善は、将来のプロトコルの属性にならない。それぞれの移行には、固有の責任者、根拠、可逆経路が必要である。

憲章は作業範囲を定め、運用権限を渡さない

FANN 憲章は、問題記述、要件、ギャップ分析を WG の作業と関連する成果物の案内として挙げる。これによりグループが問題を扱う理由は分かる。しかし実際のトポロジーで誰がイベントを受けるかを決めず、ドメイン間の信頼関係を作らず、自動化を承認せず、配送目標をサービス水準の約束に変えない。

技術文書も慎重である。安全機構を規定しない一方、将来の解決案が購読の信頼境界、通知源の認可、機微な運用データの保護を考慮すべきだと述べる。部分導入の影響と対応動作の一貫性も評価対象にする。採択後に消える但し書きではない。後続方式、ローカル方針、運用結果を別の記録に保つべき理由である。

重要な変更をする運用者には、採択済み問題記述以上のものが必要だ。評価した版、受け入れるイベント類、送信元の身元と認可確認、受信者の役割、動作規則、頻度制限、抑制、障害時の扱い、観測、ロールバック担当者、見直し条件である。将来の FANN 文書は一部を相互運用可能にできるかもしれない。しかし全てのネットワークのために先回りして承認することはできない。

薄い共通受領記録と、読み取れるローカル決定

共通層は小さくてよい。呼びかけの開始と期限、議長結論、正確な版、後継版があればその名、範囲境界、次の公開決定点を保存する。それで WG が何に取り組むことを決め、何をまだ決めていないかを確認できる。

横にはローカル記録を置く。通知源、認可規則、方針版、受信者の類、試験環境、観測された配送挙動、動作上限、例外経路、責任者、ロールバック権限を記す。この分離は公開手続の状態がローカル統制の決定に化けることを防ぎ、ローカル動作が IETF の合意だと宣伝されることも防ぐ。

次に見るべき証拠は別々である。最初の draft-ietf-fann-、呼びかけ意見の処分、協調モデルを明記する要件または解決案、送信元認証と受信者認可の規則、部分導入の挙動、そしてその後続文書への WG 判断である。それまでは、FANN は問題を扱うことに合意した、ネットワーク動作の権限はネットワークを管理し結果を負う者に残る、と言うのが正確である。

出典

  1. FANN 議長による採択呼びかけの結論
  2. FANN の問題記述に関する採択呼びかけ
  3. 問題記述の現在の Datatracker 記録
  4. Fast Network Notifications Problem Statement 第00版
  5. FANN 憲章