要約

  • draft-sayre-gendispatch-derivative-06 は活動中の個人 Internet-Draft である。標準化プロセスで使う RFC と Internet-Draft に非派生物の仕組みを限定する案であり、RFC でも採択済みの規則でもない。
  • RFC 5378 は、広い IETF Contribution と、より狭い IETF Document を区別する。現行 IESG 声明は不適合な注意書きの政策上の扱いを述べ、IETF 126 は IPR-WG での追加議論と法律顧問の確認を次の段階として記録した。
  • Daniel Kade は、原本を保持しつつ、分類、適用規則、責任ある役割、行為、再検討経路を別々に示す「投稿状態の受領記録」を提案する。これは法律助言でも IETF の必須機能でもない。

参加の痕跡と文書の地位は違う

標準化の議論には、運用経験、反対意見、修正文、議事録、上訴、正式な草案が同居する。一通のメールが設計上きわめて重要であることは珍しくない。だが、IETF のリストに届いたことだけで、そのメールが作業部会で採用し改訂できる仕様文書になるわけではない。会社のメール基盤が付けた文言も、その基盤に手続全体を決める権限を与えない。

RFC 5378 はこの混同を避ける。Contribution には、Internet-Draft または RFC として出すための提出物だけでなく、IETF 活動の文脈でなされた発言が含まれる。作業部会、リスト、BOF、総会、IESG、IAB 宛ての書面や電子的通信も対象になり得る。他方、IETF Document は IETF 標準化プロセスで使われる RFC と Internet-Draft である。参加チャネルと文書の種類は同じではない。

この区別は投稿者を軽視しない。あるメッセージは実装上の重大な欠陥を発見させることができ、それでも採択対象の仕様ではない。アーカイブは到着した内容を保存できるが、保存しただけで権利の裁定者にはならない。投稿者は留保を記せるが、それで他者の技術的検討を止める委任を受けるわけではない。

RFC 5378 は、IETF が文書を発展・公表するために必要な権利を説明し、専有技術、他の標準化機関の成果の再公表、まだ開発採択前の文書といった限定的な例外にも触れる。重要なのは例外文をすべてのメールに貼ることではなく、どの対象に当たるかを先に確かめることである。

草案は境界を示すが、個別案件を終わらせない

2026 年 8 月 13 日付の -06 は、Datatracker で RFC stream を持たない活動中の個人 Internet-Draft とされ、consensus boilerplate は unknown、IESG 状態は I-D Exists である。提案文は、non-derivative works の仕組みを、標準化プロセスで使われる RFC または Internet-Draft である Contributions に限る。他の RFC 5378 上の権利は維持される。

これは今すぐ RFC 5378 を改めるものではない。特定のメールの帰結を決めず、メールの消失、改変、検閲、不適切な保存を立証せず、草案の読者を法的判断者にもしない。IETF 126 の GENDISPATCH 議事録が示す次の段階は、IPR-WG での追加討議、その後の法律顧問レビューである。差し回しは採択でなく、予定されたレビューは公表済みの見解でない。

2025 年 10 月の IESG 声明も、別の限定された役割を持つ。そこでは、派生権を留保できるのは Contribution が IETF Document であり、かつ狭い状況にある場合だけだと説明される。方針と衝突する注意書きは Contribution では無視され、プロセス所有者は削除を求められる、とする。これは注意書きの方針上の効力を述べるもので、原信を書き換える権限、将来すべての事件の担当者、草案への最終判断を与えるものではない。

原本を残し、状態判断を分ける

避けるべき近道は二つある。第一は、どの footer にも見えない拒否権を与えること。第二は、「無視」を理由に注意書きと処理理由を履歴から消すことだ。適切な手続は、どちらも選ばない。

まず受信対象を残す。安定した識別子、チャネル、受信時刻、完全性 digest、到着時の注意書きへの参照である。保存は有効性の承認ではない。次に、分類対象を記す。メールなのか、特定の Internet-Draft なのか、RFC 本文、上訴、議事録、他の文書へのコメントなのか。さらに、実際に適用した RFC 5378 の条項、IESG 声明、IETF Trust の指示、または採択済み更新を、版と有効状態とともに示す。最後に、権限ある役割がした行為を記録する。適用外と扱ったのか、削除を求めたのか、審査へ送ったのか、再提出を求めたのか、手続行為をしなかったのか。

Daniel Kade は、この結合を投稿状態の受領記録と呼ぶ。公開部分は小さくてよい。内容識別子と digest、日時とチャネル、受信した注意書きへの参照、分類、規則版、責任役割、行為状態、再検討経路、後続の置換判断を含める。保護すべき通信は保護付録に置ける。しかし、機密性は、判断があったか、誰がどの範囲で行ったか、まだ有効かを隠す理由にはならない。

「注意書きを受けた」は「有効」と同じでない。「Contribution」は「採択文書」でない。「規則を適用」は「法律助言」でない。「削除を求めた」は「原文を改変した」でない。「審査へ送った」は「審査済み」でない。この語の境界が、参加者、chair、アーカイブ、法律担当者それぞれの責任を保つ。

日常の発言を法務案件にしない

すべての投稿に記録票は不要である。文書の扱いに実質的影響が出る制限、責任役割からの要請、上訴、または争われた手続行為がある場合に限ればよい。これは参加者の恒久的プロフィール、発言資格、リスト上のライセンス裁判所になってはならない。

Heng Lu の抑制的な区別が役立つ。参加と知見は証拠になり得るが、委任ではない。投稿者は footer によって IETF を統治しない。保存ツールもバイトを持つだけで歴史を統治しない。権利の規則は限定的なプロセス問題を律するのであって、全ての権威を再配分するものではない。

証拠の限界

確認した資料は -06 の採択、RFC 更新、IETF のコンセンサス判断、法律顧問の最終結論を示さない。特定の投稿者、企業、アーカイブの不正も示さない。受領記録は Daniel Kade の編集上の提案であり、IETF プロトコル、参加条件、通信を変更する指示ではない。

出典

  1. RFC 5378 — Rights Contributors Provide to the IETF Trust
  2. IESG Statement on Clarifying Derivative Works Rights
  3. draft-sayre-gendispatch-derivative-06 — Clarification of Derivative Works Restrictions
  4. Minutes: IETF 126 GENDISPATCH
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. Heng Lu — The Multi-Stakeholder Mirage