Subject: [netmod] RFC 8349 action input augment

From: tom petch <[email-masked]>
Date: Tue, 5 May 2020 11:24:21 +0000

RFC8349 specifies an action with no input and says that modules that use this MUST augment the input with a leaf and that the leaf must be named destination-address.

Is there any way that YANG can enforce either constraint?

Tom Petch

---

From: Martin Björklund <[email-masked]>
Date: Tue, 05 May 2020 13:39:16 +0200 (CEST)

tom petch <[email-masked]> wrote:
> RFC8349 specifies an action with no input and says that modules that
> use this MUST augment the input with a leaf and that the leaf must
> be named destination-address.
> 

This may look correct:

  action activate-route {
    input {
      must '*[local-name(.) = "destination-address"]';
    }
    ...
  }

... but unfortunatly we have a CLR in the definition of "input":

   input-stmt          = input-keyword optsep
                         "{" stmtsep
                             ;; these stmts can appear in any order
                             *must-stmt
                             *(typedef-stmt / grouping-stmt)
 HERE--------------->        1*data-def-stmt
                         "}" stmtsep

We require "input" to have at least one data-def-stmt, which doens't
make any sense, since we allow an action/rpc to not define "input" at
all.

/martin

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

---

From: tom petch <[email-masked]>
Date: Tue, 5 May 2020 15:44:00 +0000

From: Martin Björklund <[email-masked]>
Sent: 05 May 2020 12:39
Cc: [email-masked]; [email-masked]

This may look correct:

  action activate-route {
    input {

<tp>
Thanks for that.  I thought there was a reason but did not think to look there.

As you may have guessed, I just looked at a YANG module which broke the rules, added  a leaf but of the wrong name.

Tom Petch

/martin