두 조직은 하나의 시스템을 공유했지만 권한은 통합하지 않았다: RFC 3113

요약

• RFC 3113은 3GPP에 가능한 한 IETF 표준을 변경 없이 사용하고, 필요한 변경 사항은 프로토콜을 사적으로 포크하는 대신 적절한 IETF 워킹 그룹 또는 Area Director에 되돌려 달라고 요청했습니다.
• 이 협력은 공동 주권체를 만들지 않았습니다. 각 조직은 지식 재산, 사양 작성, 승인 및 유지보수에 관한 자체 규칙을 유지했으며, liaison은 정보를 전달할 수 있었지만 IETF 절차를 면제할 수 없었습니다.

하나의 네트워크, 두 개의 규칙집

2001년 무렵에는 이동통신 시스템을 더 이상 사적 섬으로 설계할 수 없었습니다. 단말, 코어 네트워크, 서비스는 인터넷과 만나야 했습니다. 그러나 이 두 세계를 만드는 조직들은 하나의 기관의 부서가 아니었습니다. 3GPP는 이동통신 시스템의 기술 사양을 만들었고, IETF는 자체 워킹 그룹과 절차를 통해 인터넷 프로토콜을 개발했습니다. 의존성은 그 경계를 넘을 수 있었지만, 관할권이 그 뒤를 따른다고 가정할 수는 없었습니다.

RFC 3113은 목표를 실무적 언어로 명시하며 시작합니다. 기존 유선·이동 인터넷 시스템, 장치, 프로토콜과의 시의성 있는 사양과 최대한의 상호운용성입니다. 그런 다음 그 야망 옆에 헌법적 한계를 놓습니다. 각 조직은 지식 재산 정책, 사양 작성, 승인, 유지보수에 관한 규칙을 포함해 자체 규칙과 절차에 따라 계속 운영된다는 것입니다.

이 문장이 문서의 중심입니다. 협력은 합병이 아니었습니다. 3GPP의 일정이 IETF의 승인이 되지 않았고, IETF liaison이 대체 워킹 그룹이 되지도 않았습니다. 기술적 의존이 의존하는 사양의 소유권을 이전하지 않았습니다. 인터페이스가 어느 쪽에 어떤 결정이 남는지 명확히 했기 때문에, 두 기관은 공유 시스템을 정확히 조율할 수 있었습니다.

역사적으로 이런 배열을 엔지니어링 위에 떠 있는 외교 계층으로 묘사하고 싶은 유혹이 있습니다. RFC 3113은 더 운영적이었습니다. 릴리스 계획이 프로토콜을 필요로 할 때, 무선 제약이 그 프로토콜의 문제를 드러낼 때, 두 출판 주기가 어느 쪽도 상대의 작업을 몰래 다시 쓰지 않고 수렴해야 할 때 무엇이 일어나는가의 문제였습니다.

재사용이 먼저, 변경은 소유자에게

RFC 3113은 3GPP의 선호 접근을 기록했습니다. 가능한 한 인터넷 표준을 변경 없이 사용한다는 것입니다. 또한 3GPP가 IETF에서 이미 수행된 작업을 복제할 의도가 없다는 점도 밝혔습니다. 이 선호는 두 종류의 파편화를 줄였습니다. 동일 프로토콜에 대한 경쟁 사양을 피했고, 유선과 이동 구현이 익숙한 인터넷 메커니즘에 서로 다른 의미를 붙일 가능성을 낮췄습니다.

그러나 "변경 없이"는 절대적이지 않았습니다. 이동통신 시스템은 기존 인터넷 사양이 다루지 못한 제약과 전문 지식을 가져왔습니다. 그래서 RFC 3113은 예외 경로를 정의했습니다. 3GPP 요구 사항을 충족하기 위해 추가나 수정이 필요하다면, 3GPP는 그 문제를 적절한 IETF 워킹 그룹에, 적합한 그룹이 없으면 Area Director에게 직접 가져간다는 것입니다.

