要約

  • BCP 14のMUSTは「その仕様における絶対的な要求」であり、文書、主体、条件、適用領域から切り離された命令ではない。
  • RFC 8174によれば、文書が所定の文言でBCP 14を呼び出し、語がすべて大文字で書かれている場合に限って特別な意味が有効になる。
  • 任意採用と厳格な適合は両立する。標準を採用しない選択はあり得るが、該当プロファイルへの適合を主張しながら適用されるMUSTを任意扱いすることはできない。
  • 再現可能な所見には「規範文の受領票」が要る。文書と版、地位、完全な文、主体、トリガー、要求動作、例外、適合対象、試験証拠、外部採用文書を保存する。

赤いセルが証明していないこと

試験表の役割は、多数の結果を一覧できるようにすることだ。ところが一覧性のために、証明に必要な情報まで削られることがある。RFC番号とMUSTが並べば根拠が強そうに見える。実際には、節番号も入力も設定も期待結果もなければ、第三者は同じ試験を実行できない。

規範文は、特定の文書が、特定の主体に、ある状態の下で、ある動作または禁止を求める関係である。監査所見にするには、さらに対象ビルド、機能選択、運用状態、観測結果を結び付ける必要がある。関係を落とした短い行は、精密になったのではない。反証可能性を失っただけである。

この欠落は権限の出所も曖昧にする。IETFは技術文書を作成し、レビューし、公開する。実装者は機能を選び、適合性を表明する。運用者は設定して展開する。調達者は受入条件を定める。規制者や契約当事者は、自らの権限でRFCを別の義務へ組み込む場合がある。MUSTだけを残すと、別々の決定が、IETFによる一つの命令に見えてしまう。

BCP 14が絶対とする範囲

RFC 2119は、MUST、REQUIRED、SHALLを「その仕様における絶対的な要求」と定義する。MUST NOTとSHALL NOTは、その仕様における絶対的な禁止である。「その仕様における」という限定は飾りではない。強制力の所在を技術文書の内部に置いている。

SHOULDは単なる弱い命令ではない。正当な例外はあり得るが、逸脱の含意を十分に理解し、慎重に比較する必要がある。MAYは本当に任意である一方、任意機能を備える実装と備えない実装との相互運用は確保されなければならない。BCP 14は工学的な互換性と危険を整理する語彙であって、制度的な格式を示す順位表ではない。

RFC 2119は書き手にも制約を課す。命令語は、相互運用のために必要な動作、または害を生む可能性があるため抑制すべき動作に、慎重かつ限定して用いる。相互運用が特定の実装方法を必要としないのに、その方法を強制するために使ってはならない。したがって、実装者が絶対要求を守る責任と、仕様作成者が共同制約の必要性を明確にする責任は対になっている。

RFC 8174は、大文字と小文字の曖昧さを整理した。BCP 14の定義が適用されるのは、すべて大文字の語であり、かつ文書に所定の解釈文言がある場合である。小文字の「must」も通常の文章として強い指示になり得るが、単語が似ているだけでBCP 14の専門用語にはならない。

検索結果を要求一覧へ変換する前に、二つを確認すべきだ。文書はBCP 14を有効化しているか。引用箇所は有効化された大文字の形か。単純な全文検索では、どちらにも答えられない。

文法上の主語は管理項目である

次の架空の四文を比べると、主語の役割が分かる。

  • 送信者は送信前に不正なオプションをMUST破棄する。
  • 受信者は未知の選択フィールドをMUST無視する。
  • プロファイルAへの適合を主張する実装は診断カウンターをMUST公開する。
  • 運用者は拡張機能を有効化する前に一意のローカル値をMUST設定する。

命令語は同じでも、責任を負う主体は毎回異なる。受信者が結果のパケットを処理したという理由だけで、送信者向け要求の違反者にはならない。プロファイルAを主張していないライブラリを、そのプロファイルの対象として試験することもできない。実装要求を運用者へ、運用前提を実装へ、根拠なく移し替えてはならない。

発動条件も文の中心である。「拡張Xがネゴシエートされたとき」は要求を作動させる。「相手がYを供給した場合を除く」は例外を区切る。「ローカルリンクを越えて転送するパケット」は領域を限定する。条件を作らない試験は、システムが何もしないべき時に何もしなかったことを、誤って失敗と判定し得る。

MUST rejectだけを抜き出し、「厳格プロファイルをネゴシエートした受信者」を捨てれば、主体、出来事、対象集合が変わる。単語は正確でも、システム上の命題は別物になる。

キーワードは文書の地位を語らない

MUSTが含まれるだけでは、RFCがどのような制度的文書か分からない。RFC 7841がステータス、ストリーム、レビューの背景を示すのは、読者が文書をどう評価すべきか理解できるようにするためだ。Standards Track、Best Current Practice、Experimental、Informationalは、大文字を共有しても同じ地位にはならない。

もちろん、Standards Track以外の要求が無意味になるわけではない。実験プロトコルでも、二つの試作実装が正しいメッセージを交換するには厳密な形式が必要である。情報提供目的のフォーマットでも、それを採用した実装に必須フィールドを定められる。規則は設計の内部で絶対であり得るが、文書が直ちにInternet Standardになったり、全ネットワークが採用者になったりはしない。

現在の系譜も確認する。更新、廃止、正誤表は、今日の評価で参照すべき文章に影響する。ただし、すべてを機械的に最新版へ置換すればよいわけではない。製品がどの版を表明したか、契約がどの版を採ったか、展開系がどの構成を動かしているかを先に確定する。

適合性と適用性を一つの問いにしない

RFC 2026は、Technical SpecificationとApplicability Statementを区別する。技術仕様は、プロトコル、サービス、手順、慣行、形式を記述し、範囲と想定領域を示す。それだけで、インターネット上のあらゆるシステムがいつ利用すべきかを決めるものではない。

そこで、評価には二つの問いがある。第一に、その仕様を実装する、またはそのプロファイルを主張するシステムは、適用される規範文を満たしたか。第二に、そのシステムはそもそも仕様やプロファイルを実装する義務を負ったか。MUSTは第一問に厳格な答えを与えながら、第二問には答えないことがある。

第二問の答えは別の記録に存在する。製品の適合宣言、ネットワーク設計、調達契約、組織方針、法令などである。いずれも重要な結果を生み得るが、決定者、対象、版、根拠を独立して残す必要がある。契約がRFCを採用したなら外部義務は実在する。ただし、その義務を作ったのは契約権限であって、大文字の形ではない。

採用する自由と適合を語る責任

RFC 3935は境界を端的に述べる。ある行為をIETF標準に従って行うなら、そのやり方を標準が示す。IETFが使用を命令し、取り締まるという意味ではない。共通規則を実装する製品同士の相互運用が価値となる。

RFC 6852は、現代の標準化に自発的採用を位置付け、実装と展開によって市場での成功が示されるとする。IETFの現行プロセス説明も、IETFの成果を任意採用される標準を定義する技術文書として説明する。

この考え方はMUSTを弱めない。ベンダーはあるプロトコルを実装しないことを選べる。だが、そのプロトコルへの適合を表示したまま、適用される絶対要求を好みの問題へ変えることはできない。互換性集合へ入る決定は自発的であり得るが、集合への所属表示は正確でなければならない。

Heng LuのRunning-Code Primacyは、公開文書だけでは運用実態が生まれないことを示す。実装、検証、展開、利用が、規則の作用と採用主体を明らかにする。Minimum Initial Specification, Localized Future Decision, and Voluntary Adoptionは、共通の決定的な不変条件を保ちつつ、将来の選択を実際の参加者の近くに置く。

この原則を、適合を主張する実装がセキュリティ不変条件を無視する口実にしてはならない。求められるのは、主張を明示し、境界を定め、動作で検証することだ。採用しないことと、採用後に適合しないことは別の事実である。

規範文の受領票

監査に立ち会わなかった人でも所見を再構成できるよう、少なくとも次を残す。

項目 何を証明するか
文書と版 評価基準として選択した正確な本文
現行地位と系譜 公開背景、更新、廃止、正誤表
BCP 14の有効化 大文字キーワードが専門的意味を持つこと
節と完全な文 検索断片ではなく要求全体
規範主体 送信者、受信者、実装、運用者など
トリガーと前提 要求を発動する出来事と状態
要求動作 観測できる行為または禁止
例外と回復境界 逸脱、縮退、再試行、失敗が許される条件
適用領域と適合対象 製品、プロファイル、機能、環境
試験と証拠 入力、設定、トレース、期待値、実測値
展開識別 ビルド、版、オプション、運用状態
外部採用文書 独自の義務を作る契約、方針、法令
所有者と終結 修正担当、再試験、所見を閉じる条件

この受領票は両方向に効く。監査側が要求を対象外の主体へ広げることを防ぎ、適合を主張した側が「標準は任意だ」と逃げることも防ぐ。同じ証拠設計が、権限の過剰と責任の回避を同時に抑える。

省略が作る五つの見せかけ

主体の置換では、実装者への要求が顧客の運用義務へ、送信者への要求が受信者の欠陥へ移る。大文字だけが残り、責任の移動を隠す。

条件の削除では、ネゴシエーション後や障害経路だけで必要な動作を通常経路で試し、起きないことを違反とする。

地位の置換では、ExperimentalやInformationalの正確な規則を、全インターネットが採用済みのStandards Track義務として説明する。

採用主体の洗浄では、RFCを選んだ調達者や規制者が記録から消え、地域の判断がIETFの命令に見える。これはThe Multi-Stakeholder Mirageが論じる委任のずれの縮図である。正当な技術プロセスが、実際に行使した権限を越えて語らされる。

書類上の適合では、本文との対応表が試験の代わりになる。期待動作は転記されていても、出荷された実装が何をしたかは不明である。

出典

結論

BCP 14が有効な文書で、指定主体に指定条件の下で適用されるMUSTは絶対的な適合要求である。その強さを尊重するからこそ、単語だけを任意の製品に貼るべきではない。

システムを裁く前に、文を復元する。主体、トリガー、地位、範囲、適合対象、試験を示す。別の機関がRFCを採用したなら、その機関と文書も記す。この連鎖がそろって初めて、赤いセルは借り物の権威ではなく監査所見になる。