Кратко

  • На 27 августа 2026 года DAWN оставалась группой со статусом Proposed. Первый устав 00-00 проходил внутреннюю проверку IESG/IAB, а бюллетень спрашивал только о готовности к внешнему рассмотрению.
  • NETCONF уже имела статус Active, однако 20-02 была предложенной новой редакцией устава. Datatracker прямо называл версию 20 текущим утверждённым уставом.
  • RFC 2418 разделяет подготовку текста, внутреннее и общественное рассмотрение, решение IESG, регистрацию и объявление Секретариата. Полномочия создаёт эта цепочка, а не появление файла.
  • Даже утверждённый устав разрешает работу над ограниченным кругом вопросов. Он не принимает Internet-Draft, не доказывает технический консенсус, не утверждает RFC и не обязывает операторов внедрять результат.

У текста есть дата изменения, у полномочий — дата решения

Обычный реестр документов поднимает наверх последнюю редакцию. Для чтения исправленного текста это разумно. Для ответа на вопрос «что группа вправе делать сейчас» нужны другие сведения: кто был уполномочен принять редакцию, какое решение он вынес и когда произошёл переход.

До утверждения первого устава действующего мандата нет. Проект может содержать точные задачи, председателей, список рассылки и сроки, но поле текущего устава должно оставаться явно пустым. При пересмотре ситуация обратная: рабочая группа и утверждённый объём работы уже существуют. Старый устав действует, пока решение не заменит его новым.

Единственный указатель latest дважды искажает положение. Он заранее создаёт полномочия DAWN и заранее отменяет ограничения NETCONF по версии 20. Поэтому предложенная последняя редакция и текущий утверждённый устав должны храниться отдельно. Пустое значение до образования группы означает «полномочия ещё не возникли», а не «данные потеряны».

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

DAWN подготовила предмет для проверки

На странице DAWN стоял заголовок «Proposed WG Discovery of Agents With Names». Статус группы был Proposed, документ устава — charter-ietf-dawn-00-00, этап — Start Chartering/Rechartering (Internal Steering Group/IAB Review).

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

На странице голосования вопрос звучал узко: «Is this charter ready for external review?». Éric Vyncke указал Yes, Mohamed Boucadair — Block, у остальных перечисленных членов стояло No Record. В резюме говорилось, что позиций достаточно для прохождения этапа после устранения Block.

Boucadair поддерживал саму работу, но просил яснее описать запуск discovery, эксплуатационные модели, различия между локальными и межорганизационными случаями, границы доверия и способность одного протокола покрыть заявленные условия. Это существенное замечание к объёму предлагаемой работы. Оно не было окончательным отказом от DAWN и не доказывало существование бессрочного личного вето.

Позицию Yes также нельзя отделять от вопроса. Готовность к внешнему обсуждению не равна утверждению WG. История устава фиксировала появление 00-00, создание бюллетеня и переход к внутреннему рассмотрению 24 августа, а затем Block 25 августа. Решения о формировании там не было.

Повестка BoF на IETF 126 показывала, что участники уже обсуждали терминологию, варианты использования, требования и проект устава. BoF даёт сведения об интересе, компетенции и разногласиях. Он не переносит полномочие IESG по созданию группы к участникам заседания.

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

NETCONF не теряла версию 20 из-за нового проекта

NETCONF находилась по другую сторону порога. Страница WG показывала статус Active и сложившийся круг задач вокруг NETCONF, RESTCONF, YANG, телеметрии и управления сетями.

На странице устава была опубликована charter-ietf-netconf-20-02, обновлённая 12 августа и находившаяся на внутреннем рассмотрении как recharter. Та же страница содержала ключевую оговорку: показанные сведения относятся к предложенному пересмотру, а текущим утверждённым уставом остаётся версия 20.

Одновременно существовали три объекта: активная группа NETCONF, версия 20 как действующая граница и 20-02 как просьба изменить её в будущем. Рассмотрение третьего не приостанавливало второе.

Бюллетень NETCONF тоже спрашивал о готовности к внешней проверке. Christopher Inacio сохранял Block, поскольку в проекте не было milestones. Mahesh Jethanandani указал Yes, несколько членов — No Objection. В резюме говорилось о возможности пройти этап после устранения Block. Это не было голосованием о вступлении 20-02 в силу.

Если IESG потребует исправлений, настоящим кандидатом может стать следующая редакция. При отзыве версия 20 остаётся. При утверждении решение должно назвать окончательный текст, заменённый устав и момент действия. Ни один сценарий не требует считать 20-02 действующей со дня публикации.

