[yang-doctors] choice entry, all operation

[Christian Hopps <[e-mail]>]

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?

Thanks,
Chris.