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

From: "Wubo (lana)" <[email-masked]>
Date: Fri, 24 Apr 2020 07:30:49 +0000

-----邮件原件-----
发件人: tom petch [mailto:[email-masked]] 
发送时间: 2020年4月23日 23:42
收件人: Wubo (lana) <[email-masked]>; Joe Clarke (jclarke) <jclarke=[email-masked]>; opsawg <[email-masked]>
主题: Re: WG LC: draft-ietf-opsawg-tacacs-yang-03

From: Wubo (lana) <[email-masked]>
Sent: 23 April 2020 12:53

Hi Tom,

Thanks for pointing this out, please see the reply below.

Regards,
Bo

-----邮件原件-----
发件人: tom petch [mailto:[email-masked]]
发送时间: 2020年4月22日 23:34

One point inline
________________________________________
From: Wubo (lana) <[email-masked]>
Sent: 22 April 2020 04:54

Hi Tom,

Thanks for the comments, please see reply inline below.

Regards,
Bo

-----邮件原件-----
发件人: OPSAWG [mailto:[email-masked]] 代表 tom petch
发送时间: 2020年4月21日 17:09

I think that more is needed for security.

Security Considerations does not list any sensitive nodes.  I see 'secret' as an obvious candidate with its nacm:deny-all and perhaps the list of servers and their addresses.
[Bo] OK. I will list these nodes to the Security Considerations section.

The model allows for accounting or authorisation or authentication or all three but not two out of three; I do not know if this is a use case.
[Bo] Two out the three configurations can be supported by configuring any of the two. "all three" is intended to be consistent with most implementations.

<tp>
I do not see it; AFAIK an enumeration can only be configured with one value which then can only be one of the four specified in the model.  Other data types do allow combinations - bit strings for examp[e - but not I think enumeration.  Whether or not this is worth including, I do not know - as you say, all three is the common case.

Tom Petch
[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?

Tom Petch
[Bo] Many thanks for your suggestion. The other two methods are indeed clumsy.  
Please see if the following modification are as you suggested.
        leaf server-type {
          type int8 {
            range "1..7";
          }				
          description
            "The value indicates different server types or combinations,
			and the meanings are as follows: 
			1    The server is an authentication server 
			2    The server is an authorization server 
			4    The server is an accounting server
			7    The group of all types of TACACS+ servers
             3    The server is an authentication and authorization server
            etc. ";
        }

Bo

opsawg-tacacs says secret must be 16  preferably 32; YANG can enforce the former and recommend the latter [Bo] OK, I will add 'length "16..max" ' and 'description: as specified by Tdraft-ietf-opsawg-tacacs : TACACS+ servers and clients MUST support shared keys that are at
   least 32 characters long '
   But I'm not sure about the 'length', vendors may use different restrictions.

server name is unrestricted in length or character set; is this desirable (YANG has a type for identifiers limited to the usual A-Z 0-9 plus some punctuation)?
[Bo] I think I can add, but System model (RFC 7317) does not have this restriction, and vendors may use different ones.

Overall I was expecting more but that said I cannot think of what to add!

Tom Petch

________________________________________
From: OPSAWG <[email-masked]> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]>
Sent: 20 April 2020 14:23

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: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 24 Apr 2020 13:24:08 +0000

Tom Petch

<tp>

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.

Joe

Tom Petch

Bo

Tom Petch

________________________________________
From: OPSAWG <[email-masked]<mailto:[email-masked]>> on behalf of Joe Clarke (jclarke) <jclarke=[email-masked]<mailto:jclarke=[email-masked]>>
Sent: 20 April 2020 14:23

Thanks.

Joe and Tianran

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

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

---

From: tom petch <[email-masked]>
Date: Fri, 24 Apr 2020 15:37:41 +0000

From: Joe Clarke (jclarke) <[email-masked]>
Sent: 24 April 2020 14:24

<tp>

<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.

Tom Petch
Joe

Tom Petch

Bo

Tom Petch

Thanks.

Joe and Tianran

Joe

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Fri, 24 Apr 2020 16:42:43 +0000

> On Apr 24, 2020, at 11:37, tom petch <[email-masked]> wrote:
> 

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.

Joe

---

From: tom petch <[email-masked]>
Date: Sat, 25 Apr 2020 10:44:12 +0000

From: Joe Clarke (jclarke) <[email-masked]>
Sent: 24 April 2020 17:42

JMC>

<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

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Sat, 25 Apr 2020 13:35:32 +0000

> On Apr 25, 2020, at 06:44, tom petch <[email-masked]> wrote:
> 

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