> On 23 Nov 2015, at 14:38, Martin Bjorklund <[email protected]> wrote:
>
> Ladislav Lhotka <[email protected]> wrote:
>>
>>> On 23 Nov 2015, at 14:09, Martin Bjorklund <[email protected]> wrote:
>>>
>>> Ladislav Lhotka <[email protected]> wrote:
>>>> Hi,
>>>>
>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>> "notification" but for these cases the specification of the context
>>>> node in sec. 7.5.3 doesn't work.
>>>>
>>>> o The context node is the node in the accessible tree for which the
>>>> "must" statement is defined.
>>>
>>> You are right. But note how the accessible tree is defined. There is
>>> a node for the operation / notification. This node should be the
>>
>> Not in rpc/action output:
>>
>> <rpc-reply message-id="101"
>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>> <reset-finished-at xmlns="http://example.net/server-farm";>
>> 2014-07-29T13:42:12Z
>> </reset-finished-at>
>> </rpc-reply>
>>
>>
>>
>>> context node:
>>>
>>> o If the "must" statement is a substatement of a "notification"
>>> statement, the context node is the node representing the
>>> notification in the accessible tree.
>>>
>>> o If the "must" statement is a substatement of a "input"
>>> statement, the context node is the node representing the
>>> operation in the accessible tree.
>>>
>>> o If the "must" statement is a substatement of a "output"
>>> statement, the context node is the node representing the
>>> operation in the accessible tree.
>>
>> In the last bullet, I don't know what the node representing the
>> operation is. In XML encoding, the request is
>>
>> <rpc ...>
>> <opname ...>
>> ...
>> </opname>
>> </rpc>
>>
>> so I understand the <opname> element is the node representing the
>> operation, but in a reply the <opname> element isn't present.
>>
>> Am I missing something?
>
> The accessible tree is the same regardless of encoding. This means
> that an implementation must (conceptually) decode the received data
> and put it in this tree. It should work with XML, JSON, and any other
> encoding we might define. So, the exact node names and structure in
> the XML encoding does not really matter.
Then I don't get what the accessible tree is. It contains instance data, and
examples in 6020bis are only given in XML, unless some extra dummy node is
added, I don't see any "node representing the operation" in RPC or action
*output*. Note that RESTCONF has the "output" node as in
HTTP/1.1 200 OK
Date: Mon, 25 Apr 2012 11:10:30 GMT
Server: example-server
Content-Type: application/yang.operation+json
{
"example-ops:output" : {
"reboot-time" : 30,
"message" : "Going down for system maintenance",
"language" : "en-US"
}
}
which could serve as the context node but no such thing is mentioned in 6020bis.
Lada
>
>
> /martin
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
