Subject: Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

From: "Wubo (lana)" <[email-masked]>
Date: Tue, 21 Apr 2020 04:08:51 +0000

Hi chairs,

Thanks for the suggestion. We will add the example in the next revision.

Thanks,
Bo

-----邮件原件-----
发件人: OPSAWG [mailto:[email-masked]] 代表 Joe Clarke (jclarke)
发送时间: 2020年4月20日 21:26
收件人: Joe Clarke (jclarke) <jclarke=[email-masked]>
抄送: opsawg <[email-masked]>
主题: Re: [OPSAWG] WG LC: draft-ietf-opsawg-tacacs-yang-03

Hello, authors.  Tianran and I were chatting over email, and he had a good suggestion.  Could you add an example to this draft showing off how to use the model?

Joe

> On Apr 20, 2020, at 09:23, Joe Clarke (jclarke) <jclarke=[email-masked]> wrote:
> 
> Hello, opsawg.  As we stated in the April 7 virtual interim, this draft has reached a point where current WG feedback has been incorporated, and the larger TACACS+ is progressing through the IESG.  We are opening a two week last call for this draft.
> 
> Please comment as to whether or not you feel it is ready and what additional changes are required by May 3, 2020.
> 
> Thanks.
> 
> Joe and Tianran
> 
> Joe
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Wubo (lana)" <[email-masked]>
Date: Sun, 26 Apr 2020 02:12:31 +0000

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-masked]] 
发送时间: 2020年4月25日 21:36
收件人: tom petch <[email-masked]>
抄送: Wubo (lana) <[email-masked]>; opsawg <[email-masked]>
主题: Re: WG LC: draft-ietf-opsawg-tacacs-yang-03

> On Apr 25, 2020, at 06:44, tom petch <[email-masked]> wrote:
> 
> From: Joe Clarke (jclarke) <[email-masked]>
> Sent: 24 April 2020 17:42
> On Apr 24, 2020, at 11:37, tom petch <[email-masked]> wrote:
>> 
>> From: Joe Clarke (jclarke) <[email-masked]>
>> 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