Subject: Re: [netmod] Y02: context node

From: Jernej Tuljak <[email-masked]>
Date: Wed, 16 Dec 2015 13:36:12 +0100

Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> Ladislav Lhotka <[email-masked]> wrote:
>> Hi,
>>
>> I'd like to resolve this issue. Here is a complete example (valid, I believe):
>>
>> module context {
>>    namespace "http://example.com/context";
>>    prefix ctx;
>>
>>    leaf foo {
>>      config false;
>>      type uint32;
>>    }
>>    rpc oper {
>>      output {
>>        must "/foo mod foo = 0";
>>        leaf foo {
>>          type uint32;
>>        }
>>      }
>>    }
>> }
>>
>> 1. What does the accessible tree look like?
> Note that the anser to this depends on the outcomne of Y04.  Andy has
> strong objections to Y04-02, and proposed Y04-04 instead.
>
> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
> result has foo = 10, the accessible tree would look like this:
>
>     <root>
>       +-- oper
>       |   +-- foo = 10
>       +-- foo = 20
>
>
> (If we instead move back to Y04-04, the accessible tree would be:
>
>     <root>
>       +-- oper
>           +-- foo = 10
>
> )
>
>> 2. What is the context node for the "must" expression?
>   /oper

This change to the accessible tree (1.0 --> 1.1) may break some existing 
"when" XPath expressions (those under "output" statement). Is this 
compatible with 1.1 charter - "All compliant YANG 1.0 modules must be 
accepted as compliant YANG 1.1 modules"?

   rpc my-rpc {
     output {
       uses my-stuff {
         when "specific-param = 'foo'";// 1.0
// when "my-rpc/specific-param = 'foo'" // 1.1
       }
       leaf specific-param {
         type string;
       }
     }
   }

Jernej

>
> /martin
>
>
>
>> Thanks, Lada
>>
>> Martin Bjorklund <[email-masked]> writes:
>>
>>> Ladislav Lhotka <[email-masked]> 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
>>> 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.
>>>
>>>
>>> /martin
>> -- 
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Dec 2015 13:48:55 +0100 (CET)

Jernej Tuljak <[email-masked]> wrote:
> This change to the accessible tree (1.0 --> 1.1) may break some
> existing "when" XPath expressions (those under "output" statement).

Maybe.  The old text said:

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.

So this probably meant that for this definition:

  module ex {
    ...
    prefix x;
    ...
    rpc foo {
      output {
        leaf bar { ... }
      }
    }
  }

The accessile tree was:

   nc:rpc-reply
     +-- x:bar

This is very NETCONF-specifc.  With 1.1, the tree would be:

   x:foo
     +-- x:bar

which is protocol-neutral.

