Кратко

  • draft-sparysh-pala-audit-00 был анонсирован 3 сентября 2026 года. Datatracker указывает, что это активный индивидуальный Internet-Draft без одобрения и формального статуса IETF, без RFC stream и ответственного Area Director.
  • Текст описывает PALA-1 как уже существующий wire format для аудиторских записей, замороженный в версии 1.0. Проект Palimpsests принял это локальное решение 9 августа — до подачи в IETF.
  • Draft сообщает о пяти реализациях, но отделяет эталонный код авторов от четырёх реализаций по тексту, проверенных на векторах, предоставленных проектом.
  • Более поздний прогон по тегу v1.0 выявил неоднозначности и пробел в сопоставлении spans. Draft говорит об изменении спецификации после freeze, но не заявляет об изменении wire или векторов.
  • Минимальная квитанция должна отдельно указывать замороженный объект, роль проекта, состояние IETF, замечание, класс изменения, решившую сторону и последствия для старых readers и writers.

Две временные линии

Анонс IETF появился 3 сентября. Datatracker задаёт точную институциональную границу: индивидуальный I-D может подать любой человек; эта публикация не одобрена IETF и не имеет официального места в процессе стандартов. На момент отсечения не были указаны RFC stream и Responsible AD, а состояние IESG ограничивалось «I-D Exists».

В заголовке самого документа указан предполагаемый статус Informational, тогда как сводное поле Datatracker оставалось пустым. Ни одно поле не означает одобрения. RFC Editor подчёркивает, что I-D — рабочий документ, а не RFC. Даже возможное принятие Working Group стало бы только началом последующего обсуждения и изменений.

Проект остановил собственные часы раньше. Commit 50b47edb1ed8 от 9 августа перевёл спецификацию из Draft в «Frozen — v1.0». Обещание ограничено wire: его изменение требует нового format_version, тогда как profiles могут расширяться в собственных пространствах. Сентябрьский I-D прямо говорит, что показывает существующий формат, а не пересматривает его.

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

У реализаций должна оставаться родословная

Implementation Status перечисляет пять реализаций: reference implementation авторов, работу co-maintainer с заявленной границей заимствования и три реализации людей, которые во время прогона находились вне проекта. Один из них позже стал maintainer.

Draft не превращает их в пять одинаковых голосов. Четыре реализации помимо reference были написаны по тексту без доступа к предыдущему коду и сравнивались с тестовыми векторами проекта. Документ специально отмечает: векторы не были независимыми. Реализация по тексту, межпродуктовая совместимость и production deployment — разные уровни доказательств.

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

RFC 7942 отводит Implementation Status именно такую ограниченную роль. Раздел может сообщать зрелость, покрытие, совместимость версий, лицензию и опыт. Working Group сама оценивает эти данные. Перечень кода не означает поддержки IETF, а временный раздел обычно удаляется перед публикацией RFC.

Что обнаружили уже после тега

Пятый прогон показывает проблему управления лучше любого лозунга. По описанию I-D, внешний на тот момент разработчик работал с pala1-v1.0, прошёл опубликованные тесты, добавил собственные adversarial cases и зафиксировал восемь неоднозначностей и пробел в span pairing.

Спецификация обещала, что crash оставит видимый незакрытый span, но не определяла проверку, которая одинаково покажет его во всех verifiers. Решение не стало объявлять неполный trail подделкой. Непарный span был оформлен как advisory finding. Draft называет этот прогон тем, который изменил спецификацию после заморозки, и ссылается на публичные основания решения.

Это не доказательство изменения байтов. Это доказательство того, что слово «заморожено» требует объекта. Редакционное уточнение, дополнительная диагностика, нормативная семантика, profile и новое смещение несут разные последствия. Векторы могут не измениться, хотя понимание станет точнее. А изменение поля способно сломать старый parser при прежнем замысле.

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

Замораживать только общий минимум

Спецификация проекта задаёт 156-байтовый header, TLV, типы records и hash chain. При неизвестной версии, типе или TLV verifier должен продолжить проверку цепочки, пометить record как неинтерпретируемый и не отвергать всю цепь только из-за новизны.

Для будущих версий фиксируется parsing spine: magic, version, длины, type, sequence, boot ID, предыдущий hash и body digest. Благодаря ему старый reader может найти следующий record и проверить цепь. Эта механика не замораживает навсегда каждое значение.

Profiles определяют EVENT bodies, агрегаты, источники листьев Merkle и словарь ролей. Выбор profile делает документация deployment. Это минимальная начальная спецификация: общим остаётся только то, что нужно для совместимости, а отраслевые решения сохраняются ближе к реализации.

PALA-1 столь же узко формулирует доказательства. Внутренняя целостность, полнота относительно anchor и существование относительно witness — разные вопросы. Правильная chain не доказывает правдивость recorder. Такой предел не ослабляет формат; он не позволяет техническому механизму присваивать полномочие, которого у него нет.

Короткая квитанция об изменении

Для freeze достаточно записать точный commit и tag, хэши векторов, роль решившего, дату, exit test и открытые вопросы. Поле scope выбирает между wire bytes, parsing spine, нормативной семантикой, profile, руководством и тестовым артефактом.

Каждое последующее issue получает стабильный ID, точную revision, раздел и класс: editorial, interpretation, semantic rule, profile, additive extension, vector repair или wire incompatibility. Disposition называет проектную либо IETF-роль, основание и исход: no change, clarification, advisory, profile update, extension, compatibility note, new version или deferred.

Рядом указывается эффект: видит ли v1-reader границы records, проверяет ли chain, остаётся ли v1-writer conformant, нужен ли новый profile. Исправления добавляются в историю, а не стирают первоначальное решение.

Институциональные состояния идут отдельно: individual I-D, обсуждение в названном venue, WG adoption, consensus, IESG approval, RFC publication. Maintainer отвечает за release проекта, но не говорит от имени IETF. Working Group рассматривает текст, но не получает собственность над установленной базой. Оператор может добровольно применять v1, не называя его стандартом.

RFC 2026 ставит implementation и testing рядом с техническим качеством, ясностью, открытостью, справедливостью и повторным рассмотрением. Код — обязательная дисциплина, но не короткий путь к власти.

Подход Heng Lu добавляет полезное ограничение: общий слой должен быть минимальным, слова проверяются кодом, будущие решения остаются локальными, если не ломают совместимость, а добровольное принятие не становится мандатом. Будущая проверка может подтвердить PALA-1 без изменений, потребовать уточнения, изменить profile или привести к v2. Пока это неизвестно. Известно другое: frozen не должно заменять идентичность объекта, совместимость, авторство и институциональную власть одновременно.

Источники

  1. Анонс IETF
  2. Datatracker: PALA-1
  3. История в Datatracker
  4. Архив IETF: версия 00
  5. Спецификация PALA-1
  6. Commit заморозки 50b47edb1ed8
  7. Журнал независимой проверки
  8. Тестовые векторы
  9. Архив independent runs
  10. RFC 7942: Improving Awareness of Running Code
  11. RFC 2026: The Internet Standards Process
  12. RFC Editor: How RFCs Are Created
  13. Heng Lu: Running-Code Primacy
  14. Heng Lu: Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption