-----邮件原件----- 发件人: tom petch [mailto:[email protected]] 发送时间: 2020年4月23日 23:42 收件人: Wubo (lana) <[email protected]>; Joe Clarke (jclarke) <[email protected]>; opsawg <[email protected]> 主题: Re: WG LC: draft-ietf-opsawg-tacacs-yang-03
From: Wubo (lana) <[email protected]> Sent: 23 April 2020 12:53 Hi Tom, Thanks for pointing this out, please see the reply below. Regards, Bo -----邮件原件----- 发件人: tom petch [mailto:[email protected]] 发送时间: 2020年4月22日 23:34 One point inline ________________________________________ From: Wubo (lana) <[email protected]> Sent: 22 April 2020 04:54 Hi Tom, Thanks for the comments, please see reply inline below. Regards, Bo -----邮件原件----- 发件人: OPSAWG [mailto:[email protected]] 代表 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 protected]> on behalf of Joe Clarke (jclarke) <[email protected]> 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 protected] https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
