Кратко

  • Редакция 00-01 проекта устава IETF Agent Communication Protocols появилась 14 сентября. Документ по-прежнему проходит внутреннюю проверку Steering Group/IAB и включён в повестку телеконференции IESG 17 сентября; рабочая группа Agentproto ещё не учреждена.
  • В текст добавлено согласование с соответствующими внешними работами по стандартизации и открытыми проектами, чтобы понимать внедрённую практику и избегать ненужного расхождения.
  • Предыдущая фраза требует передавать вопросы об изменении протоколов других рабочих групп IETF этим группам для решения. Внешние сведения и внутренняя компетенция идут разными маршрутами.
  • Daniel Kade предлагает двухконтурную квитанцию согласования. Это авторская рекомендация, а не условие проекта устава.

Один переход для сведений, другой — для полномочий

Редакция 00-01 предусматривает три параллельных результата: базовый протокол управления диалогом пользователей, агентов и инструментов, справочную архитектуру и информационный документ о сценариях и требованиях.

В конце описания результатов стоят две фразы об отношениях с соседними работами. Если Agentproto понадобится изменить или расширить протокол, разработанный другой рабочей группой IETF, вопрос следует передать соответствующей группе. Она решает, как его лучше обработать. Пересечение технических областей не означает автоматической передачи контроля изменений.

Следующая фраза появилась в 00-01. Будущая группа должна координироваться с относящимися к теме работами по стандартизации и открытым кодом вне IETF, изучать реальную эксплуатацию и не создавать лишних несовместимых направлений.

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

Однако доказательная сила не определяет владельца решения. Участие внешнего проекта само по себе не создаёт консенсус IETF. И решение IETF по собственному документу не меняет репозиторий, лицензию или план внешнего проекта. Каждый участник может влиять на другого, но отвечает от своего имени.

Документ движется по процедуре, но ещё не принят

Карточка Datatracker сохраняет состояние Start Chartering/Rechartering (Internal Steering Group/IAB Review) и указывает телеконференцию IESG 17 сентября. Это следующая точка контроля, а не заранее известный результат.

По сравнению с 00-00 новая редакция содержит четыре заметных изменения. Из определения агента удалено intelligent; в абзац о защите обмена данными добавлены пользователи; исправлена грамматическая форма; включена внешняя координация.

История и бюллетень показывают предшествующие замечания. 10 сентября один участник спрашивает, следует ли сотрудничать с группами вне IETF. Другой поднимает вопрос об обмене с пользователями и о контрольных сроках дальнейшего продвижения документов. 13 сентября добавлен срок представления протокола в IESG как Proposed Standard — март 2028 года; на следующий день опубликована 00-01.

Последовательность и сходство формулировок можно проверить. Причинную связь — нет. В изученных публичных материалах отсутствует построчный реестр, где каждое замечание связано с правкой, решившим лицом и обоснованием. Поэтому корректно сказать, что после вопроса появилась соответствующая редакция, но не что вопрос обязательно вызвал её.

Новая версия также не переписывает итоги BoF Agentproto на IETF 126. Там отдельно спрашивали о сфере, результатах и создании группы, а число ответивших менялось. 00-01 — более поздний проект в процедуре учреждения, не способ объединить те подсчёты в одно поручение.

Формальная связь показывает предел представительства

RFC 4052 относит управление официальными отношениями связи IETF к IAB. Такие отношения должны оставаться настолько неформальными, насколько это возможно, и уменьшать дублирование, не мешая каждой организации исполнять свой мандат.

RFC 4691 описывает координатора связи как двусторонний информационный канал. Он собирает сведения, нужные IETF для решений, но не создаёт позицию IETF лично. Сообщение от имени организации должно передавать установленный консенсус, а не частное мнение должностного лица.

RFC 4053 регулирует приём, направление, рассмотрение и ответ на официальные liaison statements. Просьбу повлиять на курс рабочей группы надлежит рассмотреть, но статус отправителя не даёт ей автоматического одобрения. Срок повышает срочность, а не полномочия содержания.

Из этого не следует, что каждый разговор с разработчиком открытого проекта надо оформлять как официальную связь. Публичная issue, отчёт о реализации, испытание совместимости или индивидуальное участие инженера нередко уместнее. Важно сохранить вид источника, его версию и представительский статус до момента внутреннего решения.

Двухконтурная квитанция согласования

Входной контур фиксирует вопрос, внешний артефакт, точную версию или commit, владельца, дату, канал, утверждение и состояние проверки. Отдельно указывается класс: официальное обращение, позиция организации, индивидуальный вклад, наблюдение реализации или неподтверждённое сообщение.

В контуре решения записываются затронутый результат Agentproto, ответственный в IETF, открытое обсуждение, состояние и обоснование. Достаточно ограниченного набора: наблюдалось, рассмотрено, принято, принято с изменениями, отклонено, отложено, запрошено действие внешнего владельца.

Если протокол принадлежит другой группе IETF, квитанция ссылается на её решение, а не подменяет его. Если изменение должен сделать внешний проект, отражаются запрос и независимый ответ, а не вымышленное распоряжение. Исходящее заявление от имени IETF связывается с состоянием консенсуса, разрешающим такое представительство.

Публиковать закрытую переписку или чувствительные сведения об уязвимостях не нужно. Нужно различать известного участника и учреждение, консультацию и согласие, распространённую реализацию и решение по стандарту. Эта схема предложена Daniel Kade и не содержится в проекте 00-01.

Источники

  1. Проект устава Agentproto 00-01 с контрольными сроками
  2. Проект устава Agentproto 00-00 с контрольными сроками
  3. История проекта устава Agentproto
  4. Бюллетень по проекту устава Agentproto
  5. Карточка проекта устава
  6. RFC 4052 — процессы IAB по управлению отношениями связи IETF
  7. RFC 4053 — процедуры обработки liaison statements
  8. RFC 4691 — рекомендации координатору связи IETF
  9. RFC 2418 — принципы и процедуры рабочих групп IETF
  10. RFC 5434 — рекомендации по проведению BoF
  11. Lu Heng — The Multi-Stakeholder Mirage
  12. Lu Heng — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption