«rpc» против «action»
Разница между «rpc» и «action» заключается в том, что последний подключен к определенному узлу данных.Этот узел может служить метаданными для выполняемой операции.
Разница между действием и RPC заключается в том, что действие связано с узлом в хранилище данных, тогда как RPC нет.Когда вызывается действие, узел в хранилище данных указывается вместе с именем действия и входными параметрами.
RFC7950, раздел 7.15
Предположим, у вас есть массив элементов, каждый из которых поддерживает отдельные операции, такие как «запуск», «остановка» и «перезапуск».Когда кто-то выполняет такую операцию, он говорит что-то вроде: «Эй, пожалуйста, перезапустите только этот конкретный экземпляр элемента».Вы бы смоделировали это в YANG 1.1, используя «список» со встроенными действиями.Таким образом, когда операция выполняется, сервер точно знает, какой экземпляр вы хотите перезапустить, остановить или запустить, поскольку его уникальный идентификатор становится неотъемлемой частью полезной нагрузки <rpc> (или полезной нагрузки операции RESTCONF).
RFC7950использует пример "фермы серверов", чтобы продемонстрировать это.Каждый сервер в ферме может быть сброшен.
module example-server-farm {
yang-version 1.1;
namespace "urn:example:server-farm";
prefix "sfarm";
import ietf-yang-types {
prefix "yang";
}
list server {
key name;
leaf name {
type string;
}
action reset {
input {
leaf reset-at {
type yang:date-and-time;
mandatory true;
}
}
output {
leaf reset-finished-at {
type yang:date-and-time;
mandatory true;
}
}
}
}
}
Соответствующая полезная нагрузка NETCONF, за которой следует полезная нагрузка RESTCONF («Эй, пожалуйста, сбросьте сервер apache-1»):
<rpc message-id="101"
xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<action xmlns="urn:ietf:params:xml:ns:yang:1">
<server xmlns="urn:example:server-farm">
<name>apache-1</name>
<reset>
<reset-at>2014-07-29T13:42:00Z</reset-at>
</reset>
</server>
</action>
</rpc>
POST /restconf/data/example-server-farm:server=apache-1/reset HTTP/1.1
Host: example.com
Content-Type: application/yang-data+xml
<input xmlns="urn:example:server-farm">
<reset-at>2014-07-29T13:42:00Z</reset-at>
</input>
Обратите внимание на разницу в кодировке полезной нагрузки.Для NETCONF <rpc> для действий содержит элемент <action> в стандартном пространстве имен urn:ietf:params:xml:ns:yang:1, за которым следует ветвь элемента, идентифицирующая экземпляр узла данных, для RESTONF вместо UI /restconf/operations перед *1027* предшествует URI.
Для сравнения, rpcs - это "глобалы".Они всегда отображаются на верхнем уровне модуля YANG и могут относиться или не относиться ко всему устройству.Конечно, вы можете реализовать любое действие, используя оператор rpc, но для этого потребуется какой-то нестандартный способ предоставления ссылочного узла данных в качестве аргумента операции с помощью оператора «input».Кто-то также с большей вероятностью выполнит эту операцию на несуществующих экземплярах.
Итак, настоящей причиной введения этого утверждения было удобство.Многие реализации серверов полагались на собственные расширения YANG для поддержки того же поведения, поэтому имело смысл создать реальное ключевое слово YANG, чтобы определить его стандартным способом.
"anyxml" против "anydata"
Более новое ключевое слово теперь стало предпочтительным способом моделирования большого количества произвольных данных.
Следует отметить, что в YANG версии 1 «anyxml» был единственным оператором, который мог моделироватьнеизвестная иерархия данных.Во многих случаях эта неизвестная иерархия данных фактически моделируется в YANG, но конкретная модель данных YANG не известна во время разработки.В этих ситуациях РЕКОМЕНДУЕТСЯ использовать «anydata» (раздел 7.10) вместо «anyxml».
RFC7950, раздел 7.11
Когда RFC6020 былопубликованные, смоделированные YANG данные могут быть закодированы только в XML.Имеет смысл ввести ключевое слово, представляющее двоичный объект произвольно правильно сформированного XML.Но со временем появляются новые кодировки, такие как кодировка JSON, используемая в RESTCONF.
"anyxml" теперь имеет гораздо меньше смысла.Зачем JSON-ориентированному устройству нужно встраивать XML в свои полезные данные?Это слишком громоздко.Итак, «anydata» была введена - она моделирует блок данных, не зависящих от кодировки.Если сервер использует XML, он будет закодирован как XML, если используется JSON, он будет закодирован в JSON, если используется X, он будет закодирован в X. Единственное ограничение на эти данные состоит в том, что они могут моделироваться с помощью YANG!
Оператор anydata используется для представления неизвестного набора узлов, которые можно смоделировать с помощью YANG, кроме anyxml, но для которых модель данных неизвестна во время разработки модуля.Возможно, хотя и не обязательно, чтобы модель данных для любого содержимого данных стала известна посредством протокольной сигнализации или других средств, которые выходят за рамкинастоящего документа.
RFC7950, раздел 7.10