要約

  • RFC 3113は、可能ならIETF standardを変更せず利用し、IETFの作業を重複させないことを3GPPの基本方針とした。変更が必要なら、該当するIETF working groupかArea Directorへ課題を戻す。
  • liaisonは文書、専門知識、期限情報を運んだが、共同の承認機関ではない。両組織はIPR、仕様作成、承認、保守の手続を保持し、liaisonにはIETF procedureの例外を作る権限がなかった。

依存先の締切は、自分の締切ではない

mobile releaseが一つのInternet protocolを待っている。release managerには納期があり、端末とcore networkには実装計画がある。しかし依存しているprotocolは別の組織で議論されている。このとき、切迫した予定は技術的事実であっても、相手の承認手続を支配する権利にはならない。

2001年6月のRFC 3113は、この不都合な状態を隠さなかった。目標は、既存のfixed/mobile Internet system、device、protocolとの最大限の相互運用性を保ちながら、技術仕様を適時に完成させることだった。同時に、各組織はIPR policy、仕様の作成、承認、保守を含む自らの規則で運営されると明記した。

つまりtechnical dependencyとjurisdictionは別である。3GPPがRFCを必要としても、IETFの承認権は移らない。IETFが一つのprotocolを管理しても、3GPP architecture全体を決める権利は生まれない。共有するのはsystemであり、無限定なmandateではなかった。

変更しないことが最初の設計だった

RFC 3113によれば、3GPPは可能ならInternet standardをそのまま使い、IETFで済んだ仕事を重複させない方針だった。このdefaultは単なる効率化ではない。同じprotocol名の下にfixed版とmobile版が並び、似ているのに互換でない実装が生まれることを防ぐ。

一方、radio linkやmobility stateが既存仕様の前提を破ることはあり得る。そのため「unchanged」は絶対条件ではなかった。追加や修正が必要なら、3GPPは適切なIETF working groupへ直接問題を持ち込む。該当groupがなければ、Area Directorへ届ける。

このrouteは、変更案をprotocolのowner processへ戻す。3GPPは要件、制約、release timingを説明する。IETFはIETFの方法でprotocol workを判断する。3GPPは得られたartifactを自分の仕様でどう使うか判断する。coordination layerは依存を可視化するが、両方の承認を代理しない。

薄い境界であることに意味があった。liaison officeが納期を理由に例外を発行できれば、それは連絡路ではなく責任のないgatekeeperになる。RFC 3113はroutingを作り、supervisorを作らなかった。

radio expertiseは権限ではなく入力だった

文書は、3GPP側のexpertiseがどこにあるかも示した。radio accessとphysical transport、mobility managementとcore protocol、terminalとapplication、全体architecture、security、operationである。

この情報はIETFに必要だった。fixed networkで安い操作がradioでは高価かもしれない。端末の移動はpathとstateを変える。battery、latency、handoverはprotocolの隠れた前提を露出させる。3GPP expertはその現実をIETF discussionへ運べる。

しかしexpertiseはapproval tokenではない。専門家は「この設計はここで壊れる」と説明できる。それだけで、他組織の標準を採択する主体にはならない。知識と権限を混同すれば、最も詳しい人物の信用が、委任されていない制度的主張へ転用される。

RFC 3113の構造では、専門家は正しい技術の場へ参加し、decisionは既存のprocessに残る。この分離が、相手の知識を利用しながら相手の権限を発明しない条件だった。

liaisonは近道を発行できなかった

working levelのinformal communicationが推奨され、mailing listへの参加が重視された。必要ならformal communicationも可能で、IETF Area Directorと3GPP technical leadershipが助ける。IETF liaisonは、working groupやArea Directorだけでは処理しにくいadministrative issueの入口となる。

ただしRFC 3113は、liaisonにIETF policyやprocedureのexceptionを作る能力がないと書いた。連絡が速いことと、承認が省略されることは別だった。

RFC 4052は後に一般原則を明文化した。liaison relationshipは重複を防ぐが、各組織が自分のmandateを追求することを妨げない。IETFに生じるwork itemは通常のIETF procedureで扱う。managerは宛先違いのrequestを直し、dependencyを追い、指示されたmessageを運ぶ。messageを運んだ人物がconsensusを所有するわけではない。

