要約

  • APNICは2026年9月10日のOpen Policy Meetingで7件の提案を議論すると告知した。会議報告は7件すべてを三つの状態に整理している。
  • prop-169とprop-170はコンセンサスに達した。prop-164、prop-168、prop-171は達せず、メーリングリストへ戻る。prop-165とprop-172ではコンセンサス確認自体が行われなかった。
  • 確認なしは不成立ではない。提案状態票に、対象版、確認を行わなかった理由、次の行動、公式ページの更新時刻を残すべきだ。

7件を三つに分ける動詞

APNIC 62開幕前の案内は、9月10日のOpen Policy Meetingで扱う提案を7件と明記した。prop-164、prop-165、prop-168、prop-169、prop-170、prop-171、prop-172である。

会議後の報告にも7件すべてが登場する。ただし、二つの箱には押し込まれていない。prop-169とprop-170はコンセンサスに「達した」。prop-164、prop-168、prop-171はコンセンサスに「達しなかった」ため、Policy SIGのメーリングリストに戻して議論を続ける。そしてprop-165とprop-172については、コンセンサス確認を「行わなかった」と別に記した。

最後の一文は、結果欄の空白ではない。肯定・否定いずれかの結果を生むはずの手続イベントが起きなかった、という積極的な記録である。

この区別は評価されてよい。粗い会議要約なら、前に進まなかった提案をすべて「不成立」にまとめただろう。APNICの報告はそうしていない。したがって、prop-165とprop-172が否決されたと書く根拠はない。

一方、公開された状態遷移はそこで途切れる。確認を行わなかった理由、どの版またはどの議論条件が判断対象だったのか、次の場はどこかが示されない。証拠を固定した時点で、両提案の個別ページには会議前の「For Discussion at APNIC62 OPM」という状態が残っていた。

コンセンサスは空気から読み取れない

APNICの説明によれば、提案に反対する参加者は異議の内容を示し、コミュニティーはその異議を解消するか、修正で乗り越えられるかを検討する。異議が解消された、または十分に考慮され、利点が不利益を上回ると共同体が判断した地点がラフ・コンセンサスである。全員一致は要件ではない。

この仕組みでは、コンセンサス確認は特定可能な手続行為だ。議長が、特定時点の特定テキストについて、共同体の状態を確認する。肯定と否定は違う結果を生むが、どちらも確認が実施されたことを前提とする。確認がなければ、拍手、発言者数、チャット、会場の雰囲気から結果を逆算してはならない。

これは言葉尻の問題ではない。「達しなかった」3件について、報告は次の行き先まで書いている。メーリングリストで議論を続けるのである。「確認なし」の2件には同じ記述がない。可決と否決しか受け付けないデータベースなら、2行を誤って埋めることになる。ニュース記事が「敗れた」と書けば、同じ誤りを文章で行うだけだ。

過去の履歴を今回の理由として流用することもできない。prop-165はAPNIC 60でコンセンサスに達せず、APNIC 61で取り下げられ、別版としてAPNIC 62に戻った。むしろこの履歴は、同じ提案が会議ごとに異なる状態を取ることを示す。9月10日に確認がなかった理由ではない。prop-172はもっと新しく、会議前に複数版と事務局影響評価が公開されたが、その短い履歴にも理由はない。

二つについて共通して言えるのは、報告の文言だけである。コンセンサス確認は行われなかった。

短い会議報告にも役割がある

会議報告は議事録ではない。全体会合、各SIG、選挙、技術セッション、コミュニティー活動を、全日程を追わなかった読者にも届ける。すべての発言を再録すれば、要約としての役割を失う。Policy SIGの会場にいた人には、ウェブページに載らなかった説明が聞こえていた可能性もある。

これが現行報告に対する最も強い擁護である。理由の記載がないことは、不正操作や手続違反の証拠ではない。テキスト修正が必要だった、著者の作業を待った、時間が足りなかった、前提資料が不足した、別の会合へ移したなど、確認前に止める正当な理由は考えられる。ただし、これらは理由カテゴリーの例であり、prop-165やprop-172の事実ではない。

問題はもっと狭い。ウェブサイトは、遠隔参加者、数か月後に調べる運用者、政策状態を読むシステムにとっての長期記録でもある。報告の一文は、次の公式状態へ接続しなければならない。そうでなければ、理解は出席者の記憶や後日のメーリングリスト検索に依存する。

個別ページに残る会議前ラベルも、先送り、撤回、失敗、継続の証拠にはならない。会議前には正しかったが、議論後に何が起きたかを答えていない。会議報告と提案台帳が、遠隔の読者にも追える形でまだ接続されていないことだけを示す。

「確認なし」を正式な状態にする

修正のために会議報告を長い議事録へ変える必要はない。各提案について、短い状態票を1枚作ればよい。提案番号、対象となった正確な版、会合、時刻を記し、コンセンサス確認を実施したかを独立した項目にする。

実施した場合は結果と次の段階を記す。実施しなかった場合は、限定された手続上の理由、議長説明の引用またはリンク、次の会合や作業、提案ページを更新した時刻を残す。

理由カテゴリーは会場の支持を創作してはならない。たとえば、テキスト修正、著者作業待ち、議事時間終了、前提証拠待ち、明示された別会合への移動である。同期の記録が支えるカテゴリーだけを用い、理由が保存されていなければ「記録なし」とする方がよい。

機械向けの構造も単純である。確認実施：はい／いいえを先に置き、「はい」のときだけ結果欄を要求する。「いいえ」であれば確認なしが完全な状態であり、失敗へ自動変換すべき欠損値ではない。

これはTheo Marchによる統制案であり、APNICが導入を発表した機能ではない。議長の判断を置き換えず、投票を要求もしない。決定が行われたことと、決定イベントがまだ起きていないことを、同じ精度で保存する。

出典