Кратко

  • Председатель исследовательской группы ITU-T мог уполномочить официального делегата, но в IETF его мнение имело тот же вес, что и мнение любого другого участника рабочей группы.
  • Одобрение, доставка, публичный архив и назначенный ответственный делали связь прослеживаемой, но не доказывали согласие, консенсус, нормативную публикацию или внедрение.

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

Именно эту границу RFC 3356 сформулировал особенно ясно. Мнение официального делегата ITU-T в рабочей группе IETF получало такой же вес, как мнение любого другого участника. Мандат устанавливал происхождение позиции. Он не добавлял голос, право вето или готовый консенсус в процедуру получателя.

Информационный RFC был опубликован в августе 2002 года и заменил RFC 2436. Большая часть текста совпадала с Дополнением 3 серии A ITU-T, одобренным TSAG в ноябре 2001 года. Координация была необходима: сигнализация, нумерация, безопасность, маршрутизация, управление, производительность и доступ одновременно появлялись в планах обеих организаций.

Однако институциональные устройства различались. IETF работал в рабочих группах, главным образом через открытые публичные списки рассылки, в рамках областей и IESG. ITU-T делил работу на вопросы, рабочие партии, исследовательские группы и докладчиков, придавая большее значение заседаниям. Сотрудничество не могло означать одну процедуру под двумя названиями.

Первым механизмом было обнаружение пересечений. Исследовательская группа должна была записать в план цель и ожидаемый результат взаимодействия. Рабочая группа IETF должна была отметить связь в своём уставе. Тематическая близость тем самым не превращалась в совместное право распоряжаться темой.

Список NewWork давал раннее предупреждение. В него поступали проекты новых и изменённых уставов рабочих групп и объявления BOF, а рассылка ITU-T передавала их своим группам. RFC 3356 предупреждал, что новый устав IETF мог пройти за две недели, поэтому наблюдение требовалось постоянно. Обновления программы ITU-T должны были идти навстречу.

Уведомление создавало время для реакции, но не резервировало предмет и не останавливало чужую процедуру. Это был канал внимания, а не источник юрисдикции.

Для официального представительства существовала отдельная цепочка. Участник IETF мог присутствовать на заседании ITU-T как делегат ISOC после одобрения соответствующей рабочей группы или области; председатель IAB передавал регистрацию в TSB. В обратную сторону председатель исследовательской группы мог уполномочить участника официально говорить о работе группы или группы докладчика.

Цепочка защищала происхождение высказывания. Личное мнение нельзя было незаметно выдать за позицию учреждения. Но в IETF эта позиция всё равно входила в открытую дискуссию и формирование консенсуса. Авторитет отправителя не становился авторитетом над получателем.

Та же логика действовала вне заседаний. Неформальный обмен между экспертами приветствовался. Формальное сообщение требовало явного одобрения и указания, от какой исследовательской группы, рабочей партии, группы докладчика, рабочей группы IETF или области оно исходит.

Официальное сообщение ITU-T направлялось председателям и директорам областей, копировалось на специальный адрес приёма заявлений о связи, публиковалось на открытой странице и закреплялось за ответственным сотрудником IETF. Так возникали доказательства доставки, открытости и обязанности обработать материал.

Согласие из этого не следовало. Архивированное заявление могло оставаться открытым, вызвать возражения, получить частичный ответ или устареть. Имя ответственного — квитанция об обязанности, а не квитанция о решении.

Передача документов сохраняла статус источника. Для отправки Internet-Draft в ITU-T как вклада ISOC рабочая группа IETF должна была подтвердить взаимный интерес, пользу передачи и точность описания состояния; затем запрос одобряли директора областей. Одобрялся перенос для рассмотрения, а не проект как стандарт.

В обратном направлении проект Рекомендации ITU-T должен был указывать стадию, контакты и исследовательскую группу, рабочим документом которой он оставался. Формат Internet-Draft не превращал его в консенсус IETF. В 2002 году Internet-Draft был временным и истекал через шесть месяцев.

Поэтому RFC 3356 предпочитал полное описание результата одним органом и ссылку со стороны другого. Совместный текст не рекомендовался из-за разных процедур одобрения и пересмотра. Ссылка соединяла спецификации, не смешивая хранение и контроль изменений.

RFC 2026 задавал правила ссылок IETF на внешние открытые стандарты; Рекомендация A.5 выполняла аналогичную функцию в ITU-T. Даже общие слова RFC 3356 и Дополнения 3 оставались в разных цепочках публикации и замены.

Позднее RFC 4052, RFC 4053 и RFC 4691 уточнили управление отношениями, обработку заявлений и поведение представителей. Представитель передавал и объяснял информацию, но не был самостоятельным переговорщиком, способным связать IETF обязательством. RFC 6756 заменил RFC 3356 в 2012 году, сохранив правило равного веса и раздельное ведение документов.

Источники не доказывают, что каждое реальное взаимодействие работало идеально. Здесь нет конкретного спора или внедрения. Они дают модель доказательств: человек, мандат, сообщение, доставка, обработка, консенсус, публикация и работающий код требуют отдельных записей.

Делегат говорил от имени учреждения. Именно поэтому рабочая группа должна была сама принять и зафиксировать своё решение.

Sources