Hi Tom and Joe, Many thanks for your comments and discussions. Both of you have suggested better approach.
I will update the model when the YANG Doctor has a final suggestion. Regards, Bo -----邮件原件----- 发件人: Joe Clarke (jclarke) [mailto:[email protected]] 发送时间: 2020年4月25日 21:36 收件人: tom petch <[email protected]> 抄送: Wubo (lana) <[email protected]>; opsawg <[email protected]> 主题: Re: WG LC: draft-ietf-opsawg-tacacs-yang-03 > 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
