IETFツールのSLAとUXには別々の時計が要る

要約

SLA案の対象はシステムの性能と可用性であり、Tools Teamの評価や、作業の予定・計画は明確に対象外である。
UX協議は、画面、アクセシビリティ、アクセス制御、クライアント要件、Web、CLI、プラグイン、API、MCP、オフライン利用を扱い、システム性能は並行するSLA協議に委ねる。
各意見について、対象サービス、指標、除外条件、決定権者、実装責任者、優先順位、時期、報告先を記した版管理付きの公開受領記録を作れば、二つの状態を混ぜずに相互参照できる。

2026年9月17日、IETF LLCはIETFツールの二つの側面について意見募集を始めた。締め切りはいずれも10月12日で、LLC BoardとExecutive Directorへの非公開回答、またはtools-discussでの公開討議が選べる。入口が同じでも、その先の判断は別物だ。

SLA文書は観測できるサービス状態を定義しようとしている。可用性、Web応答、メール遅延、インシデント対応の目標を掲げ、サービス階層、部分劣化の重み、除外条件、月次報告と年次見直しを示す。「best efforts」だった運用に、検証可能な期待値を置く試みである。

一方、UX文書が問うのは利用経路だ。Web、コマンドライン、プラグイン、API、Model Context Protocol、オフライン利用を並べ、アクセシビリティ、認証、クライアント要件、共有可能なURL、個別設定について意見を求める。性能は別協議が扱うため、この文書の外に置かれている。

この線引きは、結果から何を言えるかを決める。可用性の値は、指定した測定点と期間におけるサービスの状態を示せる。しかしチームの働きぶりを直接評価したり、開発の順番を決めたりはしない。UX上の必要性を認めても、関連サービスが既に目標を満たしたことにはならない。

SLA案は、Tools Teamの性能と作業のスケジュール・計画を明示的に除外する。議論の必要性まで否定してはいないが、サービス指標からその結論を出すことはできない。

対象範囲の中では設計が細かい。自動監視を可用性の基準とし、全面停止を1、重大な劣化を0.5、軽微な劣化を0.25、見た目だけの不具合を0とする。重要度に応じてサービスを分け、Web応答はサーバー側で測る。クライアントの描画、利用者のネットワーク、定義された外部依存は含めない。

除外条件も結果の一部だ。計画保守、第三者障害、不可抗力、利用者の端末や回線、意図的なセキュリティ対策は計算から外れる。緊急保守や、悪用・過剰トラフィックによる停止は自動的には消えない。率だけを示して分母と除外理由を隠せば、責任の比較は成立しない。

未達時の措置も罰金ではなく、検証と改善である。小規模な分散チームが通常時間帯に働き、24時間運用センターではないという前提も明記される。コミュニティが選ぶのはサービス期待と投資の組み合わせであり、人事評価ではない。

監視データは七日間しか保存されず、定期的な書き出しもないため、過去分析ができないという注意もある。これは長期測定を整える理由であって、現在のツールが故障している証拠ではない。

ツールは有機的に発展し、多くのUI判断を開発者が担ってきた。新しいrfc-editor.orgでは専門家を活用したが、ツール群全体について意見を集め、計画へ反映する正式な仕組みはこれまでなかった。

ここで問われるのは選択だ。CLIやオフライン対応を増やすか、JavaScript依存をどこまで認めるか、シングルサインオンと自己管理をどこまで広げるか、AIやMCPからの利用を想定するか、アクセシビリティ専門家をどこで使うか。いずれも応答時間の閾値ではない。

ただし運用上の帰結はある。オフライン機能には同期データやコンテナ保守が要るかもしれない。認証は新たな依存を増やす。APIやMCPは負荷を変え、キーや制限の根拠になり得る。帰結は測定すべきだが、測定値が製品判断を代行してはならない。

IETF LLCのCommunity Engagement Policyは、意見を追跡し、採用するか不採用理由を明示し、決定後にコミュニティへ伝えることを既に求めている。二つの協議では、この処理を相互検証できる形にする価値がある。

重要な意見ごとに、内容、対象サービスまたは利用形態、指標と測定点、除外条件、決定権者、実装責任者、優先度と時期、将来の報告・見直し先を版管理して公開する。SLAとUXの関連項目はリンクするが、状態は別に保つ。

会議中の安定したオフライン利用を例にすると、UX欄は採用・不採用・保留と判断者を示す。サービス欄は配布データ、同期点、コンテナなどを特定し、測定場所と外部依存を記す。ニーズの採用は目標達成ではなく、良好な可用性もオフライン経路の完成を意味しない。

版管理は順序も守る。UX判断が予算より先になることも、新しい負荷が後からSLA指標を変えることもある。変更ごとに日時、権限、残る作業を記録すべきだ。

これは全作業を一つに集める待ち行列ではない。システム測定、利用判断、計画という別の責任の受け渡しを見せる記録である。