outgoing liaison statementにも発信主体ごとの承認が必要だった。WG名義ならWG discussionとchair、Area名義ならAD、IETF全体ならIETF Chairが関与する。RFC 4053がいうように、liaison statementは組織間のbusiness letterである。actionを求めることは、actionを承認したことではない。

open documentは「待っている」を検証可能にした

RFC 3113は、相互に関係するdraft documentの共有を促した。webで文書を公開し、相手側のdocument structureを説明するcontact pointを置く。これにより「3GPPがIETFを待っている」という発言を、具体的なspecification、draft version、owner group、期限へ分解できる。

ただしstatusを保存しなければならない。Internet-DraftはRFCではない。特定versionの本文は固定されても、draftは更新・失効し得る。3GPPのTechnical ReportとTechnical Specificationも同じ効力ではない。dependency listは必要性を示すが、実装や承認を証明しない。

RFC 4691は運用例を残した。3GPP、3GPP2、OMAはIETF文書へのdependency listを更新し、liaison managerは必要に応じてRFC番号を急ぐrequestをArea Directorへ伝えた。managerはclockを見せる。番号やpublicationを約束する権限は持たない。

古い詳細と残った原則

現在のIETFは3GPP liaisonを公式一覧に載せ、RFC 3113を参照している。2026年3月のInternet-Draftは、組織名、document access、coordination practiceが古くなったため更新を提案した。一方で、unchanged reuse、non-duplication、変更要求をIETFへ戻すというhigh-level principleは残ると述べる。

このdraftを完成したRFCとして扱ってはならない。work in progressは、現在のauthorsが保存したい原則の証拠であり、RFC 3113をすでにobsoleteにした証拠ではない。

同月のcoordination meeting minutesには、長期化したexchange、見落とされたfeedback、未完成draftへのdependency、3GPPがRFCをnormative referenceとして好む事情、IETFが更新を予定しないcaseが並ぶ。一件は3GPP側で処理し、別件はIETF groupが再度statementを送る。共同の上位決定機関がないからこそ、結果はissueごとに異なる。

divided custodyが境界を守った

3GPPは自分のarchitecture、release、specificationを管理する。IETF WG、Area、IESGはIETF protocol workを管理する。IABはliaison relationshipを管理し、liaisonはrouteとfollow-upを管理する。editorは参照versionを固定し、implementerはbehaviorを作り、operatorはdeploymentを選ぶ。

証拠も分かれる。3GPP referenceはdependencyを示すがIETFによるmobile system全体の承認ではない。RFCはpublicationを示すがdeploymentではない。statementはrequestを示すがacceptanceではない。minutesはdiscussionを示すがinteroperabilityではない。running codeもinstitutional authorityにはならない。

この分離は欠点ではない。deadlineが相手のprocedureを上書きしない。一つのprotocol ownershipがdependent architecture全体へ拡張しない。private forkが共通名のままnetworkへ入らない。そのためのsafety propertyだった。

RFC 3113の歴史的成果は、二組織を一つにしたことではない。documentを共有し、dependencyを名指しし、expertを正しい場へ送り、decisionを責任主体に残した。同じsystemを作るために、承認権を一つにしない。その逆説こそ、境界の設計だった。

出典

  1. https://www.rfc-editor.org/rfc/rfc3113.txt
  2. https://www.rfc-editor.org/rfc/rfc2850.txt
  3. https://www.rfc-editor.org/rfc/rfc2026.txt
  4. https://www.rfc-editor.org/rfc/rfc4052.txt
  5. https://www.rfc-editor.org/rfc/rfc4053.txt
  6. https://www.rfc-editor.org/rfc/rfc4691.txt
  7. https://www.rfc-editor.org/rfc/rfc3131.txt
  8. https://www.ietf.org/about/liaisons/
  9. https://www.ietf.org/archive/id/draft-kes-rfc3113bis-01.html
  10. https://datatracker.ietf.org/doc/minutes-interim-2026-ietf3gpp-01-202603160445/
  11. https://wiki.ietf.org/group/iab/3gpp_liaison_relationship
  12. https://www.3gpp.org/ftp/Information/Working_Procedures/archive/2019-08-23/3GPP_WP.htm