Кратко

  • draft-sayre-gendispatch-derivative-06 — действующий индивидуальный Internet-Draft. Он предлагает ограничить механизм запрета производных работ RFC и Internet-Draft, используемыми в процессе стандартов; это не RFC и не принятая политика.
  • RFC 5378 различает широкое понятие IETF Contribution и более узкое IETF Document. Активное заявление IESG объясняет отношение к несовместимым уведомлениям, а протокол IETF 126 оставляет дальнейшее обсуждение IPR-WG и юридическую проверку впереди.
  • Daniel Kade рекомендует реестр статуса вклада: он сохраняет исходный материал, но отдельно показывает классификацию, применённое правило, ответственную роль, действие и путь пересмотра. Это не юридическая консультация и не требование IETF.

Приписка не образует полномочие

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

RFC 5378 задаёт важное различие. Contribution включает материал, направленный для публикации как Internet-Draft или RFC, а также заявления в контексте деятельности IETF; среди них письменные и электронные сообщения рабочим группам, спискам, BOF, пленарному заседанию, IESG и IAB. IETF Document — это RFC или Internet-Draft, используемый в процессе стандартов. Участие и статус документа — не одно и то же.

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

RFC 5378 объясняет, почему для развития и публикации документов IETF требуются определённые права. Он также описывает узкие исключения: описание проприетарной технологии, перепубликацию работы другой организации стандартов и текст, который ещё не принят для разработки. Эти исключения требуют точной квалификации объекта. Они не делают каждый корпоративный footer универсальной юридической формулой.

Проект предлагает границу, а не завершает спор

Версия -06 от 13 августа 2026 года отражена в Datatracker как активный индивидуальный Internet-Draft: без RFC stream, с неизвестной формулой консенсуса и состоянием IESG I-D Exists. Её узкое предложение: механизм no-derivative works применяется только к Contributions, являющимся RFC или Internet-Draft в процессе стандартов. Иные права по RFC 5378 в предлагаемом тексте сохраняются.

Это не поправка к RFC 5378, действующая уже сейчас. Проект не выносит решение по конкретному письму, не подтверждает потерю, цензуру, изменение или неверное архивирование сообщений и не делает читателя проекта юридическим арбитром. На IETF 126 GENDISPATCH зафиксировал иной следующий шаг: дополнительное обсуждение в IPR-WG, затем проверка юридическим советником. Направление в список — не принятие. Будущая проверка — не опубликованное заключение.

Заявление IESG, опубликованное в октябре 2025 года, имеет собственный ограниченный смысл. В нём говорится, что права на производные работы могут удерживаться для Contribution только тогда, когда она является IETF Document, и лишь в узких обстоятельствах. Несовместимые с политикой уведомления предписано игнорировать в Contribution; владелец процесса может потребовать их убрать. Это позиция о политическом эффекте уведомления. Она не позволяет переписать оригинальное сообщение, не назначает заранее ответственное лицо для каждого нового случая и не заменяет будущего правового рассмотрения.

Сохранить поступившее, объяснить статус

Опасны две противоположные краткие дороги. Первая даёт любой приписке скрытое право вето. Вторая понимает «игнорировать» как основание убрать приписку и её контекст из истории. Нужен не выбор между ними, а разделённая запись.

Сначала сохраняется объект получения: устойчивый идентификатор, канал, время, хеш целостности и ссылка на уведомление в том виде, в каком оно пришло. Сохранение не подтверждает действительность уведомления. Затем раскрывается объект классификации: сообщение, названный Internet-Draft, текст RFC, обращение, протокол или комментарий. После этого указывается применённое правило — раздел RFC 5378, заявление IESG, инструкция IETF Trust или реально принятая последующая норма — с версией и состоянием.

Последним указывается действие уполномоченной роли: признание ограничения неприменимым, просьба убрать его, направление на проверку, требование повторной подачи или отсутствие процессуального действия.

Daniel Kade называет такую связку реестром статуса вклада. Его открытая часть может быть небольшой: идентификатор и digest, канал и дата, сохранённая ссылка на уведомление, классификация, версия правила, ответственная роль, состояние действия, путь пересмотра и заменяющее решение. Защищённая переписка может остаться в закрытом приложении. Но закрытость не должна скрывать сам факт решения, его предел и его текущий статус.

Точность терминов сохраняет границы: «уведомление получено» не означает «уведомление действительно»; «Contribution» не означает «документ принят»; «правило применено» не означает «дан юридический совет»; «удаление запрошено» не означает «оригинал переписан»; «передано на проверку» не означает «проверка завершена».

Открытость без досье на каждую реплику

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

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

Здесь полезна сдержанная идея Хэн Лу: участие и экспертность — доказательство, а не полномочие. Отправитель не управляет IETF через подпись. Архив и инструмент не становятся сувереном истории потому, что хранят байты. Правило о правах ограничивает конкретный вопрос, но не перераспределяет все властные роли.

Пределы доказательств

Рассмотренные источники не подтверждают принятие версии -06, обновление RFC, решение о консенсусе IETF или готовое юридическое заключение. Они не доказывают неправомерное действие автора, компании или архива. Реестр — редакционная рекомендация Daniel Kade, а не протокол IETF, условие участия или указание изменять переписку.

Источники

  1. RFC 5378 — Rights Contributors Provide to the IETF Trust
  2. IESG Statement on Clarifying Derivative Works Rights
  3. draft-sayre-gendispatch-derivative-06 — Clarification of Derivative Works Restrictions
  4. Minutes: IETF 126 GENDISPATCH
  5. RFC 7282 — On Consensus and Humming in the IETF
  6. Heng Lu — The Multi-Stakeholder Mirage