Subject: [netmod] Y02: context node

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Nov 2015 14:40:58 +0100

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.

Moreover, it is not clear how the context node could be defined for the "output" case - in NETCONF, the only candidate would be the "rpc-reply" node, which however doesn't work for RESTCONF.

I think it would be better to allow "must" only under "input" and "notification".

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Nov 2015 14:09:56 +0100 (CET)

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.
> 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Nov 2015 14:24:42 +0100

> On 23 Nov 2015, at 14:09, Martin Bjorklund <[email-masked]> wrote:
> 

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>

>      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?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 23 Nov 2015 14:38:03 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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.

/martin

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 23 Nov 2015 14:53:13 +0100

> the XML encoding does not really matter.

There may be multiple 'top-level' nodes in output, yet the text assumes 
a single node context node. Not every modeler will be nice enough to 
wrap stuff into a single "container" as a child to "output"...

Jernej

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

---

From: Jernej Tuljak <[email-masked]>
Date: Mon, 23 Nov 2015 15:00:33 +0100

Jernej Tuljak je 23.11.2015 ob 14:53 napisal:
> There may be multiple 'top-level' nodes in output, yet the text 
> assumes a single node context node. Not every modeler will be nice 
> enough to wrap stuff into a single "container" as a child to "output"...

Yeah. This is not an issue. Just ignore it. I was over-thinking again.

Jernej

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Nov 2015 15:06:29 +0100

> On 23 Nov 2015, at 14:38, Martin Bjorklund <[email-masked]> wrote:
> 

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Nov 2015 09:48:55 +0100

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?

2. What is the context node for the "must" expression?

Thanks, Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Nov 2015 11:16:22 +0100 (CET)

> 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

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Nov 2015 11:30:49 +0100

> On 25 Nov 2015, at 11:16, Martin Bjorklund <[email-masked]> wrote:
> 

Yes, I know.

> (If we instead move back to Y04-04, the accessible tree would be:

IMO, neither option works. The accessible tree has to consist of existing instances of data nodes and <ctx:oper> doesn't exist in a RPC reply (as opposed to the corresponding RPC request), which is only

<nc:rpc-reply>
  <ctx:foo>42</ctx:foo>
</nc:rpc-reply>

Do you see what I mean?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Nov 2015 12:02:01 +0100 (CET)

> IMO, neither option works. The accessible tree has to consist of existing instances of data nodes and <ctx:oper> doesn't exist in a RPC reply (as opposed to the corresponding RPC request), which is…

Yes, but this is NETCONF-specific.  We need to have a solution that
works for other protocol.  IMO, the peer must conceptually build a
tree that looks like the one I showed above.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 25 Nov 2015 12:28:01 +0100

> On 25 Nov 2015, at 12:02, Martin Bjorklund <[email-masked]> wrote:
> 

OK, but if so, it has to be described in the spec. If we don't combine the input/output trees with configuration and state data (Y04-04), then the accessible tree in my example could be simply

<root>
  +-- foo = 10

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Nov 2015 13:25:16 +0100

> I'd like to resolve this issue. Here is a complete example (valid, I believe):

Sorry for asking a stupid question but what is the use case of
referencing state data from an xpath expression in RPC input or
output parameters?

/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: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Nov 2015 13:31:01 +0100 (CET)

> referencing state data from an xpath expression in RPC input or

It all started with leafrefs in notifications.  The algorithm in RFC
6643 produces leafrefs from notifications to state data.  See Y04.

For the same reason, you may want to reference let's say an interface
name in the /interfaces-state/interface list from an RPC input
parameter.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 25 Nov 2015 14:06:28 +0100

> name in the /interfaces-state/interface list from an RPC input

Yes, but where does xpath come into play?

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 25 Nov 2015 14:15:51 +0100 (CET)

> Yes, but where does xpath come into play?

The leafref's path is XPath.  See the example in Y04.  It might be
surprising that this is illegal (if we do Y04-04):

   rpc foo {
     input {
       leaf ifref {
         type leafref {
           path "/if:interfaces-state/if:interface/if:name";
         }
         must "/if:interfaces-state/if:interface[if:name = current()/ifref]"
            + "/if:enabled";
       }
     }
   }

The leafref is legal, but the must expression would be illegal.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 25 Nov 2015 09:01:56 -0800

> The leafref is legal, but the must expression would be illegal.
I agree with Juergen about questioning the need for this new feature.
The path expression is limited.  XPath is not limited at all.
The code to find the "pointed-at" leaf is much simpler than full XPath.

> /martin
Andy