Subject: [netmod] Must on actions without input or output parameters

From: Balazs Lengyel <[email-masked]>
Date: Thu, 16 Jun 2016 10:33:34 +0200

Hello,

We have the following model

container myThing {
    leaf enabled { type boolean;}
    action start {
       must "../enabled = 'true'";
    }
}

-- or --

container myThing {
    leaf enabled { type boolean;}
    action start {
       input {
          must "../enabled = 'true'";
       }
    }
}

We only want to allow starting myThing (calling the start action) if it is enabled.
However we
- can not put a must under action according to the RFC/draft
- while the RFC would allow us to put an empty input under action with
only the must statement in it, pyang complains about the absence of data definition nodes.

What is the solution?

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 16 Jun 2016 11:49:51 -0400

> only the must statement in it, pyang complains about the absence of

Reading the specification of the must statement (section 7.5.3), the
concept that must declares a *constraint*, which is evaluated at commit
time as specified in section 8.

Reading 8.1, I see that it describes which constraints are applied at
what times.  No only are they used to validate the datastore at commit
time, they also are used to validate the inputs and outputs of actions,
etc.  The scope of the XPath expression in such a must is the input data
tree of the action, not the datastore.

So there is no way to specify in Yang a constraint on the datastore that
must be satisfied for an action to be valid.

In regard to "input", it isn't said plainly in section 7.14, but the
ABNF makes clear that it must contain at least one data-def-stmt.  But
if the action has no inputs, the input statement can be omitted.

Dale

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 22 Jun 2016 16:13:27 +0200

> tree of the action, not the datastore.
BALAZS:  From 6.4.1.  XPath Context
"If the XPath expression is defined in a substatement to an "input"
       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."

So if I define a "must" in the input of an action the normal data tree 
IS visible.
> must be satisfied for an action to be valid.
BALAZS: As stated above I don't think this is true
> if the action has no inputs, the input statement can be omitted.
BALAZS: You are correct about the ABNF. But  I could still do:

container myThing {
    leaf enabled { type boolean;}
    action start {
       input {
          leaf dummy-leaf-never-use-it { type empty; }           // 
optional so I can just ignore it
          must "../enabled = 'true'";
       }

My question is why do I need to do this ugly solution? Is there a better 
way?
Is there a reason why I really need the dummy leaf?
Is there a reason why the rfc does not allow an input field with a 
single must statement in it?

Balazs

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 Jun 2016 15:38:27 -0400

[edited]
>           // optional so I can just ignore it
>           leaf dummy-leaf-never-use-it { type empty; }

I suspect that is because nobody envisioned that an input statement with
only a 'must' could be useful.  You've provided a counterexample to that
idea.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 22 Jun 2016 15:59:59 -0400

> So if I define a "must" in the input of an action the normal data tree 

Interesting...

I'm not sure, but I think that the spec may omit something:

6.4.1:

   o  If the XPath expression is defined in a substatement to an "input"
      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 input
      parameters as children.

6.4.1.1:

   Given the following module:

     module example-a {
       yang-version 1.1;
       namespace urn:example:a;
       prefix a;

       container a {
         list b {
           key id;
           leaf id {
             type string;
           }
           notification down {
             leaf reason {
               type string;
             }
           }
           action reset {
             input {
               leaf delay {
                 type uint32;
               }
             }
             output {
               leaf result {
                 type string;
               }
             }
           }
         }
       }
       [...]
     }

   The accessible tree for an action invocation of "reset" on /a/
   b[id="1"] with the "when" parameter set to "10" would be:

     <a xmlns="urn:example:a">
       <b>
         <id>1</id>
         <reset>
           <delay>10</delay>
         </reset>
       </b>
       <b>
         <id>2</id>
       </b>
     </a>
     // possibly other top-level nodes here

I don't see where the insertion of the action node (the "reset") into
the datastore tree is specified for XPath evaluation.  (7.15 describes
how the combined XML is encoded for the request and response, and 6.4.1
describes the combined tree for input nodes for RPCs.)

Dale

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 23 Jun 2016 13:50:39 +0200

> the datastore tree is specified for XPath evaluation.  (7.15 describes

It probably isn't. A further complication is that an action instance itself
contains a "branch" of a normal data tree, so properly defining the accessible
tree becomes quite tricky.

Lada

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

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