Re: [netmod] RFC 8349 action input augment

["Rob Wilton (rwilton)" <[e-mail]>]

I've raised https://github.com/netmod-wg/yang-next/issues/106 to track this.

Regards,
Rob


> -----Original Message-----
> From: netmod <[e-mail]> On Behalf Of tom petch
> Sent: 05 May 2020 16:44
> To: Martin Björklund <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [netmod] RFC 8349 action input augment
> 
> From: Martin Björklund <[e-mail]>
> Sent: 05 May 2020 12:39
> Cc: [e-mail]; [e-mail]
> 
> tom petch <[e-mail]> 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.
> >
> > Is there any way that YANG can enforce either constraint?
> 
> 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.
> 
> <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
> 
> 
> >
> > Tom Petch
> >
> >
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod