Кратко

  • 3GPP предпочитала использовать стандарты IETF без изменений и не дублировать работу. Нужную модификацию RFC 3113 направляла в соответствующую рабочую группу IETF или к Area Director.
  • Liaison не объединяла мандаты. Обе организации сохраняли правила IPR, разработки, утверждения и сопровождения, а координатор не мог делать исключения из процедур IETF.

Чужая зависимость не становилась чужой юрисдикцией

Релиз мобильной системы может ждать протокол, который ещё обсуждает другая организация. 3GPP знает свой срок и цену задержки. Но календарь не даёт ей права утверждать документ IETF.

Именно эту ситуацию описала RFC 3113 в июне 2001 года. Целью были своевременные спецификации и максимальная совместимость с существующими фиксированными и мобильными интернет-системами. Рядом стояло ограничение: каждая организация действует по собственным правилам, включая интеллектуальную собственность, разработку, утверждение и сопровождение спецификаций.

Техническая зависимость не передавала полномочия. Ссылка 3GPP на RFC не означала одобрение IETF всей мобильной архитектуры. Владение процессом одного протокола не давало IETF власть над каждым релизом 3GPP. Общий канал должен был найти ответственного, а не создать третьего начальника.

Сначала повторное использование, затем изменение у владельца

Предпочтением 3GPP было неизменённое применение интернет-стандартов, если это возможно. Организация не хотела повторять работу IETF. Такой default защищал от частного fork: фиксированная и мобильная версии не должны были использовать одно имя для разного поведения.

Радиосреда всё же могла обнаружить новую потребность. Мобильность, состояние, задержка, ограничения терминала или безопасность иногда требовали дополнения. Поэтому «без изменений» не было абсолютным запретом. 3GPP должна была принести вопрос в подходящую рабочую группу IETF, а при её отсутствии — к Area Director.

Изменение возвращалось в процесс, который отвечал за протокол. 3GPP поставляла требования, контекст и сроки. IETF решала своим способом, что станет работой IETF. Затем 3GPP выбирала, как включить результат в свою спецификацию. Liaison показывала узкое место, но не подписывала решение за обе стороны.

Тонкость интерфейса была достоинством. Если координатор может отменять проверку ради даты релиза, канал связи превращается в безответственный gatekeeper.

Экспертиза радио была входом, а не доверенностью

RFC перечисляла области знаний 3GPP: радиодоступ и физический транспорт, управление мобильностью и core network, терминалы и приложения, архитектура, безопасность и эксплуатация. Это был двусторонний обмен, а не простое потребление готовых RFC.

То, что дёшево в фиксированной сети, может дорого стоить по радио. Handover меняет путь и состояние. Ограниченный терминал превращает задержку и энергию в свойства протокола. Эксперт 3GPP мог принести эти факты в обсуждение IETF.

Однако знания и власть — разные классы доказательств. Знание объясняет последствия дизайна. Полномочие определяет, кто может принять изменение. Участие, письмо или самая точная диагностика не делают эксперта principal другой организации.

RFC 3113 сохранила обе функции: специалист попадал в правильный технический форум, а утверждение оставалось в существующем процессе.

Посланник не мог выдать исключение

Документ поощрял неформальное общение на рабочем уровне и участие в mailing lists. При необходимости формальной связи помогали руководители 3GPP и Area Directors IETF. Liaison была начальной точкой для административных вопросов, которые трудно решить напрямую.

Но текст прямо запрещал главную подмену: координатор не мог создать исключение или специальное положение для политики и процедур IETF. Он доставлял сообщение, а не создавал consensus.

RFC 4052 позже распространила границу на liaison-отношения вообще. Они предотвращают дублирование, не мешая каждой организации следовать своему mandate. Любая работа IETF проходит обычный процесс. Менеджер может исправить адрес, отследить dependency и перенести авторизованное сообщение; он не создаёт позицию, которую оно представляет.

Исходящая liaison statement тоже имеет цепочку одобрения. Для рабочей группы нужны обсуждение и согласие chairs, для Area — её директор, для всей IETF — IETF Chair. RFC 4053 называет такой документ деловым письмом между организациями. Письмо может просить действие, но не является этим действием.

Открытый документ превращал ожидание в проверяемый факт

RFC 3113 призывала делиться взаимно интересными drafts и обеспечивать открытый Web-доступ. Контакты помогали разобраться в структуре документов другой стороны. Поэтому фразу «3GPP ждёт IETF» можно было разложить на точную спецификацию, revision, ответственную группу и срок.

Статусы нельзя смешивать. Internet-Draft не является утверждённой RFC. Конкретная версия может быть зафиксирована в байтах, но сам draft истекает или заменяется. Technical Report и Technical Specification 3GPP различаются. Список зависимостей не доказывает реализацию.

RFC 4691 описала практику: 3GPP, 3GPP2 и OMA присылали обновлённые dependency lists, а liaison manager отслеживал их и мог передать просьбу об ускоренном номере RFC Area Director. Канал показывал часы, но не гарантировал публикацию к нужной дате.

Принцип пережил устаревшие детали

IETF по-прежнему перечисляет формальную связь с 3GPP и ссылается на RFC 3113. Internet-Draft марта 2026 года предлагает обновление, потому что структуры, названия и способы доступа изменились. При этом базовые принципы названы сохранёнными: использовать без изменений, не дублировать и возвращать запрос на изменение в IETF.

Статус проекта ограничивает вывод. Это work in progress, не уже утверждённая замена. Он показывает намерение нынешних авторов, но не доказывает, что RFC 3113 формально устарела.

Протокол совещания того же месяца показывает интерфейс в работе: долгие обмены, пропущенный feedback, зависимости от незавершённых drafts, предпочтение 3GPP ссылаться на RFC и случаи, когда IETF не планировала обновление. Иногда 3GPP решала вопрос сама, иногда группа IETF готовила новое сообщение. Общей кнопки решения не было.

Раздельное хранение полномочий защищало общий результат

3GPP контролировала архитектуру, releases и спецификации. Рабочие группы, Areas и IESG контролировали работу IETF. IAB управляла отношением; liaison — маршрутом и контролем ответа. Редакторы фиксировали ссылки, разработчики поведение, операторы deployment.

Ни одно свидетельство не охватывало всю цепь. Ссылка 3GPP доказывала зависимость, но не одобрение всей системы IETF. RFC доказывала публикацию, но не внедрение. Письмо доказывало запрос, но не согласие. Minutes доказывали разговор, но не совместимость. Работающий код не получал институциональный мандат.

Разделение не позволяло сроку одной стороны переписать процесс другой, владению протоколом расшириться на всю зависимую архитектуру, а частному fork выйти под общим именем.

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