Преждевременная замена переворачивает обязанность обосновывать. До решения сторонник расширения объясняет, почему новая работа принадлежит NETCONF. После накопления заседаний, призывов к принятию и реализаций на основании теневого объёма уже проверяющего просят объяснить, почему он «отнимает» никогда не выданное полномочие. Проверка заявки превращается в утверждение необратимых затрат.

Участие создаёт доказательную основу, а не безграничный мандат

Опубликованной основой на дату наблюдения оставался RFC 2418, часть BCP 25. Предполагаемый председатель и соответствующий Area Director обычно согласовывают устав. IAB даёт рекомендации, IESG принимает окончательное решение. После внутренней проверки предложение открывается более широкому сообществу. IESG может утвердить, изменить или отклонить его, а Секретариат регистрирует и объявляет утверждённую группу.

RFC 2418 называет устав контрактом между IETF и WG на выполнение набора задач. Это институциональный контракт, а не торговая сделка, международный договор или политическая делегация от каждого затронутого человека. Он связывает открытый форум, процедурное управление и ограниченный круг работы.

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

RFC 3710 распределяет роли. Инициатива может исходить от участников или Area Director. Будущие председатели превращают её в выполнимый план. Сообщество показывает знания, поддержку и возражения. IAB проверяет архитектурные последствия. Открытое рассмотрение выявляет риски безопасности, приватности, эксплуатации и пересечений. Area Director координирует, IESG отвечает за институциональный выбор.

Фраза «участие не равно полномочию» не обесценивает консультацию. Сильное возражение может сузить устав, добавить внешнее взаимодействие, разделить результат или показать недостаточную готовность. Участие легитимно как источник сведений и проверяемого несогласия, а не как вымышленная генеральная доверенность присутствующих.

Для важной работы вне действующего устава есть пути: пересмотр, другая WG, работа вне группы или новая группа. Соблюдение границы не означает бездействие.

Устав разрешает разбирать вопрос, но не выбирает ответ

После утверждения устав создаёт пространство задач. Индивидуальный Internet-Draft можно оценить внутри него. Принятие документа рабочей группой означает выбор основы для работы, а не согласие с каждым положением. Rough consensus, Working Group Last Call, оценка IESG и публикация RFC — последующие отдельные акты. Поток и категория дополнительно определяют статус опубликованного RFC.

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

draft-ietf-procon-2418bis-04 показывал то же разделение. На 27 августа он был WG Document со статусом IESG I-D Exists. В заголовке говорилось, что документ сделает RFC 2418 и RFC 3934 устаревшими, если будет утверждён. Условие нельзя удалять из описания состояния.

Текст draft называет устав обязательством по объёму и прямо отделяет принятие Internet-Draft от консенсуса по его содержанию. Устав PROCON разрешает объединить названную цепочку процедурных RFC и требует recharter для иных существенных вопросов. Полномочие подготовить преемника не утверждает его заранее.

Квитанция перехода полномочий

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

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

Раздел решения фиксирует исход IESG, публичное обоснование, дату, объявление Секретариата, момент действия и заменённый устав. Утверждение, возврат на изменения, продолжение старого устава, отзыв, отказ и роспуск — полноценные исходы.

С утверждённым уставом должны передаваться два отрицательных утверждения: он не доказывает консенсус по конкретному документу и не требует его реализации. Эти границы не ослабляют устав, а сохраняют его реальную силу без расширения.

Источники

  1. IETF Datatracker: группы на этапе chartering и rechartering
  2. IETF Datatracker: предложенная группа DAWN
  3. IETF Datatracker: бюллетень по уставу DAWN
  4. IETF Datatracker: история устава DAWN
  5. IETF Datatracker: повестка DAWN BoF на IETF 126
  6. IETF Datatracker: предложенный recharter NETCONF
  7. IETF Datatracker: утверждённый устав NETCONF, версия 20
  8. IETF Datatracker: активная рабочая группа NETCONF
  9. IETF Datatracker: бюллетень по уставу NETCONF
  10. RFC 2418: правила и процедуры рабочих групп IETF
  11. RFC 3710: устав IESG
  12. RFC 6292: требования к средствам работы с уставами WG
  13. IETF Datatracker: статус draft-ietf-procon-2418bis
  14. IETF Datatracker: текст draft-ietf-procon-2418bis
  15. IETF Datatracker: устав рабочей группы PROCON
  16. RFC 3935: миссия IETF
  17. RFC 9281: участники процесса стандартизации IETF