Кратко

  • draft-dogru-cedulon-decision-profile-02 от 5 сентября 2026 года остаётся активным индивидуальным Internet-Draft без одобрения и формального статуса IETF, без RFC stream и ответственного Area Director.
  • Профиль сверяет подписанные Decision Records с аутентифицированными строками Effect Extract. Разрешению должен соответствовать один эффект, а отказу или отсрочке — ни одного.
  • Ревизия 02 прямо говорит, что binding не упорядочивает две шкалы времени. Время строки проверяется по окну extract, а не по времени связанного Decision Record.
  • effect-against-refusal доказывает наличие отказа и эффекта с общей ссылкой в проверяемых наборах. Он не доказывает, что эффект был позже, и не указывает место сбоя контроля.
  • Отдельная квитанция последовательности должна назвать владельцев часов, допустимый сдвиг и дополнительные свидетельства, сохранив четыре исхода: до, после, в пределах сдвига и неопределённо.

Что именно не сошлось

Datatracker указывает институциональную границу документа. Это ревизия 02 индивидуального проекта Emek Can Doğru, обновлённая 5 сентября. Подать I-D может любой; этот текст не одобрен IETF и не занимает формального положения в её процессе стандартов. RFC stream, Responsible AD и telechat date отсутствуют, состояние IESG — лишь «I-D Exists».

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

Для allow ожидается ровно одна строка с теми же ref, хешем содержания и классом эффекта. Нет строки — decision-without-effect. Есть строка без решения — effect-without-decision. Deny и defer считаются refusal и не должны иметь строки; её появление под той же ссылкой даёт effect-against-refusal.

Такое имя полезно: оно отличает эффект при явном отказе от эффекта вообще без решения. Но зафиксированный текст ревизии 02 не позволяет читать finding как готовое доказательство действия после отказа.

Более ранняя строка всё равно связывается

В Decision Record и строке эффекта есть timestampMs. Текущий алгоритм не сравнивает эти числа попарно. Строка должна находиться в [windowStartMs, windowEndMs), но её время не проверяется относительно времени отвечающей ей записи. Строка, датированная до Decision Record, связывается так же, как датированная после. Сопоставляются ссылка, содержание и класс, но не sequence.

Если эффект имеет время 10:00, а отказ — 10:01, отчёт всё равно может выдать effect-against-refusal. Эффект мог действительно случиться раньше; одни часы могли спешить; решение могло быть принято раньше, но подписано позже; время мог добавить процесс сбора после события. Расхождение наборов остаётся фактом, а исторический порядок — открытым вопросом.

Окно отвечает за другое. Одна строка за его пределами делает весь extract некорректным. Непарные элементы около границы могут быть отложены или перенесены по унаследованному правилу; companion по умолчанию использует пять минут. Это определяет состав проверки и уменьшает ложные разрывы между соседними окнами. Оно не доказывает единую синхронизацию часов Decider и канала.

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

Не превращать расхождение в обвинение

effect-against-refusal следует сохранить как результат сохранения популяций. Эффект существует под ссылкой, которую решения относят к отказу. Это основание продолжить расследование.

Draft одновременно предупреждает, что finding не локализует неисправность. Причина может быть в доставке контроля, enforcement, обходном пути или сборе доказательств. Временной язык должен быть столь же точным. «Эффект присутствует под ссылкой отказа» подтверждён. «Агент действовал после получения отказа» добавляет порядок, доставку и возможность исполнения.

От этой добавки могут зависеть эскалация инцидента, договорная ответственность и кадровое решение. Поэтому она требует своего доказательства. Принцип Heng Lu о точных записях задаёт полезное редакционное ограничение: запись описывает реальность, а не создаёт её. Здесь сверка описывает имеющиеся поля и выполненные сравнения. Она не создаёт пропущенную последовательность. Это аналитическое применение Daniel Kade, а не правило Cedulon или IETF.

Четыре исхода временной проверки

Временной результат можно поставить рядом с существующим finding. Одна пара вправе получить одновременно effect-against-refusal и sequence-indeterminate. Первый говорит о составах наборов, второй — о силе временного свидетельства.

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

Дальше достаточно четырёх ответов:

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

Монотонный счётчик, порядок событий канала, доверенная временная метка, checkpoint или независимое наблюдение могут усилить вывод. У каждого источника своя власть. Счётчик Decider не создаёт независимости; порядок канала не доказывает, когда policy достигла агента. Даже надёжное «после» показывает предшествование при явных предпосылках, но не причинность или вину.

Running code должен уметь не знать

Раздел Implementation Status в рамках RFC 7942 сообщает о двадцати conformance cases и четырёх offline fixtures в репозитории автора. Он же фиксирует пределы: ревизия 02 меняет текст и не добавляет case; порядок часов описан, но не enforced. Живой журнал канала не измерялся, независимая реализация неизвестна, публичные времена записаны постфактум без temporal precommitment.

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

Источники

  1. IETF Datatracker: Cedulon Decision Profile
  2. Архив IETF: draft-dogru-cedulon-decision-profile-02
  3. Репозиторий Cedulon companion
  4. IETF Datatracker: основной draft Cedulon
  5. RFC 7942: Improving Awareness of Running Code
  6. RFC Editor: How RFCs Are Created
  7. Heng Lu: The Bill of Rights of Uniqueness Coordination