중요한 행위는 일반 조율자에게 허가를 구하는 것이 아니었습니다. 제안된 변경을 프로토콜의 개발 절차를 통제하는 기구로 라우팅하는 것이었습니다. 3GPP는 자신의 사양이 그 결과에 의존할지에 대한 권한을 유지했고, IETF는 무엇이 IETF 작업이 되며 그 작업이 어떻게 승인되는지에 대한 권한을 유지했습니다. 요청이 시급하고 타당해도 자동으로 실행되지는 않았습니다.

이것은 두꺼운 감독 기관이 아니라 얇은 인터페이스였습니다. 의존성을 드러내고, 기술적 근거를 제공하고, 올바른 결정 표면을 찾아주는 역할이었습니다. 두 부모 조직을 모두 무시할 권한을 가진 제3의 기구를 만들지는 않았습니다.

전문 지식은 반대 방향으로 흘렀다

관계는 단순히 3GPP가 완성된 RFC를 소비하는 것이 아니었습니다. RFC 3113은 IETF 참여자들이 무선 접속, 물리 전송, 이동성 관리, 코어 네트워크, 단말, 응용, 아키텍처, 보안, 운영 분야의 전문 지식에 도달할 수 있도록 3GPP 기술 사양 그룹(TSG)을 정리했습니다.

이 상호 경로는 중요했습니다. 열린 프로토콜이라도 불완전한 환경 지식 위에서 설계될 수 있기 때문입니다. 유선 네트워크의 가정이 무선 링크에서는 비용이 크거나, 모호하거나, 불가능해질 수 있습니다. 이동성 메커니즘은 데스크톱 네트워크에서는 보이지 않는 방식으로 상태, 타이밍, 보안과 상호작용할 수 있습니다. 3GPP는 IETF 결과를 선언할 권한을 얻지 않으면서도 이런 제약을 IETF 논의에 가져올 수 있었습니다.

전문 지식과 권한은 다른 증거 클래스입니다. 전문 지식은 설계가 무엇에 부딪히는지 설명합니다. 권한은 정의된 절차 안에서 어느 기구가 변경을 승인할 수 있는지 결정합니다. 둘을 혼동하면 전문가가 두 번 벌을 받습니다. 기술 지식이 정치적 위임으로 취급되고, 이어서 기관이 최종 결정을 내릴 때 그 사람에게 책임이 돌아가기 때문입니다.

RFC 3113은 이 구분을 쓸 수 있게 유지했습니다. 워킹 그룹과 기술 그룹이 실질 작업을 했습니다. 연락 창구는 참여자가 올바른 방을 찾도록 도왔습니다. liaison은 워킹 그룹이나 Area Director로 처리하기 어려운 행정 문제를 위한 것이었습니다. 혼란을 우회하는 경로였지, 절차를 우회하는 경로가 아니었습니다.

liaison은 메시지를 나르지 위임을 나르지 않았다

문서는 비공식적 실무 수준의 소통과 메일링 리스트 참여를 장려했습니다. 필요할 때는 관련 IETF Area Director와 3GPP 기술 리더십이 중개하는 공식 소통도 가능했습니다. 관계의 행정적 측면에 대한 초기 연락 창구로 IETF liaison을 두자고 제안했습니다.

그런 다음 이 역할에서 가장 위험한 지름길을 차단했습니다. liaison은 3GPP의 행정 절차에 참여할 것으로 기대되지 않았고, IETF 정책과 절차에 대해 예외나 특별 조치를 만들 권한이 없었습니다.

이후의 IETF 프로세스 문서들은 같은 경계를 더 명확히 했습니다. RFC 4052는 liaison 관계를, 어느 조직도 자기 위임을 추구하지 못하도록 막지 않으면서 우발적 중복을 방지하는 방법으로 묘사했습니다. IETF에 귀속되는 결과 작업은 여전히 보통의 IETF 절차를 따라야 했습니다. liaison 관리자는 잘못 전달된 요청을 재지향하고, 소통을 유지하고, 의존성을 추적하고, 승인된 메시지를 전달할 수 있었습니다. 하지만 메시지를 나르는 것으로 합의를 만들어내지는 않았습니다.

발신 liaison 문서에도 승인 절차가 있었습니다. 워킹 그룹을 대표한다고 주장하는 문서는 워킹 그룹 논의와 의장의 동의가 필요했습니다. Area 문서는 Area Director의, IETF 전체 문서는 IETF Chair의, IAB 문서는 IAB Chair의 승인이 필요했습니다. RFC 4053의 더 소박한 설명이 유용합니다. liaison 문서는 업무 서신이라는 것입니다. 정보를 요청하고, 의견을 제시하고, 조치를 요구할 수 있습니다. 전달이 곧 승인이 아니며, 기한이 곧 명령 권한이 아닙니다.

여기서 이 역사는 인터넷 거버넌스의 더 넓은 교리와 만납니다. 참여는 증거이자 경고이자 전문 지식일 수 있습니다. 그러나 자동으로 승인이 되지는 않습니다. 상설 채널은 원칙(principal)이 되지 않으면서도 가치 있을 수 있습니다. 메시지와 위임은 별도로 귀속 가능해야 합니다.

공개 문서가 불일치를 검증 가능하게 만들었다

RFC 3113은 양 조직이 상호 관심사의 초안 문서를 공유하도록 권장했습니다. 2001년의 이 기록은 공개 웹 접근과 낯선 문서 구조를 설명해 줄 연락 창구를 강조했습니다. 공개 아카이브가 보편화된 지금에서야 비로소 평범하게 들립니다.

문서 접근은 인터페이스의 질을 바꿨습니다. 의존성을 회의의 전언이 아니라 정확한 아티팩트로 특정할 수 있게 되었습니다. 제안된 변경을 텍스트에 대조해 논의할 수 있게 되었습니다. 일정 리스크를 초안의 상태에 연결할 수 있게 되었습니다. 관찰자는 한 조직이 실제 출판한 것과 다른 조직이 출판해 주기를 바라는 것을 구분할 수 있게 되었습니다.

그래도 기록은 신중한 해석이 필요했습니다. Internet-Draft는 RFC가 아닙니다. 초안 참조가 안정된 버전을 가리킬 수 있지만 그 초안은 이후 변경되거나 만료될 수 있습니다. 3GPP 기술 보고서(TR)는 기술 사양(TS)과 같은 아티팩트가 아닙니다. liaison 문서는 의존성을 보고할 수 있지만 수신 기구가 요청된 조치를 수락했음을 증명하지는 않습니다.

RFC 4691은 이후 실용적 메커니즘을 기술했습니다. 3GPP, 3GPP2, OMA가 갱신된 의존성 목록을 보내면 liaison 관리자가 이를 추적하고, 필요할 때 신속한 RFC 번호 배정 요청을 적절한 Area Director에 전달한다는 것입니다. 관리자는 시간 압박을 드러낼 수 있었습니다. 그러나 무엇이 가능한지는 여전히 Area Director와 IETF 절차가 결정했습니다.

경계는 살아남았고, 세부는 늙었다

IETF는 여전히 3GPP를 활성 liaison 관계로 등록하고 RFC 3113을 가리킵니다. 2026년 3월의 Internet-Draft는 조직 이름, 문서 접근 메커니즘, 조율 관행이 바뀌었기 때문에 기존 문서를 대체할 것을 제안합니다. 중요한 것은, 그 초안이 상위 수준의 원칙은 그대로 유지된다고 말한다는 점입니다. 가능한 한 인터넷 표준을 변경 없이 재사용하고, IETF 작업의 중복을 피하고, 필요한 변경을 적절한 IETF 장소로 가져간다는 것입니다.

