Internet Engineering Task Force (IETF) E. Voit Request for Comments: 7923 A. Clemm Category: Informational A. Gonzalez Prieto ISSN: 2070-1721 Cisco Systems June 2016
Requirements for Subscription to YANG Datastores
Требования к подписке на хранилища данных YANG
Аннотация
Этот документ задаёт требования к службам, позволяющим клиентам подписываться на обновления хранилищ данных YANG. На основе критериев, согласованных в рамках подписки, обновления выталкиваются целевым получателям. Такая возможность избавляет от необходимости периодически опрашивать хранилища данных YANG из приложений и заполняет функциональные пробелы имеющегося транспорта YANG (т. е. NETCONF и RESTCONF). Такие услуги можно охарактеризовать как сервис pub/sub для обновлений хранилищ данных YANG. Кроме набора базовых требований к сервису рассмотрены разные уточнения, включая периодичность обновлений объектов, фильтрацию объектов запрошенной ветви, гарантии QoS при доставке.
Статус документа
Документ не относится к категории Internet Standards Track и публикуется лишь для информации.
Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Не все документы, одобренные IESG претендуют на статус Internet Standard. Дополнительную информацию о стандартах Internet можно найти в разделе 2 в RFC 7841.
Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке http://www.rfc-editor.org/info/rfc7923.
Авторские права
Авторские права (Copyright (c) 2016) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.
К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).
1. Введение
Приложениям, взаимодействующим с хранилищами данных YANG, нужны возможности, выходящие за рамки традиционной модели клиент-сервер для настройки сети. Одним из классов таких приложений являются приложения обеспечения услуг, которым требуется непрерывное представление рабочих данных и состояния. Другим классом являются приложения защиты, которые должны непрерывно отслеживать изменения в элементах сети для поддержки соответствия корпоративной политике.
Периодическая выборка данных не является адекватным решением для приложений, требующих частого или быстрого обновления состояний удалённых объектов. Применение основанных на опросах решений сильно загружает сети, устройства и приложения. Кроме того, такие решения не справляются с отказами в сети и ограничены по возможностям синхронизации и калибровки интервалов извлечения данных через сеть. Эти ограничения можно преодолеть с помощью базовых механизмов подписки на объекты в элементах сети и разрешения применять эти механизмы в контексте данных, которые концептуально содержатся в хранилищах YANG.
В этом документе собраны требования к таким подпискам в разных сценариях развёртывания.
2. Потребности бизнеса
Десятилетиями доставка сведений о текущем состоянии сети выполнялась путём выборки из эксплуатационных интерфейсов или по специализированным, настраиваемым сетевым протоколам. С ростом инфраструктур централизованного управления (оркестровки), императивного распространения правил и продвижением YANG в качестве языка моделирования для применения в программируемых интерфейсах к сетевым элементам такого смешения выборки и разнообразных сетевых протоколов стало недостаточно. Требуется механизм выталкивания (push), способный доставлять сведения об изменениях объектов, когда они возникают.
Такие механизмы распространения с выталкиванием не заменяют имеющиеся сетевые протоколы,а дополняют их, обеспечивая другие характеристики времени отклика, партнёрства, расширяемости и безопасности.
Push-решения не обеспечат все имеющиеся потребности операционной инфраструктуры. SNMP и базы MIB сохранятся и будут использоваться во многих системах мониторинга, однако некоторые функции могут быть перенесены. Возможно, самым большим недостатком SNMP для приложений является необходимость полагаться на периодические опросы, поскольку это дополнительно нагружает сеть и устройства и не обеспечивает устойчивости к пропускам циклов опроса, а также сложно синхронизируется и калибруется через сеть. Если приложения могут применять лишь опросы хранилищ YANG, аналогичные проблемы возникают и для них.
2.1. Pub/Sub на интерфейсе с системой маршрутизации (I2RS)
Различные документы об интерфейсе с системой маршрутизации (Interface to the Routing System или I2RS) подчёркивают необходимость предоставления возможностей публикации-подписки (pub/sub) между элементами сети. По всему документу присутствуют ссылки на [RFC7921], начиная с параграфа 6.2, примеры которых приведены ниже.
-
В параграфе 7.6 [RFC7921] приведено руководство верхнего уровня для pub/sub (уведомления).
-
В параграфе 6.4.2 [RFC7921] описана подписка на поток сведений об изменениях маршрутизации и получение уведомлений о включении (up) и отключении (down) соседей.
-
В параграфе 6.3 [RFC7921] отмечено, что при вытеснении I2RS локальной конфигурацией могут потребоваться внешние уведомления.
Аналогичные требования указаны в [USECASE] и часть их приведена ниже.
-
L-Data-REQ-12. Интерфейсам I2RS следует поддерживать подписку пользователей на данные с указанием синхронной или асинхронной отправки данных через зарегистированные подписки.
-
L-DATA-REQ-07. Интерфейсу I2RS (протокол и мгновенные сообщения – IM) следует разрешать подписчикам выбор частей модели данных.
-
PI-REQ01. Мониторинг доступных маршрутов в базе маршрутных сведений (Routing Information Base или RIB) каждого устройства пересылки, включая уведомления об установки и удалении маршрутов практически в реальном времени.
-
BGP-REQ10. Клиентам I2RS следует быть способными инструктировать агентов I2RS для уведомления клиента при обнаружении процессами BGP связанной системы маршрутизации изменения маршрутов к конкретному набору префиксов IP и связанных префиксов… Агенту I2RS следует поддерживать возможность уведомления клиентов через механизм публикации или подписки.
-
IGP-REQ-07. Интерфейсу I2RS (протокол и IM) следует поддерживать механизм для подписки клиентов I2RS на уведомления агента I2RS о критических событиях на узлах IGP.
-
MPLS-LDP-REQ-03. Для уведомлений от агента I2RS следует поддерживать для клиентов I2RS возможность подписки на поток изменений состояния, связанных с сессиями LDP или путями с коммутацией по меткам LDP (LDP Label Switched Path или LSP).
-
L-Data-REQ-01. Система I2RS должна быть способна собирать большие наборы данных из сети с высокой частотой и разрешением при минимальном воздействии на процессоры и память устройств.
В параграфе 7.4.3 [RFC7922] также указано требование pub/sub.
-
Агенты I2RS должны поддерживать публикацию сведений журнала трассировки I2RS в канале для подписки как описано [в этом документе]. Подписчики будут получать прямую трансляцию взаимодействий I2RS в формате журнала трассировки и смогут гибко выбирать действия по сообщениям из журнала.
2.2. Варианты Pub/Sub на элементах сети
Этот документ предназначен для выполнения требований, выходящих за рамки I2RS. В прошлом можно увидеть много протоколов коммутации и маршрутизации, явно или неявно использовавших публикацию и подписку. Сейчас коммутаторах и маршрутизаторах появляются новые механизмы уведомления о правилах. Ниже указаны некоторый из прошлых и современных механизмов подписки.
-
Организация групповой топологии перед доставкой содержимого конечным точкам (IGMP, PIM и т. п.).
-
Защищённые автоматизация и непрерывный мониторинг (Secure Automation and Continuous Monitoring или SACM) разрешают подписку на устройства, которые затем могут выталкивать спонтанные изменения в своих аппаратных и программных настройках [SACMREQ].
-
В MPLS VPN [RFC6513] граничные маршрутизаторы клиентов (Customer Edge) обмениваются управляющими сообщениями PIM с граничными устройствами провайдера (Provider Edge или PE) до организации маршрутной смежности [RFC6513].
-
После организации смежности OSPF начинается анонсирование состояний каналов (Link State Advertisement) [RFC2328].
В этих примерах следует отметить разнообразие базового транспорта. Обобщенный механизм публикации и подписки следует структурировать для поддержки разных вариантов транспорта. Еа основе текущих требований I2RS протоколу NETCONF следует быть изначально поддерживаемым транспортом из-за потребности в ориентированных на соединения индивидуальных (unicast) взаимодействий. В конечном итоге потребуется также поддержка групповой и широковещательной подписки на распространение обновлений.
2.3. Имеющиеся обобщённые реализации Pub/Sub
TIBCO, RSS, CORBA3 и другие технологии являются предшественниками pub/sub. Однако имеются новые потребности (4. Требования), которые эти технологии не удовлетворяют, поэтому нужна новая технология.
Есть по меньше мере две широко распространённые реализации pub/sub, которые близки к текущим потребностям, – расширяемый протокол сообщений и присутствия (Extensible Messaging and Presence Protocol или XMPP) [XEP-0060] и служба распространения данных (Data Distribution Service или DDS) [OMG-DDS]. Оба служат подтверждением возможности реализации хорошо расширяемого распределенного хранилища данных, соединяющего миллионы узлов.
/ти подтверждения дают уверенность в том, что базовые технологии могут позволить распространение многократно используемых обобщённых объектов YANG. Нужен анализ для оценки скорости и масштабов такого распространения объектов для ветвей разного размера и различных типов транспорта.
3. Терминология
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119]. Хотя документ не является спецификацией протокола, указание уровней требований разъясняет разработчикам протоколов, как создать решения, соответствующие документу.
Подписчик (Subscriber) делает запросы для наборов объектов данных YANG.
Издатель (Publisher) отвечает за распространение объектов данных YANG в соответствии с условиями подписок. Обычно издатель является владельцем хранилища данных YANG, но которое организуются подписки.
Получатели (Receiver) являются целью выталкивания объектов издателем. Обычно получатель и подписчик являются одной сущностью. Служба подписки (Subscription Service) обеспечивает для них подписки на данные YANG. Служба подписки взаимодействует и издателем данных YANG для предоставления данные в соответствии с подписками.
Запрос подписки на одну или несколько ветвей YANG (включая отдельные листья) выполняется подписчиком к издателю и нацелен на получателя. Подписка может включать ограничения на частоту и условия передачи обновлений данных YANG. Подписка является соглашением между службой подписки и подписчиком, определяющим данные, которые нужно выталкивать, и связанные с этим условия.
Хранилища данных определены в [RFC6241].
Обновление (Update) представляет изменения объектов, которые произошли в интересующих ветвях YANG. Обновление может включать текущий статус экземпляров узлов данных, для которых фильтры указывают отличие от переданного прежде состояния. Обновление может включать включать связанный набор упорядоченных (последовательных) изменений данного объекта, произошедших с момента предыдущего обновления.
Фильтр содержит критерии соответствия, которые применяются к объектам YANG в рамках подписки. Имеется два типа фильтров – фильтры ветвей (Subtree Filter), указывающие выбранные объекты и узлы, опубликованные в целевом узле данных, и фильтры элементов и атрибутов, которые выбирают лишь объекты, свойства которых соответствуют критериям фильтрации.
4. Требования
Многие требования в этом разделе заимствованы из спецификаций XMPP [XEP-0060] и DDS [OMG-DDS].
4.1. Допущения о поведении подписчиков
Этот документ описывает требования к службам подписки, на задавая требоаний для подписчиков и издателей. Однако для определения желаемого поведения службы подписки важно задать некоторые ограничения на входе.
Подписчикам следует избегать попыток организации нескольких подписок на одни и те же сведения (т. е. из тех же ветвей хранилища YANG). Подписчик может указать критерии качества обслуживания (QoS) службе подписки. Если служба не соответствует этим критериям, организовывать подписку не следует.
Когда подписчик и получатель представляют одну сущность и транспортная сессия теряется или разрывается, подписчик должен восстановить созданные ранее подписки путём сигнализации через транспортную сессию. Т. е. не требуется, чтобы срок жизни указанных сигналами подписок превышал срок действия транспортной сессии.
Подписчик должен быть способен сделать вывод о неактивности службы подписки, когда обновления больше не приходят. Подписчик может проверить службу подписки, чтобы подтвердить её наличие и мониторинг ветвей дерева. Подписчик должен быть способен периодически арендовать и продлевать подписку в Subscription Service.
4.2. Требования к службам подписки
4.2.1. Общие требования
Служба подписки должна поддерживать создание, обновление, тайм-аут и прерывание подписки.
Служба подписки должна быть способна be able to support and independently track multiple subscription requests by the same Subscriber.
Служба подписки Служба подписки может быть способна поддерживать добавление, изменение, удаление подписок на несколько ветвей YANG в одном запросе на подписку.
Служба подписки должна поддерживать подписки на рабочие и конфигурационные хранилища данных.
Служба подписки должна быть способна поддерживать фильтры для выбора рабочих и/или конфигурационных данных.
Служба подписки может включать фильтры, заданные в запросе на подписку, при этом она должна публиковать лишь узлы данных, соответствующие заданному для подписки фильру.
Служба подписки должна поддерживать возможность периодической подписки. Интервал для подписки должен быть настраиваемым через запрос подписки.
Службе подписки следует поддерживать возможность подписки на уведомления при изменении (on-change), т. е. в случаях изменения объектов данных в подписке. Для частых обновлений при изменении служба подписки должна поддерживать период демпфирования между передаче последовательных обновлений при изменении. Период демпфирования следует делать настраиваемым через запрос подписки.
Служба подписки должна поддерживать мониторинг подписчиков. В частности, она должна поддерживать хотя бы минимальные сведения об обслуживаемых подписчиках, условиях их подписок (например, набор данных, фильтры, политика обновления) и общее состояние подписки (активна или приостановлена).
Служба подписки должна поддерживать прерывание подписки по запросу подписчика.
Службе подписки следует поддерживать возможность приостановки подписки по запросу клиента.
Служба подписки может по своему усмотрению приостанавливать имеющуюся подписку. Причинами могут служить ограничения ресурсов, завершение срока действия свидетельств, потеря связности с получателем, команда оператора через интерфейс CLI и пр. В таких случаях служба подписки должна уведомлять подписчика и обновлять статус подписки.
Служба подписки может предоставлять возможность изменения фильтра подписки. В таком случае служба должна показывать подписчикам, в какой момент изменённые фильтры вступили в силу.
4.2.2. Согласование
Служба подписки должна быть способна согласовать условия подписки:
-
политику (периодически или при изменении);
-
интервал при периодической публикации;
-
интервал демпфирования для уведомлений при изменении (если поддерживается политика on-change);
-
фильтры, связанные с ветвями подписки.
Службе подписки следует поддерживать согласование критериев QoS для подписки. Примеры критериев QoS включают настройку надёжности подписки, время между фиксацией изменения ветви или объекта YANG и выталкиванием обновления, способность службы подписки проверять живучесть объекта.
Если запрос на подписку не может быть принят из-за нехватки ресурсов платформы, службе подписки следует включать в отказ советы по параметрам, которые позволят выполнить последующий запрос на подписку. Например, если запрошены слишком частые обновления для заданного набора данных, издатель может указать приемлемый интервал обновления. При запросе обновлений по изменению со слишком агрессивным интервалом демпфирования может возвращаться приемлемый интервал демпфирования или указание поддержки лишь периодических обновлений для запрошенных объектов.
4.2.3. Распространение обновлений
При подписке на изменения служба подписки должна передавать лишь различия (delta) возникшие для объектов, иначе подписчик может не узнать, что изменилось на деле. Обновления для каждого объекта должны указывать, был ли он удалён, создан или изменён.
Когда служба подписки не способна передавать уведомления в соответствии с соглашением о подписке, подписчики должны уведомляться, а подписка – переводиться в состояние, указывающее приостановку подписки. Когда обслуживание может быть продолжено, подписчиков нужно уведомить об этом. Если обслуживание нельзя восстановить, служба подписки может прервать подписку и уведомить подписчиков.
Когда подписка on-change приостановлена, а затем возобновлена, в первое обновление следует включать все изменения, произошедшие за время приостановки указанием текущего значения. Служба подписки должна предоставлять чёткое указание, когда эта возможность не поддерживается (в этом случае клиенту может потребоваться синхронизировать состояние отдельно).
Несколько объектов, выталкиваемых подписчику (возможно, из разных подписок), следует объединять в одно обновление.
Передачу уведомления недопустимо задерживать сверх Push Latency любого из вложенных объектов.
Передачу уведомления недопустимо задерживать сверх интервала демпфирования любого из вложенных объектов.
Уведомления недопустимо передавать до завершения интервала демпфирования любого из вложенных объектов.
Служба подписки может поддерживать в качестве опции возможность воспроизведения для передачи получателю последовательности обновлений за предшествующий интервал времени.
4.2.4. Транспорт
Обновления от службы подписки могут передаваться с применением разных типов транспорта, таких как NETCONF, RESTCONF, HTTP. Помимо имеющихся транспортных протоколов служба подписки будет применима и для новых транспортных протоколов, таких как заданы в [USECASE]. Транспортная гибкость задаёт ряд требований.
-
Службе подписки следует поддерживать различные транспортные протоколы.
-
Службе подписки следует поддерживать разное кодирование содержимого.
-
Получатели должны иметь возможность связать обновление с конкретной подпиской.
-
Для ориентированного на соединения транспорта следует прерывать подписку при разрыве соединения. Подписчик может запросить новую подписку.
4.2.5. Требования безопасности
В некоторых случаях служба подписки будет передавать приватные обновления и метаданные. Для таких систем сведения подписки должны быть связаны с защищёнными механизмами транспорта с шифрованием. Например, при использовании транспорта NETCONF решение [RFC7589] обеспечивает приемлемую защиту доставляемой информации. Службы подписки могут также применяться в чувствительном к приватности контексте. Например, системы на основе [USECASE] будут применять эти требования в сочетании с указанными в [I2RS-ENV-SEC] и [I2RS-PROT-SEC] для защиты эфемерных сведений о состоянии сетевых элементов.
При организации подписки должна применяться взаимная аутентификация между подписчиком и службой подписки.
Подписчикам недопустимо принимать на себя роль службы подписки.
Должны поддерживаться любые версии протоколов подписки, чтобы можно было раскрыть возможности и ожидаемое поведение реализаций конкретных технологий.
Подписка может применяться в попытке получить сведения, для которых получатель не имеет права доступа. Поэтому важно, чтобы для передаваемых по подписке данных применялась проверка полномочий как при обычных операциях извлечения. Выталкиваемые клиенту данные должны подобающим образом фильтроваться как при извлечении по запросу. Для индивидуального (unicast) транспорта применяется модель управления доступом NETCONF.
Дополнение и изменения в структуре ветви с подпиской, включая сведения о новых ветвях, должны проверяться методами контроля доступа перед отправкой обновлений.
При потере аутентифицированного доступа к целевой ветви или узлу подписчику следует передавать уведомление.
При любом обмене шифрованной информацией должны быть доступны механизмы защиты соответствующей строгости и эти механизмы следует применять. Это включает все этапы подписки и выталкивания обновлений.
Для запросов на подписку, включая создание, прерывание, приостановку и возобновление должна применяться подобающая проверка подлинности.
Когда подписчик не совпадает с получателем, последний должен быть способен прервать любую подписку, где объекты доставляются с применением индивидуального (unicast) транспорта.
Службе подписки следует отвергать запросы на подписку, если существует вероятность истощения её ресурсов. Предпочтительно сразу отклонить подписку, чем позднее прерывать её преждевременно.
Когда подписчик не совпадает с получателем и базовое транспортное соединение передаёт свидетельства (credential) в процессе его организации, потенциально выталкиваемые объекты должны исключаться из обновления, если для них у получателя нет видимости (доступ для чтения).
4.2.6. QoS для подписки
Службе подписки следует поддерживать возможность согласования для подписки параметров QoS с подписчиком (демпфирования, надёжность, срок действия, объединение).
Службе подписки следует поддерживать возможность интерпретации параметров QoS для подписки и организовывать подписку лишь при наличии возможности соблюдать запрошенные параметры QoS.
4.2.6.1. Живучесть
Служба подписки должна быть способна отвечать на запросы о живучести (Liveliness) подписки.
Служба подписки должна быть способна информировать подписчика об отслеживаемых в настоящее время узлах.
4.2.6.2. Демпфирование
Служба подписки должна быть способна согласовать минимальный вариант между передачей двух последовательных обновления для того, чтобы ограничить получателю видимость изменчивости чего-либо.
4.2.6.3. Надёжность
Служба подписки может передавать обновления с использованием гарантированного и Best Effort транспорта.
4.2.6.4. Когерентность
Для конкретной подписки обновления объектов из подписки должны передаваться получателю в порядке изменений.
4.2.6.5. Представление
Служба подписки может поддерживать объединение набора дискретных уведомлений в одно публикуемое обновление для подписки. Группа может включать сведения о разных узлах данных и/или несколько обновлений для одного узла.
Для групповых обновления служба подписки должна предоставлять получателю сведения для восстановления порядка и времени обновлений.
4.2.6.6. Срок действия
Служба подписки должна быть способна выталкивать обновления регулярно на основе заданных подписчиком временных меток начала и конца. Регулярные обновления могут включать одно обновление, а также заданное или неограниченное число периодических обновлений.
4.2.6.7. Задержка выталкивания
Службе подписки следует поддерживать возможность задержки обновления на заданное подписчиком время.
Административный объект должен иметь возможность задать задержку между изменением объекта в отслеживаемой ветви и выталкиванием службой подписки уведомления об этом изменении.
4.2.6.8. Относительный приоритет
Службе подписки следует поддерживать относительную приоритизацию подписок, чтобы выталкивание из очереди и отбрасывание push-уведомлений могло учитывать приоритет при недостатке пропускной способности между издателем и получателем.
4.2.7. Фильтрация
Если критерии фильтрации не заданы или выполнены, обновления для объектов подписки должны выталкиваться в соответствии с параметрами QoS для подписки.
Служба подписки должна иметь возможность получать фильтры от подписчика и применять их к соответствующим объектам подписки. Должна обеспечиваться возможность присоединить к подписке обну или несколько ветвей или элементов с атрибутами фильтрации. Обязательные типы фильтров включают:
-
для символьных свойств объектов – совпадение или несовпадение с указанной строкой, а также её включение;
-
для численных свойств объектов — выражения =, !=, <, <=, >, >=.
Следует обеспечивать возможность фильтрации по нескольким свойствам указанного объекта и применения к одному объекту нескольких фильтров.
Следует обеспечивать возможность запроса критериев сопоставления для дополнительных объектов, используемых вместе с критериями фильтрации объектов подписки. (например, если объект A изменён и B=1, то A выталкивается.) Сопоставление с объектами хранилища может выполняться даже при отсутствии таких объектов в подписке при условии, что подписчик имеет доступ к таким объектам.
Для обновлений при изменении объект должен проходить через фильтр, если он был изменён после предыдущего обновления. Это включает неоднократные изменения, возвращающие переданное в последнем обновлении значение.
4.2.8. Обеспечение и мониторинг
Должна обеспечиваться возможность узнать состояние отдельной подписки от службы подписки.
Должна обеспечиваться возможность узнать состояние всех подписок конкретного подписчика.
Должна обеспечиваться возможность узнать состояние список и состояние всех запросов на подписку в интервале времени. Если при этом возникает отказ, это может быть обусловлено несколькими причинами.
-
Представлены некорректные свидетельства защиты (безопасности) для доступа к целевому узлу.
-
Указанного узла не существует.
-
Запрошенный тип подписки не поддерживается для целевого узла.
-
Нехватка или недоступность ресурсов.
-
Неполное согласование с подписчиком.
5. Вопросы безопасности
С этим документов не связано вопросов безопасности сверх отмеченных в параграфе 4.2.5.
6. Литература
6.1. Нормативные документы
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., “Network Configuration Protocol (NETCONF)”, RFC 6241, DOI 10.17487/RFC6241, June 2011, <http://www.rfc-editor.org/info/rfc6241>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., “Multicast in MPLS/BGP IP VPNs”, RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, “Using the NETCONF Protocol over Transport Layer Security (TLS) with Mutual X.509 Authentication”, RFC 7589, DOI 10.17487/RFC7589, June 2015, <http://www.rfc-editor.org/info/rfc7589>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, “An Architecture for the Interface to the Routing System”, RFC 7921, DOI 10.17487/RFC7921, June 2016, <http://www.rfc-editor.org/info/rfc7921>.
[RFC7922] Clarke, J., Salgueiro, G., and C. Pignataro, “Interface to the Routing System (I2RS) Traceability: Framework and Information Model”, RFC 7922, DOI 10.17487/RFC7922, June 2016, <http://www.rfc-editor.org/info/rfc7922>.
6.2. Дополнительная литература
[I2RS-ENV-SEC] Migault, D., Ed., Halpern, J., and S. Hares, “I2RS Environment Security Requirements”, Work in Progress, draft-ietf-i2rs-security-environment-reqs-01, April 2016.
[I2RS-PROT-SEC] Hares, S., Migault, D., and J. Halpern, “I2RS Security Related Requirements”, Work in Progress4, draft-ietf-i2rs-protocol-security-requirements-06, May 2016.
[OMG-DDS] Object Management Group (OMG), “Data Distribution Service for Real-time Systems, Version 1.2”, January 2007, <http://www.omg.org/spec/DDS/1.2/>.
[SACMREQ] Nancy, N. and L. Lorenzin, “Security Automation and Continuous Monitoring (SACM) Requirements”, Work in Progress5, draft-ietf-sacm-requirements-13, March 2016.
[USECASE] Hares, S. and M. Chen, “Summary of I2RS Use Case Requirements”, Work in Progress, draft-ietf-i2rs-usecase-reqs-summary-02, March 2016.
[XEP-0060] Millard, P., Saint-Andre, P., and R. Meijer, “Publish-Subscribe”, XSF XEP-0060, July 2010, <http://xmpp.org/extensions/xep-0060.html>.
Благодарности
Спасибо Ambika Tripathy и Prabhakara Yellai за полезный вклад, комментарии и предложения, а также Nancy Cam Winget, Ken Beck, David McGrew за полезные сведения о сквозном системном контексте.
Адреса авторов
Eric Voit Cisco Systems Email: evoit@cisco.com Alexander Clemm Cisco Systems Email: alex@cisco.com Alberto Gonzalez Prieto Cisco Systems Email: albertgo@cisco.comПеревод на русский язык
Николай Малых
1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.
2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.
3Common Object Request Broker Architecture.
4Опубликовано в RFC 8241. Прим. перев.
5Опубликовано в RFC 8248. Прим. перев.