Subject: [netmod] YANG 1.1: must-stmt evaluation in input, output, notification

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Jun 2016 19:21:47 -0700

Hi,

I am trying to implement YANG 1.1 must-stmt extensions.
They appear to be under-specified.

In sec. 7.5.3

   The XPath expression is conceptually evaluated in the following
   context, in addition to the definition in Section 6.4.1
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1>:

   o  The context node is the node in the accessible tree for which the
      "must" statement is defined.

The problem for input/output is that these nodes are not encoded
in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly defines the
XPath context for input and output, so 7.5.3 is incorrect.

7.5.3 should say the context node for input/output is the node representing
the RPC operation. This would be the same for NETCONF encoding of action.
The RESTCONF encoding for RPC and action is completely different
but the definition in 7.5.3 is actually correct for RESTCONF.

The problem for notification is not that <notification> is not in the
instance document, but rather that it is not part of the XPath context:

   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.

The context node for <notification> should be the node representing the
notification.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Jun 2016 14:42:15 +0200

> but the definition in 7.5.3 is actually correct for RESTCONF.

This should not depend on any encoding, an XPath expression is evaluated
on a conceptual data tree, and this tree is defined for operations, too.  

>       all top-level data nodes in all modules as children.

This is indeed quite incomprehensible. What's the idea here?

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 13 Jun 2016 07:39:05 -0700

On Mon, Jun 13, 2016 at 5:42 AM, Ladislav Lhotka <[email-masked]> wrote:

> > <
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-13#section-6.4.1
> >:
> >

The <input> and <output> nodes do not appear at all
in the instance document for NETCONF so this bullet in 7.5.3 is wrong
for those nodes.

For <notiofication>, the child of <notification> is already specified
as the child of docroot.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 13 Jun 2016 17:30:37 +0200

> On 13 Jun 2016, at 16:39, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

OK, so this is about "must" statements specified directly under input/output and notification statements, right? I had the same comment previously:

https://www.ietf.org/mail-archive/web/netmod/current/msg14469.html

My understanding is that in the former case the context node is the root of the input/output data tree, and in the latter case it is the node with the same name as the notification.

I agree it should be better explained.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Jun 2016 06:12:35 -0700

On Mon, Jun 13, 2016 at 8:30 AM, Ladislav Lhotka <[email-masked]> wrote:

> OK, so this is about "must" statements specified directly under
> input/output and notification statements, right? I had the same comment
> previously:
>
> My understanding is that in the former case the context node is the root
> of the input/output data tree, and in the latter case it is the node with
> the same name as the notification.
>

If you already brought up this issue, then why is the text still incorrect?

> >       "must" statement is defined.

This text is clearly wrong for the 3 new nodes that were added (input,
output, notification).
Why wasn't this text corrected?

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jun 2016 15:28:45 +0200

> On 16 Jun 2016, at 15:12, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

The subsequent discussion convinced me that it can be easily fixed, and then I lost it from the radar, unfortunately.

Lada

> This text is clearly wrong for the 3 new nodes that were added (input, output, notification).

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Jun 2016 15:58:48 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> The subsequent discussion convinced me that it can be easily fixed,
> and then I lost it from the radar, unfortunately.

I lost track of this issue as well :(

Anyway, I think my original proposed fix to this issue should work:

OLD:

NEW:

   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.

   o  Otherwise, the context node is the node in the accessible tree
      for which the "must" statement is defined.

Note that the original email thread quickly started to discuss the
accessible tree, but the proposed text above does not change the
accessible tree.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Jun 2016 16:08:17 +0200

> On 16 Jun 2016, at 15:58, Martin Bjorklund <[email-masked]> wrote:
> 

What is "the node representing the operation in the accessible tree"? I think it should rather be "the root node of the operation request/reply instance". Unlike notifications, operations request/reply isn't wrapped in an element with the operation's name.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Jun 2016 07:40:59 -0700

On Thu, Jun 16, 2016 at 7:08 AM, Ladislav Lhotka <[email-masked]> wrote:

> >>> My understanding is that in the former case the context node is the
> root of the input/output data tree, and in the latter case it is the node
> with the same name as the notification.
> >>>

notification foo {
   must "leaf-a > 4";
   leaf leaf-a { type int32; }
}

<notification>
   <foo>
       <leaf-a>5</leaf-a>
   </foo>
</notification>

The text might confuse people into thinking <notification> is the context
instead of <foo>.
The XPath section says the accessible tree root has <foo> as a child node,
but it is
not obvious.

> What is "the node representing the operation in the accessible tree"? I
> think it should rather be "the root node of the operation request/reply
> instance". Unlike notifications, operations request/reply isn't wrapped in
> an element with the operation's name.
>

It is different for NETCONF and RESTCONF

How about "representing the root of the operation input in the accessible
tree"

Andy

---

From: "Jonathan Hansford" <[email-masked]>
Date: Thu, 16 Jun 2016 17:31:34 +0100

s/a "input"/an "input"
s/a "output"/an "output"

> -----Original Message-----
> From: netmod [mailto:[email-masked]] On Behalf Of Martin
> Bjorklund
> Sent: 16 June 2016 14:59
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netmod] YANG 1.1: must-stmt evaluation in input, output,
> notification
> 
> > > > > in any NETCONF RPC or action invocation. Sec. 6.4.1 clearly
> > > > > defines the XPath context for input and output, so 7.5.3 is
incorrect.
> > > > >
> > > > > 7.5.3 should say the context node for input/output is the node
> > > > > representing the RPC operation. This would be the same for
> NETCONF encoding of action.
> > > > This should not depend on any encoding, an XPath expression is
> > > > evaluated on a conceptual data tree, and this tree is defined for
> operations, too.
> > > >
> > > >
> > > >
> > > > The <input> and <output> nodes do not appear at all in the
> > > > instance document for NETCONF so this bullet in 7.5.3 is wrong for
> > > > those nodes.
> > > >
> > > > For <notiofication>, the child of <notification> is already
> > > > specified as the child of docroot.
> > >
root
> of the input/output data tree, and in the latter case it is the node with
the
> same name as the notification.
> > >
accessible
> tree, but the proposed text above does not change the accessible tree.
> 
> 
> /martin
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 17 Jun 2016 09:39:36 +0200 (CEST)

Ladislav Lhotka <[email-masked]> wrote:
> >>>>> representing
> >>>> evaluated
> >>> input/output and notification statements, right? I had the same
> >>> comment previously:
> >>> 
> >>> root of the input/output data tree, and in the latter case it is the
> >>> node with the same name as the notification.
> >>> 
> What is "the node representing the operation in the accessible tree"?

This is already defined in section 6.4.1.  Again, note that the text
we're currently discussing does not alter the definition of the
accessible tree.  For more background, see the old email thread to
which you provided a pointer.

> I think it should rather be "the root node of the operation
> request/reply instance". Unlike notifications, operations
> request/reply isn't wrapped in an element with the operation's name.

Again, see the email thread (this is protocol specific)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jun 2016 11:06:41 +0200

>       for which the "must" statement is defined.

I think this resolves the issue.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 17 Jun 2016 12:54:04 +0200

> Again, see the email thread (this is protocol specific)

OK, got it.

Lada