Ян пути выражения для ссылки на узлы данных и узлы схемы и т. д.

Question

Рассмотрим следующий модуль ян

module mod {
    yang-version 1;
    namespace "http://example.com/mod";
    prefix m;
    revision "2016-09-09" {
       description "Initial revision.";
    }
    container foo {
        description 'container foo';
        leaf l {
            type string;
        }
    }
}

Какое выражение пути является правильным в достижении листа l?

/mod:foo/l
/m:foo/l
/foo/l

Если в моем приложении активны 2 ревизии одного и того же модуля, как клиент выражает, какой узел ревизии ему интересен?

и есть ли доступное выражение пути для ссылки на "описание" листа l?

Answer 1

Какое выражение пути является правильным в достижении листа l?

В контексте RESTCONF GET используется схема, описанная в draft-ietf-netconf-restconf-16, раздел 3.5.3, Кодирование идентификаторов ресурса данных в URI запроса.

Идентификатор ресурса данных RESTCONF кодируется слева направо, начиная с узла данных верхнего уровня, в соответствии с правилом "api-path" в разделе 3.5.3.1. Имя узла каждого предка целевого узла ресурса кодируется по порядку, заканчиваясь именем узла для целевого ресурса. Если узел в пути определен в другом модуле, чем его родительский узел, или его родитель является хранилищем данных, тогда имя модуля, за которым следует символ двоеточия (":"), ДОЛЖНО быть добавлено перед именем узла в идентификаторе ресурса. Подробнее см. Раздел 3.5.3.1.

Поэтому правильный URI будет примерно таким:

/restconf/data/mod:foo/l

Если в моем приложении активны 2 ревизии одного и того же модуля, как клиент выражает, какой узел ревизии ему интересен?

Вы не можете выразить такой запрос. Это одна из причин, по которой серверу разрешено реализовывать только одну ревизию модуля YANG. В YANG 1.1 это явно запрещено, а в YANG 1.0 это только подразумевается. Обратите внимание, что соответствующие реализованные модули YANG могут ссылаться (импортировать) несколько ревизий одного и того же модуля, но только одна из них может быть объявлена ​​как реализованная (возможно, самая новая). Так как правила обновления модуля довольно строги, определения не просто пропадут в новой версии модуля, поэтому клиенты в безопасности.

есть ли доступное выражение пути для ссылки на "описание" листа l? Мой вариант использования для "описания", что-то вроде этого. Клиент отправляет модуль ян на сервер. Клиент хочет убедиться, что сервер правильно видит структуру. Клиент говорит: "покажи мне описание этого листа" или "что такое лист по умолчанию" и т. Д.

Вы, кажется, неправильно понимаете роль модели ЯНГ. Клиент не управляет моделью сервера, он может управлять только данными, описанными в этой модели! Такая вещь находится в домене сервера и его сопровождающего.

Единственный стандартный способ запроса модели YANG (которую я знаю), а не данных, смоделированных ею, состоит в том, чтобы получить файл YANG/YIN с сервера (get-схема), а затем проанализировать его самостоятельно.

Как примечание стороны. Клиент, который реализует ваш модуль и получает действительный ответ от сервера, по сути знает, какое описание сопоставлено с каким элементом XML / объектом JSON, потому что он уже сделал "отображение" между документом экземпляра и моделью (схемой) во время проверки. фаза.