Кратко

  • В консультации сказано, что прежнее SLA выполнялось лишь в 42,5% измеренных кварталов с 2016 года, а старые состояния неполно отделяли ожидание автора, ожидание назначения редактора и части финальной проверки AUTH48.
  • Новый проект использует скользящий год, показатели выпуска и активного бэклога, три группы размера, процентили и две постепенно ужесточающиеся шкалы. В SLA входит только время под контролем RPC.
  • Документ оценивает нынешний путь типичного RFC объёмом 30–50 страниц примерно в 245 календарных дней, связывает около 115 дней с бэклогом и называет в среднем около 97 дней вне контроля RPC. Эти совокупные оценки пересекаются и не складываются в три независимых отрезка.
  • Daniel Kade предлагает реестр ответственных передач: начало и конец состояния, владелец, следующий исполнитель, основание часов, причина, порог эскалации и история исправлений сохраняются вместе с ограниченным и полным временем.

Зелёный показатель не завершает документ

Если редактор ждёт ответа автора, часы RPC должны остановиться. Центр не может дать этот ответ и не должен нарушать контракт из-за действия, которое принадлежит другому участнику. Если требуется решение IESG или операция IANA, административный таймер тем более не способен его произвести.

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

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

Консультация объясняет, почему прежняя мера больше не справляется с различением. По её данным, с 2016 года SLA соблюдалось только в 42,5% измеренных кварталов. Цель, которая систематически не достигается, перестаёт показывать исключение. Она может свидетельствовать о расширившейся работе, неполной модели или неизменённом обещании, но не сообщает, какой из факторов действует сейчас.

Состояния очереди тоже были неоднозначны. До второго квартала 2025 года режим ожидания автора применяли редко, поэтому время могло оставаться на стороне RPC, когда центр фактически ждал. Отдельного состояния для ожидания назначения редактора не было. А части AUTH48, когда работа RPC ещё продолжалась, не входили в прежний счётчик. Числа могли совпадать с базой данных и одновременно неверно объяснять операцию.

Как устроен предлагаемый ответ

Проект учитывает объём документа. Анализ оценивает добавочную нагрузку примерно в 0,34 дня RPC на страницу. Один предел неизбежно давал бы преимущество очереди с короткими текстами и штрафовал бы период с длинными RFC. Три диапазона размера уменьшают такое искажение.

На исходном уровне 75% документов должны укладываться в подконтрольные RPC пределы: 130 дней при объёме до 15 страниц, 170 дней при 16–40 страницах и 190 дней при объёме свыше 40 страниц. Затем действуют две храповые шкалы. Требуемая доля растёт на один процентный пункт в квартал до 85%. После первого года максимальные сроки сокращаются на 5% ежегодно.

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

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

Модель основана на неизменных общих редакционных ресурсах и неизменном объёме обязанностей RPC. Она предполагает медленное сокращение накопления существующими силами, а не временное вложение. При этих условиях бэклог должен уменьшиться примерно на 20% за три года и исчезнуть через семь–двенадцать лет. Это условная траектория, не обещанная дата.

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

Почему нельзя сложить 245, 115 и 97

Для типичного RFC на 30–50 страниц в консультации приведена оценка около 245 календарных дней от получения до публикации. Нынешнему бэклогу приписывается примерно 115 дней, а путь без него моделируется примерно в 130 дней. Среднее время вне контроля RPC — автор, IESG и IANA — оценивается примерно в 97 дней независимо от числа страниц.

Эти значения описывают систему с разных сторон. Они не представлены как три непересекающиеся части одного документа. Их сложение создало бы структуру, которой нет в источнике. Они также не доказывают причину задержки конкретного RFC: одному мешает нормативная ссылка, другому — сложная редактура, третий быстро проходит AUTH48, но долго ждёт назначения.

Для управленческого вывода достаточно возможности расхождения. RPC может сократить свой сегмент, а полная длительность останется прежней, если ожидание переместилось к передаче. Это реальное улучшение исполнителя, но ещё не улучшение для автора. И наоборот: длинная полная длительность не доказывает, что дополнительные средства RPC устранят ограничение.

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

AUTH48 показывает разделённый контроль

На этапе AUTH48 текст близок к публикации, но авторы и назначенные проверяющие должны подтвердить окончательную редакцию. Может потребоваться уточнение технической формулировки, завершение ссылки или действие IANA. Такая осторожность поддерживает архивное качество серии. Её нельзя автоматически считать потерей времени.

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

Полномочия без подмены мандата

То же относится к руководителю потока, IESG и IANA. RFC 9280 разделяет разработку политики серии, одобрение и производственную реализацию между RSWG, RSAB, RPC и IETF LLC. RFC 8711 возлагает на LLC административную, операционную и финансовую ответственность, но не даёт власти над разработкой стандартов IETF.

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

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

Реестр передач как второй видимость, а не второй штраф

Запись начинается с идентичности одобренного черновика и связывает её с итоговым RFC. Для каждого состояния сохраняются момент входа и выхода, тип часов — рабочие или календарные дни, активный или остановленный счёт, ответственный за состояние и держатель следующего действия.

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

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

Такой реестр не вводит SLA для волонтёров и не оценивает авторов в таблице. Он объясняет, почему показатели расходятся. Если RPC становится быстрее, а путь не меняется, можно исследовать передачу, которая приняла ожидание. Если полное время увеличивается из-за необходимой проверки, качество остаётся отличимым от бездействия.

Объём работы нельзя спрятать в скорости

Консультация перечисляет рост сложности: RFCXML v3, проверку YANG и исходного кода, поддержку нелатинских символов и письма справа налево, доступность, редакционные errata, GitHub и Markdown, сайты и инструменты. Она сообщает о постепенном замедлении примерно на шесть дней на документ в год и не сводит его к одному событию.

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

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

Цель RFC Series — долговечная техническая запись, а не максимум завершений. Скорость, точность, доступность и сохранность нельзя свести к одному процентилю без потери смысла.

Консультация определяет будущую память

Mirja Kühlewind в индивидуальном ответе называет горизонт семь–двенадцать лет длинным и ставит вопрос о пользе фиксированных метрик самих по себе. Acee Lindem предлагает сосредоточиться на времени от входа в очередь до AUTH48 и сомневается в дополнительном процессе. Это атрибутированные личные позиции, а не консенсус IETF.

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

Поэтому справедливое решение двуслойно. RPC получает управляемое SLA только для своего времени. Сообщество получает рядом некарательный сквозной показатель и историю передач. Граница контракта определяет ответственность за сегмент; она не должна определять, какой части ожидания разрешено остаться в памяти.

Источники

  1. Консультация о SLA редактирования и публикации RFC
  2. Объявление IETF Administration LLC о консультации
  3. RFC 9280: RFC Editor Model, версия 3
  4. RFC 8711: структура административной поддержки IETF
  5. Процесс публикации для авторов
  6. Описание очереди RFC Editor
  7. Отчёт RPC для председателей рабочих групп
  8. Отчёт о сроках публикации и состояниях процесса
  9. Индивидуальный ответ Mirja Kühlewind
  10. Индивидуальный ответ Acee Lindem