Кратко

  • В редакции 25 проекта GAAP рабочей группы PIM раздел 5 получил название «Illustrative GAAP API». В документе прямо сказано: GAAP — протокол, а не библиотека или Python API. Псевдокод показывает один способ интеграции; допустимы другие интерфейсы или их отсутствие при соблюдении обмена Claim на линии. Редакция 24 уже называла пример иллюстративным и ненормативным.
  • Проект также поясняет, что у Claim четыре поля, а последующие описания их использования не добавляют новых элементов. Дополнение по безопасности объясняет возможность изменения шифртекста ChaCha20 без аутентифицированной целостности. Ни новый формат пакета, ни новый запрет, ни реальное нападение из этого не следуют.

Смысл децентрализованного распределения адресов групп многоадресной рассылки не в том, чтобы все приложения были написаны одинаково. GAAP предлагает согласовать то, что разные участники передают друг другу, обходясь без единственного назначающего сервера. Публикация редакции 25 от 25 сентября 2026 года делает эту границу более заметной. В разделе с псевдокодом теперь отдельно указано, что GAAP не является Python-библиотекой: программные вызовы помогают объяснить идею, но не определяют обязательный интерфейс для совместимости.

Новизну нельзя описывать как отмену прежней обязанности применять Python. В версии 24 пример уже был ненормативным. Изменение в том, что версия 25 снимает возможное смешение двух уровней — протокола между независимыми узлами и устройства местного программного компонента. Реализация может использовать иной API либо обходиться без программного API, если выполняет правила Claim на линии. Раздельный процесс и встроенный модуль служат возможными примерами; сведения о действующих установках из этого не возникают.

В разделе 4 проводится аналогичная граница между полями записи и объяснением полей. У Claim есть групповой адрес IPv4, групповой адрес IPv6, временная метка и имя группы. Текст о применении, сравнении и разборе этих значений не означает дополнительных полей. Следовательно, редакционная правка не подтверждает появления пятого элемента, перестановки байтов или перехода уже работающей сети на иной формат. Она уточняет чтение спецификации, но не дает результатов испытаний совместимости.

Поправка о безопасности отделяет прежнее требование от новой аргументации. Редакция 24 уже говорила, что ChaCha20 без кода аутентификации сообщений не отвечает требованию целостности и не должен использоваться отдельно. Редакция 25 поясняет механизм: поточный шифр без целостности допускает управляемое изменение шифртекста. Противник на пути передачи может изменить биты, чтобы после расшифрования получились иные групповой адрес, временная метка или имя, а получатель не заметил подмены. Авторы проекта считают ложную уверенность в защите потенциально хуже явно незашифрованного базового режима.

Это оценка проектного риска, а не сообщение об обнаруженном эксплойте или пострадавшей сети.

Сопоставление двух поправок показывает, что локальная свобода и общее обязательство не противоречат друг другу. Название метода Python не доказывает правильного обмена Claim. Наличие шифрования не доказывает неизменности расшифрованных данных. Проверять надо наблюдаемое поведение удаленных участников и отдельно свойства выбранной защиты. Такой вывод — редакционная интерпретация, а не предложенная IETF программа сертификации.

В Datatracker документ остается Internet-Draft рабочей группы PIM в состоянии IESG Evaluation, AD Followup, с предполагаемым статусом Experimental. Он не стал RFC. Предыдущая статья BTW о GAAP-23 разбирала фиксированные диапазоны адресов и сходимость одноименных Claim после соединения разделенных участков сети. Редакция 25 не доказывает разрешения той проблемы. Настоящий повод другой: уточнение границ общих данных, программного примера и свидетельства целостности.

Источники