> Is
> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> must be accepted as compliant YANG 1.1 modules"?
> 
>   rpc my-rpc {
>     output {
>       uses my-stuff {

This is not correct.  If a relative path is used, it would be the same
in 1.0 and 1.1.

If an absolute path is used, it would be:

   when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
   when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1

I wonder if any implementation of 1.0 supports this absolute form.

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 16 Dec 2015 14:08:08 +0100

> This is not correct.  If a relative path is used, it would be the same

I disagree due to current text:

    o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list, anydata, and
       anyxml.

    o  If the XPath expression is defined in a substatement to an
       "output" statement in an "rpc" or "action" statement, the
       accessible tree is the RPC or action operation instance, all state
       data in the server, and the running configuration datastore.  The
       root node has top-level data nodes in all modules as children.
       Additionally, for an RPC, the root node also has the node
       representing the RPC operation being defined as a child.  The node
       representing the operation being defined has the operation's
       output parameters as children.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.
       The accessible tree is tentatively altered during the processing
       of the XPath expression by removing all instances (if any) of the
       nodes added by the "uses", "choice", or "case" statement.

It clearly says that the context node is the root node ("/"), not the 
node representing the RPC ("/my-rpc"), which is a child to root node. 
The "root node" aka "document root" can only mean a single thing  XPath 
terminology.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Dec 2015 15:10:48 +0100

> On 16 Dec 2015, at 14:08, Jernej Tuljak <[email-masked]> wrote:
> 
> It clearly says that the context node is the root node ("/"), not the node representing the RPC ("/my-rpc"), which is a child to root node. The "root node" aka "document root" can only mean a single thing XPath terminology.

RFC 6020 clearly says that the tree is the rpc reply instance document, so it is a different document whose root node coincides with <rpc-reply>. The problem of 6020bis is that we need a definition that's independent of XML, and that's not so easy, but I agree with Martin that nothing should change for relative paths.

Lada

---

From: Jernej Tuljak <[email-masked]>
Date: Wed, 16 Dec 2015 16:17:44 +0100

> RFC 6020 clearly says that the tree is the rpc reply instance document, so it is a different document whose root node coincides with <rpc-reply>. The problem of 6020bis is that we need a definition…

I'm not against the new accessible tree. That nothing should change for 
relative paths is a given, IMO. So what about absolute location paths?

The previous accessible tree for a "when" expression under "output" was:

<root>
   +- x:bar

and now it is:

<root>
   +- x:foo
     +- x:bar

The absolute path to "x:bar" was:

/x:bar

and is now:

/x:foo/x:bar

and this needs to be taken into account for at least relative paths to 
stay the same. Again, the root node is "/" in any case. So the context 
node needs to be set explicitly "/x:foo" for this corner case. I dare 
say it is not even a corner case. There is a similar YANG pattern to my 
"my-rpc" example in ietf-netconf-notifications for a "notification".

Jernej

---

From: Andy Bierman <[email-masked]>
Date: Wed, 16 Dec 2015 08:03:10 -0800

On Wed, Dec 16, 2015 at 7:17 AM, Jernej Tuljak <[email-masked]> wrote:

>>> node representing the RPC ("/my-rpc"), which is a child to root node. The
>>> "root node" aka "document root" can only mean a single thing XPath
>>> terminology.
>>>
>> RFC 6020 clearly says that the tree is the rpc reply instance document,
>> so it is a different document whose root node coincides with <rpc-reply>.
>> The problem of 6020bis is that we need a definition that's independent of
>> XML, and that's not so easy, but I agree with Martin that nothing should
>> change for relative paths.
>>
>
> stay the same. Again, the root node is "/" in any case. So the context node
> needs to be set explicitly "/x:foo" for this corner case. I dare say it is
> not even a corner case. There is a similar YANG pattern to my "my-rpc"
> example in ietf-netconf-notifications for a "notification".
>
>

I am strongly opposed to changing the way when-stmt works,
and against expanding the XPath context for RPC and notifications.
You are demonstrating the types of complicated hacks required to
implement YANG 1.1.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 16 Dec 2015 17:11:16 +0100

> On 16 Dec 2015, at 16:17, Jernej Tuljak <[email-masked]> wrote:
> 
> I'm not against the new accessible tree. That nothing should change for relative paths is a given, IMO. So what about absolute location paths?
> 
> and this needs to be taken into account for at least relative paths to stay the same. Again, the root node is "/" in any case. So the context node needs to be set explicitly "/x:foo" for this corner case. I dare say it is not even a corner case. There is a similar

Yes, that's how I think it should be. It's tricky because x:foo doesn't appear in the XML encoding of <rpc-reply> - that's what I asked about previously in this thread.

Lada

>  YANG pattern to my "my-rpc" example in ietf-netconf-notifications for a "notification".
> 
> Jernej
> 
>> 
>> Lada
>> 
>>> Jernej
>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Dec 2015 17:18:29 +0100 (CET)

Jernej Tuljak <[email-masked]> wrote:
> >> node representing the RPC ("/my-rpc"), which is a child to root
> >> node. The "root node" aka "document root" can only mean a single thing
> >> XPath terminology.
> > RFC 6020 clearly says that the tree is the rpc reply instance
> > document, so it is a different document whose root node coincides with
> > <rpc-reply>. The problem of 6020bis is that we need a definition
> > that's independent of XML, and that's not so easy, but I agree with
> > Martin that nothing should change for relative paths.
> 
> I'm not against the new accessible tree. That nothing should change
> for relative paths is a given, IMO. So what about absolute location
> paths?
> 

No it was:

  <root>
    +-- nc:rpc-reply
      +- x:bar

> The absolute path to "x:bar" was:

/nc:rpc-reply/x:bar

> say it is not even a corner case. There is a similar YANG pattern to
> my "my-rpc" example in ietf-netconf-notifications for a
> "notification".

I think what needs to be done is to clarify that the context node for
when/must in input/output or uses in input/output is the node
representing the rpc.  Note that this is unspecified in 6020.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 16 Dec 2015 18:47:02 +0100 (CET)

Jernej Tuljak <[email-masked]> wrote:
> 
> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
> No. How do you explain the different wording for "input" when compared
> to "output" (6020, 7.19.5):
> 
>    o  If the context node represents RPC input parameters, the tree is
>       the RPC XML instance document.  The XPath root node has the
>       element representing the RPC operation being defined as the only
>       child.
> 
>       the RPC reply instance document.  The XPath root node has the
>       elements representing the RPC output parameters as children.
> 
> "XPath root node has the _element_ representing the RPC operation as
> the _only child_" vs. "XPath root node has the _elements_ representing
> the RPC output as _children_".
> 
> This is different from what 6020bis-09 is saying. The latter
> "equalized" accessible trees for "input" and "output". What I am
> asking is whether this confilcts with 1.1 charter.

You're right, but the entire thing is underspecifed in 6020.  In the
example you had:

  rpc foo {
    output {
      uses my-stuff {
        when "...";
      }
    }
  }

and if you go by 6020, there is no context node for the when
expression, and the accessible tree is defined in terms of the context
node.

Yes this is different in 1.1, but I think we're specifying rules for
something that wasn't specified, and fix inconsistencies.

> You could never refer to "nc:rpc-reply" as anything other that the
> document root in 1.0 ("/") . You could never refer to "nc:rpc" either,
> only to "x:foo".

It depends on how you interpret the words: "the tree is the RPC reply
instance document."

> True. It is unspecified. For notifications also, yet
> ietf-netconf-notifications practices it.

It just uses relative paths, in places where the context node is
well-defined.

/martin

> >>>>>>>>>>       o The context node is the node in the accessible tree for
> >>>>>>>>>>       which
> >>>>>>>>>>       the

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 17 Dec 2015 10:34:47 +0100

> It depends on how you interpret the words: "the tree is the RPC reply

There is no room for misinterpreting what an XPath root node is (next 
sentence). Even if the processing is actually done on an RPC reply 
instance document, an RPC instance document or a notification instance 
document, "nc:rpc-reply", "nc:rpc" and "ncEvent:notification" are simply 
not part of the YANG XPath model as anything else than a root node ("/") 
and they never were. The QNames previously listed do not exist in this 
model.

> It just uses relative paths, in places where the context node is

The specific definition I had in mind is netconf-confirmed-commit 
"notification" (trimmed):

   notification netconf-confirmed-commit {
     uses common-session-parms {
       when "confirm-event != 'timeout'";
     }
   }

The context node for this "when" is as unspecified as in my original 
example for "output" per 6020 (no data node ancestor to "uses"). And in 
6020bis-09 the context node now defaults to root node (not root/document 
element)! So if I take ietf-netconf-notifications@2012-02-06 and add a 
"yang-version 1.1;" to it, the module will break.
Furthermore the absolute XPath location path for confirm-event node is 
"/ncn:netconf-confirmed-commit/ncn:confirm-event", not 
"/ncEvent:notification/ncn:netconf-confirmed-commit/ncn:confirm-event", 
which is what you seem to be saying. If this is what the intention was, 
several errata need to be posted for 6020. We implement the 1.0 
accessible tree the way I have been describing, and yes, we do implement 
absolute location paths.

XPATH, 5.1 (http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model):
The root node is the root of the tree. A root node does not occur except 
as the root of the tree. The element node for the document element is a 
child of the root node.

6020:

    The data model used in the XPath expressions is the same as that used
    in XPath 1.0 [XPATH<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#ref-XPATH>], with the same extension for root node children
    as used by XSLT 1.0 [XSLT<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#ref-XSLT>] (Section 3.1).  Specifically, it means
    that the root node may have any number of element nodes as its
    children.

    o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list, and anyxml.

    o  If the context node represents notification content, the tree is
       the notification XML instance document.  The XPath root node has
       the element representing the notification being defined as the
       only child.

6020bis-09:

    The data model used in the XPath expressions is the same as that used
    in XPath 1.0 [XPATH], with the same extension for root node children
    as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
    that the root node may have any number of element nodes as its
    children.

    o  If the XPath expression is defined in a substatement to a
       "notification" statement, the accessible tree is the notification
       instance, all state data in the server, and the running
       configuration datastore.  If the notification is defined on the
       top-level in a module, then the root node has the node
       representing the notification being defined and all top-level data
       nodes in all modules as children.  Otherwise, the root node has
       all top-level data nodes in all modules as children.

I hope this clarifies what my previous email was saying about 
ietf-netconf-notifications. The accessible tree for "output" is a 
different issue.

(PS: I've been having trouble replying to the mailing list ever since we 
migrated our mail server which is why my previous message was not sent 
to the mailing list and Martin seemed to be replying to thin air.)

Jernej

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 17 Dec 2015 13:23:02 +0100 (CET)

Jernej Tuljak <[email-masked]> wrote:
> document, "nc:rpc-reply", "nc:rpc" and "ncEvent:notification" are
> simply not part of the YANG XPath model as anything else than a root
> node ("/") and they never were. The QNames previously listed do not
> exist in this model.
> 
> >
> >>>> and is now:
> >>>>
> >>>> /x:foo/x:bar
> >>>>
> example for "output" per 6020 (no data node ancestor to "uses"). And
> in 6020bis-09 the context node now defaults to root node (not
> root/document element)!

As I wrote before, this needs to be fixed.  We need to take the
node representing the notification (or rpc) into account.  Do you
agree?

> So if I take
> ietf-netconf-notifications@2012-02-06 and add a "yang-version 1.1;" to
> it, the module will break.
> which is what you seem to be saying.

No, you are right.

/martin

> If this is what the intention
> was, several errata need to be posted for 6020. We implement the 1.0
> accessible tree the way I have been describing, and yes, we do
> implement absolute location paths.
> 
> The root node is the root of the tree. A root node does not occur
> except as the root of the tree. The element node for the document
> element is a child of the root node.
> 
> 6020:
> 
>    in XPath 1.0
>    [XPATH<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#ref-XPATH>],
>    with the same extension for root node children
>    as used by XSLT 1.0
>    [XSLT<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09#ref-XSLT>]
>    (Section 3.1).  Specifically, it means
> (PS: I've been having trouble replying to the mailing list ever since
> we migrated our mail server which is why my previous message was not
> sent to the mailing list and Martin seemed to be replying to thin
> air.)
> 
> Jernej
> 
> >
> >
> > /martin
> >
> >
> >
> >> Jernej
> >>
> >>> /martin
> >>>
> >>>
> >>>
> >>>> Jernej
> >>>>
> >>>>> Lada
> >>>>>
> >>>>>> Jernej
> >>>>>>

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 17 Dec 2015 14:28:30 +0100

> node representing the notification (or rpc) into account.  Do you

I agree. The root node is acceptable only if none of these ancestors are 
found: a data node, node representing a notification, node representing 
an rpc, node representing rpc output.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 17 Dec 2015 14:37:21 +0100

> On 17 Dec 2015, at 14:28, Jernej Tuljak <[email-masked]> wrote:
> 
> I agree. The root node is acceptable only if none of these ancestors are found: a data node, node representing a notification, node representing an rpc, node representing rpc output.

The latter is somewhat more peculiar because it doesn't appear in XML instances - the others do. I think it would be useful to include a section describing the data tree, its properties, and how it maps to XPath. This is a bit difficult prospect though given that 6020bis is already in the (second) WGLC.

Lada