> On Apr 25, 2020, at 06:44, tom petch <[email protected]> wrote: > > 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.
JMC> As a contributor (and all of my comments on this thread have been) I still prefer the leaf-list. Privileges are different than server types, and in a number of cases, I just configure authn and authz alone (so I don’t think ‘*’ would be as prevalent). Still, I agree with this last comment of yours, and I will flag this to the YANG doc. Thanks for your reviews, as always, Tom. The discussions are very valuable. Joe _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
