要約

  • 1998年のRFC 2418は、ワーキンググループの判断基準をラフコンセンサスとし、51％の多数だけでは足りないと明記した。
  • 当時の指針ではハミング、挙手、合意した別の方法が認められたが、どれも自動的な決定手段ではなかった。
  • 2014年に情報提供文書として出たRFC 7282は、ハミングが匿名投票のように扱われる傾向を批判し、議論の開始点にすべきだと説明した。
  • 技術的な異論を検討し、残る異論が結論を変えない理由を示すことが求められた。
  • RFC 7282は既存の原則を説明する文書で、IETFの手続きを変更したり、新たな拘束力ある規則を設けたりしていない。

会場の反応は結論ではない

ワーキンググループは、提案への支持の様子を把握する必要があった。対面会合では、議長が挙手の代わりに賛成・反対のハミングを求めることがある。音は会場全体の傾きを示すが、票を数える作業にはしない。意見の割れや関心の強さは見えても、参加者がその意見に至った理由や、技術的な異論が解決したかまでは分からない。

この違いは2014年より前から指針にあった。1998年のRFC 2418は、技術的な合意をワーキンググループの「ラフコンセンサス」で判断するとした。51％では足りないとも明記し、到達したかどうかは議長が判断すると説明する。また、メールの量だけを合意の指標にしてはいけない。少数の参加者が議論の大半を投稿することもあるからだ。メールリストは、時間や移動の負担がかかる会合より広い関心層に届く、とも記している。

2014年のRFC 7282は、原則と儀式の間に生じたずれを取り上げた。著者のPete Resnickは、参加者がハミングを秘密投票や議論を打ち切る近道と誤解する状況を指摘した。ハミングの役割は、なお解決すべき問題を話し合うきっかけになることだ。声が大きい側が、そのまま技術的な勝者になるわけではない。

異論をどう扱うかが中心だった

RFC 7282は、賛成者の数ではなく、未解決の問題に注意を向ける。議長は、何が提案を受け入れられなくしているのかを尋ね、本当の技術的欠陥なのか、好みの違いなのか、検討済みのトレードオフなのかを確かめる。すべての異論を採用する必要はない。しかし内容を理解し、判断の理由を示す必要がある。

議長は機械的な集計係でも、無制限の個人的拒否権を持つ裁定者でもない。グループの技術目標を把握し、異論を評価し、理由を要約し、要件が見落とされたときの異議申立てを認める責任がある。大多数が異論を退けても、その検討を省略できない。一方、すでに検討され回答された懸念を一人が繰り返すだけで、作業を永続的に止めることもできない。

以前のRFC 1603とRFC 2418は、グループの感触を得る方法として投票やハミングなどを挙げていた。RFC 7282が疑問を示したのは、そうした信号だけで中身を決められるという考え方だ。挙手、簡易投票、ハミングは議論の輪郭を示せるが、結論は理由、技術要件、議長の判断に委ねられる。

新しい規則を作らなかった情報文書

RFC 7282は意図的にInformationalとして発行された。標準仕様でもBest Current Practiceでもなく、IETFの手続きを変える提案でもない。この位置づけは重要だ。文書は既存の伝統を説明しようとしたのであって、ルールを改訂したりワーキンググループに新しい権限を与えたりしたのではない。

会場の外の手続きも関係する。RFC 2418は、メールリストで扱っていない議題や、そこでの議論から大きく変わった結論を会合で出した場合、リスト上で再確認するよう求めた。RFC 7282も最終判断はメールリスト上で行うものだと説明する。会場は方向を探る場であり、非同期の記録は理由を残し、出席できなかった人にも応答の機会を与える。

手続きの効用と同じくらい、その限界も大切だ。これらのRFCが記録するのはIETFワーキンググループの指針である。誰が参加したか、影響を受ける全運用者が代表されたか、成果のプロトコルが実際に展開されたかを測定したものではない。異論を聞けば技術判断は改善し得るが、プロセスに参加しなかった人々の承認を代替するわけではない。この区別が、会場の信号を設計された用途の範囲に保つ。