Кратко

  • BCP 139 объясняет, почему опубликованный RFC — плохой шаблон для нового проекта: его boilerplate остаётся прежним, а требования меняются.
  • При нынешнем получении URL для XML, текста с пояснениями и чистого текста завершили редирект на одном общем каталоге. Это квитанция о маршруте запроса, но не о содержательной преемственности трёх файлов.

Архив сохранил документ, но не сохранил его исходную форму

Через несколько лет группе понадобилось объяснить, почему раздел безопасности был составлен именно так. Финальный проект сохранился. Сохранились результаты компилятора. В истории обсуждения стояла ссылка на официальный шаблон. Не сохранился сам шаблон и не было его контрольной суммы.

Ссылка отвечала. Более того, отвечали все три ссылки, перечисленные на странице OPS. Однако каждая после перенаправления показывала один и тот же общий каталог авторских ресурсов. Нельзя было установить, видел ли автор XML-комментарии, текстовые подсказки или только пустой каркас.

Система сохранила результат и потеряла один из входов. Это не делает документ неправильным. Это делает часть его проверки невоспроизводимой.

RFC 5249 вынес изменчивость наружу намеренно

В 2008 году авторы часто брали уже опубликованный MIB RFC за основу. Логика понятна: прошедший проверку документ выглядит безопаснее нового шаблона. Но он фиксирует требования своего времени. Юридический boilerplate, правила Internet-Draft, требования IANA и рекомендации по безопасности могут измениться позже.

RFC 5249, он же BCP 139, указывает три поддерживаемых MIB Doctors варианта: XML2RFC с комментариями, текст с подсказками и чистый текст. Документ отмечает, что многие MUST в подсказках связаны с требованиями IESG и будут проверяться. Шаблоны предполагалось обновлять по мере изменения требований.

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

Код 200 отвечает не на вопрос о полномочиях

Современная страница OPS по-прежнему перечисляет три шаблона и упоминает обновления июня 2013 года. Исторические адреса tools.ietf.org ведут на authors.ietf.org/templates-and-schemas. Там есть общие RFCXML-шаблоны, схемы и материалы для иных форматов. Страница справедливо предупреждает, что подготовленный XML опубликованного RFC не следует превращать обратно в Internet-Draft.

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

Нужны две квитанции. Транспортная хранит начальный URL, переходы, конечный URL, время, тип, размер и hash. Квитанция полномочий показывает, какой ответственный источник объявил новый объект преемником старого. Без второй зелёный статус должен называться «доступен, идентичность не установлена».

У документа и модуля разные доказательства

RFC 5249 не предлагает шаблон самого MIB-модуля. Напротив, модуль рекомендуется разрабатывать отдельно, чтобы валидаторы получили изолированный вход, а затем включать в окружающий текст.

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

Правильные заголовки не гарантируют корректный SMIv2. Успешная компиляция не делает DESCRIPTION однозначным. Наличие Security Considerations не доказывает, что названы опасные записываемые объекты и чувствительные читаемые данные.

RFC 4181 требует свежих одобренных заготовок, но прямо выступает против слепого копирования. Если класс объектов не упомянут, это не равнозначно выводу об отсутствии риска. Инструмент проверяет синтаксис; эксперт обязан прочитать текст глазами будущего реализатора.

Узнаваемая форма — не номер версии

RFC 7367 благодарит автора шаблона Harrington, а RFC 9349 показывает более позднюю публикацию MIB-документа. Это подтверждает родословную, но не восстанавливает байты, подсказки и редиректы другой работы. RFC 8407 относится к YANG; близость областей не превращает его в неявную замену MIB-руководства.

Самая опасная страховка — локальная копия. Она воспроизводима, поэтому кажется надёжной. Но без сравнения с текущим источником она постепенно становится тем самым старым прецедентом, от которого защищал BCP.

Шаблон следует учитывать как зависимость сборки: фиксировать на время проверки, хранить hash, сравнивать обновления и повторно открывать только затронутые решения. Человеческая ссылка «последняя версия» может двигаться; вход завершённой проверки должен оставаться неизменным.

В манифест входят политика, имя и ревизия шаблона, издатель, путь, время и hash, цепочка редиректов, hash модуля, валидатор и его версия, результат и исключения, объекты из анализа безопасности, эксперт и решение.

Так работает дисциплина reality layer из заметок Lu Heng. Шаблон координирует текст, но не доказывает модуль. Валидатор наблюдает форму, но не доказывает эксплуатацию. Публикация стабилизирует спецификацию, но не создаёт одинаковое поведение реализаций. Каждому уровню положены только его собственные полномочия.

Источники