Re: [yang-doctors] choice entry, all operation

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

Hi Chris,

> -----Original Message-----
> From: yang-doctors <[e-mail]> On Behalf Of Christian
> Hopps
> Sent: 21 April 2020 13:34
> To: YANG Doctors <[e-mail]>
> Subject: [yang-doctors] choice entry, all operation
> 
> I'm wondering about the best way to model a particular pattern I have
> coming up multiple times with NMDA in mind. I want the user to enter a
> value using a single form of the value, but I want to report
> (operationally) multiple forms based on that value.
> 
> Here are a couple examples:
> 
> - A packet size :: 3 choices, either "discover", an "outer" tunnel packet
> size, or an "inner" payload size.
> - A bit rate :: 2 choices, either "L2 bitrate" or "L3 bitrate"
> 
> So for the packet size the user might use "discover" (which would use PMTU
> discovery to discover the "outer" size to use). This is for an IPsec
> tunnel so the "inner" payload size will be determined based on the "outer"
> size and the IPsec algorithms in use (variable overhead). Point being all
> 3 values are useful to see operationally.
> 
> Bit rate is a bit more straight-forward, but still if the user configures
> 10G for l2-bitrate its useful to be able to operationally query the l3-
> bitrate which would remove the L2 overhead.
> 
> "choice" is obvious for "config true", but fails for reporting all the
> "config false" operational values, so I'm wondering what is a better way?
> 
> Should I just use sibling leafs and leave validation up to the server on
> config application, or is this a case where I'm trying to do too much with
> NMDA, and I should just split the operational values out (and have the
> "config true" choice node be a duplicate of the operational value when
> it's operational value is fetched?
[RW] 

Just considering the packet size example:

One option could be:
- Define 3 config true leaves, and put must constraints on two of them so that only one of the leaves can be configured, and then have a comment in the description to indicate that the must constraint isn't enforced in operational.  Possibly, we should consider for YANG.next whether there should be a keyword to mark some constraints as only applying to configuration, or operational data. 

The other option would be to split the operational values out, as you suggest, but that loses the config/state relationship.

Regards,
Rob

[As an individual contributor]

> 
> Thanks,
> Chris.
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors