From: Joe Clarke (jclarke) <[email protected]>
Sent: 24 April 2020 17:42
On Apr 24, 2020, at 11:37, tom petch <[email protected]> wrote:
>
> From: Joe Clarke (jclarke) <[email protected]>
> Sent: 24 April 2020 14:24
>
> [Bo] You are correct, and I think this model should not exclude this cases.
> I am considering of two possible approach: one way is to modify enumeration
> to leaf-list, the other is that 'server' list uses both 'name' and
> server-type' as key values.
> What do you think?
>
> <tp>
> I am not sure I understand. I think of the traditional approach of an int
> range 0..7 with 1, 2, 4 representing the three alternatives so one digit
> represents any possible combination but that is Unix and not really YANG.
> I see it as attractive to have one value meaning all three (which 7 would do
> above) as that is a common case but I think you are suggesting a leaf-list of
> one or two or three entries which works, but is a bit clumsy. Ditto
> server-type as key, would you not end up with three entries in the list for a
> full function server?
>
> Why is leaf-list clumsy? To me that seems like the right approach here. The
> chmod-like bit string seems less obvious in this case. This seems akin to
> the feature leaf-list in ietf-yang-library and I can see this working where
> there is a server-type-identifier typedef that is an enum of the types
> currently present in the module. Then you’d like instance data like:
>
> <server-type>authentication</server-type>
> <server-type>authorization</server-type>
> <server-type>accounting</server-type>
>
> This is more self-describing than the bit string. I wouldn’t add server-type
> as a key, though. I would think that the name alone would still work.
>
> <tp>
> I did say it was more Unix than YANG:-)
> I use 'clumsy' to mean that in order to show support for all three options,
> which I suspect will be the commonest case, you have to set three objects
> whereas ideally you would set just the one meaning all three. I would also
> use clumsy to describe introducing a fourth option to mean all three.
> At present, I cannot think of a less clumsy way in YANG. Thus, I do not see
> a bit string as any more attractive.
JMC>
Agreed, I don’t see the bstring as more attractive. Yes, the explicit
enumeration is more verbose, but it is more self-describing. I would opt for
that vs. an “all” that doesn’t tell me anything unless I read the module.
<tp>
Joe
I had a look at the NACM RFC to see how Andy handled the case of the five
possible actions, CRUDX, of which zero to five are possible and he uses bit
string, which suggests to me that there is no better way, except that for NACM
the commonest case is likely just 'Read' so that is nice and compact to
specify. I notice elsewhere that he has a list of type string for users or
groups thereof but does allow '*' to mean all, which I like and think
self-explanatory. I would expect users here to know of the three options and
expect them all to be present in most cases and so would realise the meaning of
asterisk. We could have
choice
case select
bit string
/* one or two services*/
case all
(asterisk)
/* all three*/
Is it worth the complexity? Up to you:-)
We could draw the attention of a Yang Doctor review to this.
Tom Petch
Joe
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
