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

From: "Wubo (lana)" <[email-masked]>
Date: Thu, 23 Apr 2020 11:53:24 +0000

Hi Tom,

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

Regards,
Bo

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

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?
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: tom petch <[email-masked]>
Date: Thu, 23 Apr 2020 15:42:20 +0000

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

Hi Tom,

Regards,
Bo

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

One point inline

Hi Tom,

Regards,
Bo

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

<tp>

Tom Petch

<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

Tom Petch

Thanks.

Joe and Tianran

Joe