지위와 증거의 구분이 중요합니다. 2026년 문서는 진행 중인 작업입니다. 그 자체 증거로는 RFC 3113을 폐기(obsolete)하지 않았습니다. 저자들과 현재 조율 그룹이 무엇을 보존하려 하는지 보여줄 수는 있지만, 승인된 후속 문서로 인용될 수는 없습니다.

2026년 3월 IETF–3GPP 조율 회의 회의록은 이 인터페이스에 아직 해야 할 일이 왜 있는지 보여줍니다. 참여자들은 장기화된 교환, 빠진 피드백, 미완성 초안에 대한 의존성, 3GPP의 규범적 참조로서의 RFC 선호, IETF가 문서를 갱신할 계획이 없는 사례들을 논의했습니다. 한 항목에서는 3GPP가 문제를 자체적으로 처리했고, 다른 항목에서는 IETF 그룹이 추가 liaison 문서를 보낼 것으로 기대되었습니다. 조율이 결과를 하나의 규칙으로 통합하지는 않았습니다.

이 당대 기록은 모든 문제가 해결되었거나 RFC 3113이 이후의 상호운용성을 만들었다고 증명하지 않습니다. 더 좁은 무언가를 증명합니다. 의존성, 타이밍, 소유권은 여전히 실제 운영 변수이며, 오래된 인터페이스는 버려지기보다 갱신될 수 있을 만큼 충분히 알아볼 수 있다는 것입니다.

지속된 설계는 분할 보관이었다

이 협력은 서로 다른 증거와 행동을 서로 다른 보관자에게 배정했습니다. 3GPP는 자신의 이동 아키텍처, 릴리스 요구, 기술 사양을 알았습니다. IETF 워킹 그룹은 프로토콜 작업을 알고 IETF 변경 절차를 운영했습니다. IAB는 liaison 관계를 관리했습니다. liaison 관리자는 경로와 의존성 인식을 유지했습니다. 편집자는 구체적 아티팩트를 특정했습니다. 구현자는 버전을 선택하고 텍스트를 동작으로 바꿨습니다. 운영자와 사용자는 조각들이 상호운용되는지를 경험했습니다.

어느 한 계층도 전체 결과를 증명하지 않았습니다. 3GPP 참조는 의존성을 보여주지만 주변 이동 사양에 대한 IETF 승인을 보여주지 않습니다. RFC는 출판을 보여주지만 현장 배치를 보여주지 않습니다. liaison 문서는 요청을 보여주지만 수락을 보여주지 않습니다. 회의록은 논의를 보여주지만 프로토콜 적합성을 보여주지 않습니다. 구현은 한 시스템에서의 동작을 증명할 뿐 공유 표준을 재정의할 권한을 증명하지 않습니다.

이 분할 보관은 제거해야 할 약점이 아니었습니다. 그것이 안전 속성이었습니다. 조율자가 릴리스 일정을 맞추기 위해 IETF 절차를 면제할 수 있다면, 그 채널은 검증 불가능한 관문이 됩니다. IETF가 하나의 프로토콜을 소유한다는 이유로 3GPP의 이동 아키텍처 전체에 지시할 수 있다면, 의존성은 관할권 확장이 됩니다. 어느 쪽이든 상대의 작업을 사적으로 포크하면 그 비용은 이후 호환되지 않는 시스템으로 나타납니다.

RFC 3113은 더 규율된 답을 제시했습니다. 초안을 공유하고, 의존성을 명명하고, 전문가를 관련 기술 논의에 넣고, 책임 있는 기구로 상급화하고, 각 조직의 승인 절차를 보존하고, 릴리스가 실제 의존하는 버전을 기록하라는 것입니다.

두 기관은 하나의 시스템을 공유했지만 권한은 통합하지 않았습니다. 그것은 엔지니어링을 둘러싼 어색한 타협이 아니었습니다. 그 경계 자체가 곧 엔지니어링이었습니다.

출처

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