Кратко
- RFC 3005 сделала общий дискуссионный список IETF широким местом для технической работы и обсуждения курса организации, но не признала уместными любые темы, тон или повторение.
- Ограничить человека или ветку можно было при неуместном содержании, образующем модель злоупотребления; жалобы направлялись в IAB, а поздние BCP уточнили сроки, предупреждения, чтение и апелляцию.
Открыть дверь для участия — не значит отказаться от действий, если кто-то постоянно занимает проход. В общей дискуссии дефицитны не байты, а внимание и возможность других внести вклад. RFC 3005, опубликованный в ноябре 2000 года как Best Current Practice 45, описал этот предел для самой общей рассылки IETF.
У общего дискуссионного списка было два назначения. Он помогал разрабатывать и специфицировать интернет-технологии через техническое обсуждение и принимал разговоры о направлении, политике, встречах и процедурах IETF. Самому широкому форуму полагалась значительная свобода. Вопросам без рабочей группы, Last Call и спорам о самой организации требовалась видимая начальная площадка.
Однако это была именно площадка для первоначального обсуждения. Если тема относилась к рабочей группе или устоявшемуся списку, после указания её следовало перенести, кроме случаев, когда нужен был более широкий взгляд. Открытость не обязывала один центральный канал хранить каждую дискуссию. Правильное распределение защищало общее внимание.
Устав перечислял допустимое: Last Call, новые технические вопросы, административная политика, уточнения о встречах, мероприятия при поддержке ISOC или IETF. Неуместными были нежелательные массовые письма, посторонние темы, неподдержанные анонсы и непрофессиональные комментарии независимо от общей темы. Техническая релевантность сообщения не доказывала профессиональность его формы.
Полномочия вмешаться получили IETF Chair, Executive Director или назначенный Chair sergeant-at-arms. Они могли ограничить публикации человека либо ветки, когда содержание было неуместным и представляло модель злоупотребления. Два условия стояли вместе. Отдельная ошибка, жёсткое возражение или непопулярный вывод не объявлялись моделью автоматически.
Принимающему решение рекомендовалось смотреть на общую природу сообщений человека и отличать отклонение от типичного поведения. Это контекстное наблюдение во времени, а не словарь запрещённых выражений или числовой порог.
Первичный исполнитель не становился последней процессуальной инстанцией. Жалобы на решения направлялись в IAB. Короткий текст RFC 3005 не определял максимальный срок, обязательную лестницу предупреждений или формат дела. Но он отделял первоначальное действие от внешнего рассмотрения. Техническая блокировка требовала институциональной ответственности.
RFC 2418 объясняет значение этого канала: формального членства в IETF не было, участвовать могли все, а люди выступали как индивидуальные технические авторы. Рассылки были рабочей средой стандартов. Ограничение публикации влияло на маршрут участия, но не определяло истинность технического довода.
В 2004 году RFC 3683 отчётливо разделил непрерывное нарушение процесса и одинокий голос несогласия. Долговременная posting-rights action проходила через Area Director, IESG Last Call, обсуждение сообщества, решение IESG и обжалование. Она касалась права писать, а не читать: получение сообщений должно было сохраняться.
RFC 3934 ввёл отдельный временный путь для списков рабочих групп. Обычно Chair сначала обращался напрямую, затем делал хотя бы одно публичное предупреждение и советовался с Area Director. Последней мерой была приостановка не более чем на тридцать дней. Получение продолжалось, решение можно было обжаловать. Общий список, рабочая группа и действие IESG не давали одну безграничную власть.
История требует раздельных свидетельств. Техническая уместность не доказывает корректное поведение. Поведенческое ограничение не опровергает технический аргумент. Жалоба сама по себе не доказывает процессуальный сбой. Отсутствие консенсуса допустимо и не равно атаке. Каждое утверждение нуждается в собственном следе.
RFC 3005 сохранил низкий порог входа, публично описал назначение, отделил эпизод от модели, назвал действующих лиц и передал жалобу другой структуре. Открытость поддерживалась не отсутствием власти, а возможностью прочитать её границы и проверить применение.
Sources
- Lu Heng, «Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: An Internet Coordination System»
- Lu Heng, «On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile»
- Lu Heng, «Running Code Primary: The Patch Needed to Preserve the Internet’s Original Design»
- Страница RFC 3005 в RFC Editor
- RFC 2026, процесс интернет-стандартов
- RFC 2418, правила и процедуры рабочих групп IETF
- RFC 3005, устав дискуссионного списка IETF
- RFC 3683, практика отзыва прав публикации
- RFC 3934, обновление управления списками IETF
- RFC 7154, правила поведения IETF
- RFC 7776, процедуры IETF против домогательств
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
