Кратко

  • После слияния pull request 42 от 4 сентября появилась редакция 11 с необязательными временем наблюдения и сроком действия, а также эксплуатационными рекомендациями. Это рабочий Internet-Draft, а не RFC.
  • Идентификатор функции в каждом сообщении исключили сознательно: авторы выбрали офлайн-согласование при инициализации, чтобы селектор не менял алгоритм динамически.
  • Диапазон оценок, нормализация, параметры, формула, веса и направление сравнения теперь должны войти в формальный манифест, синхронизированный офлайн и поставленный под контроль версий.
  • В эксплуатации предполагается полная сопоставимость, хотя поля не содержат версии, дайджеста или эпохи манифеста. Подпись и свежесть не доказывают общий смысл.
  • Динамические переговоры не нужны. Нужны проверка общей идентичности манифеста, заранее определённая реакция на расхождение и квиток, связывающий конфигурацию с решением.

Что именно было принято

Pull request 42 влили в репозиторий CATS 4 сентября. Merge commit вошёл в фиксированный текст редакции 11. Datatracker показывает действующий документ рабочей группы со статусом IESG «I-D Exists». Это не завершённый стандарт и не свидетельство внедрения.

CATS направляет запросы к экземплярам сервиса с учётом сети и вычислительных ресурсов. Задержка, загрузка и доступная память измеряются по-разному. Нормализация приводит данные к общей шкале, агрегация формирует категории уровня 1 или глобальную оценку уровня 2. Итог зависит от границ, параметров, весов и направления сравнения.

Редакция 11 требует до развёртывания согласовать между поставщиками диапазон оценок, метод и параметры нормализации, формулу и веса агрегации, а также правило «выше лучше» или «ниже лучше». Результат должен стать формальным манифестом конфигурации, разойтись офлайн при инициализации по компонентам принятия решений и храниться по версиям.

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

Авторы видели альтернативу

В августе pull request 41 предложил передавать для значения применённую функцию, время наблюдения и интервал действия. Параметрически связанная идентичность позволила бы отличить изменение ресурса, другую формулу и просроченное наблюдение.

25 августа соавтор сообщил решение в списке CATS. Функция не должна повторяться в каждом отчёте. Детали нескольких поставщиков следует согласовать вне полосы при инициализации. Разбор идентификаторов и динамическая настройка C-PS сделали бы систему чрезмерно сложной. Два поля времени допускаются как необязательные.

Автор предложения согласился с этой границей: framework не предполагает переговоры для каждого сообщения. В редакции 11 появились Observation_Time и Validity_Interval, но не Function. Комментарий в PR 41 указывает, что PR 42 забрал два временных поля; исходный запрос оставался открытым на момент проверки.

Это не забытая графа. Это осознанная экономия сложности. Поэтому вопрос следует ставить иначе: чем доказать, что офлайн-соглашение по-прежнему одинаково на всех работающих компонентах?

Корректная подпись не устраняет разный смысл

Представим частичное обновление. Селектор и производитель поставщика A работают по M1. Производитель B уже включил M2, где изменена верхняя граница нормализации или вес категории. Оба отправляют глобальную оценку 7. Отправители разрешены, подписи верны, значения свежие. Но две семёрки могут означать разные уровни способности.

Это гипотеза о механизме, не сообщение об аварии. Поле Source различает прямое измерение, оценку, агрегацию и нормализацию. Observation_Time задаёт момент, Validity_Interval — допустимый срок. Целостность, происхождение, разрешение и свежесть защищают сообщение. Ни одна проверка не называет M1 или M2.

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

Ранняя проверка OPSDIR пометила редакцию 10 как «Has issues» и запросила руководство по межвендорному сравнению, идентификаторам политик, калибровке, сбоям, управлению и миграции. Редакция 11 исправляет многое: ограничивает обычную частоту, разрешает событийные обновления, описывает последнее хорошее значение, понижение приоритета, исключение, переход только на сеть и тревоги.

Расхождение манифестов не обязано выглядеть аномалией. Значение по M2 может быть правдоподобным для M1, а компонент со старой копией — технически исправным. Если «последнее хорошее» не сохраняет свою версию, резервный режим способен продлить неопределённость.

Доказать равенство, не раскрывая параметры

Возвращать весь алгоритм в каждое сообщение не требуется. Достаточна компактная идентичность: канонический ID и дайджест манифеста, административный домен, область компонентов, версия или эпоха активации, время вступления и состояние синхронизации.

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

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

Текущий CATS framework ограничивает систему одним административным доменом и требует общих функций. Это облегчает проверку, но не отменяет частичное развёртывание. RFC 8911 даёт ограниченный пример идентичности метрики, связанной с фиксированными параметрами. CATS может реализовать принцип иначе.

Источники

  1. Datatracker — определение метрик CATS
  2. Редакция 11
  3. Редакция 10
  4. История Datatracker
  5. Ранняя проверка OPSDIR
  6. Решение соавтора об офлайн-согласовании
  7. Ответ автора предложения
  8. Pull request 41
  9. Pull request 42
  10. Merge commit PR 42
  11. Текущий CATS framework
  12. RFC 8911
  13. Heng Lu о минимуме общих правил и локальном выборе