Кратко

  • RFC 10009 даёт повторно используемый материал YANG 1.1 для HTTP-клиентов и серверов: URI клиента, разрешённые версии, необязательные параметры TLS и прокси, серверную HTTP-конфигурацию и удобную композицию стека прослушивания.
  • Модули определяют typedef и группировки, но сами не создают доступных по протоколу узлов. Заполненная модель свидетельствует о намерении настроить систему, а не о слушателе, аутентификации, приёме запроса или наблюдаемом эффекте.

RFC 10009 полезен именно до установления соединения. Группировка ietf-http-client способна описать URI, список HTTP-версий, разрешённых локальной политикой, клиентский материал TLS и выбор прокси. ietf-http-server описывает HTTP-часть серверного стека, а отдельная удобная группировка собирает HTTP с TCP, TLS либо QUIC/UDP. Это позволяет потребляющей модели показать связную поверхность конфигурации, не превращая разные слои в один якобы установленный эксплуатационный факт.

На клиентской стороне граница особенно ясна. Единственный обязательный элемент — uri, у которого обязательны scheme и host. Scheme и authority URI несут сведения о нижележащем транспорте, но не наблюдают ответ DNS, не доказывают путь TCP или QUIC и не подтверждают решение по сертификату. protocol-versions сообщает, что разрешила конфигурация. supported-versions, доступный только для чтения, сообщает, что умеет реализация независимо от выбранной настройки. Необязательные параметры TLS могут назвать идентичность клиента и материал аутентификации сервера; поля прокси могут назвать промежуточный путь. Ничто из этого не доказывает, что конкретный партнёр будет достигнут, распознан или примет соединение. Без клиентских параметров TLS соединения TLS при этой конфигурации невозможны; с ними они всё ещё не становятся свершившимся фактом.

Серверная часть столь же ограничена. HTTP-группировка конфигурирует HTTP-часть стека, а не TCP или TLS. Группировка listen stack комбинирует HTTP поверх TCP, TLS или QUIC, сохраняя соответствующие нижние группировки. server-name, разрешённые версии и необязательное простое хранилище Basic-пользователей, включаемое функцией, — это выборы конфигурации. Они не доказывают, что процесс слушает, что порт 80 или 443 связан, что партнёр аутентифицирован, что управление паролем достаточно или что приложение разрешило действие. Аккуратная модель всё ещё может встретить отказ на каждом последующем переходе.

Ключевая фраза касается устройства самого стандарта: три модуля RFC 10009 определяют повторно используемые типы или группировки и сами по себе не определяют узлов данных, доступных по протоколу. Их должен инстанцировать потребляющий модуль. Поэтому до выполнения существуют как минимум два разных свидетельства: повторно используемый материал и конкретный проект узлов данных у потребителя. Затем требуются разрешённая запись управления, развернутая ревизия, связанный listener, результат транспорта и проверки партнёра, HTTP-обмен, допуск приложения и наблюдаемый эффект.

Свести весь путь к словам «точка настроена» — значит выдать намерение за неподтверждённый результат работы.

Полномочие настройки заканчивается раньше полномочия сервиса

Раздел безопасности сохраняет это различие. Последствия модулей, состоящих из группировок, зависят от модулей, которые их используют. Управление через NETCONF и RESTCONF требует защищённого транспорта и взаимной аутентификации; NACM может ограничивать доступ пользователя к операциям и содержимому управления. Эти механизмы отвечают на вопрос, кто читает или меняет поверхность управления. Они не дают HTTP-клиенту общего права выполнить любое прикладное действие и не превращают сохранённую конфигурацию в доказательство доставки.

Того же ограничения требует typedef HTTP-версий, поддерживаемый IANA. Реестр предоставляет общий словарь, а реализация может показать собственные возможности. Ни один из этих фактов не доказывает, что версия включена в определённой конфигурации, согласована с партнёром, принята посредником или дала полезный результат приложению. Реестр — справка, возможность — локальное заявление, работающий обмен — отдельное свидетельство.

Это редакционный вывод, а не требование IETF. Идея Heng Lu о минимальной начальной спецификации объясняет пользу малой общей прослойки: она делает части сочетаемыми и оставляет последующие решения локальными. Приоритет работающего кода даёт практический критерий: утверждение, что сервис сработал, принадлежит сверенной записи исполнения, а не одной предшествующей модели.