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.
Tom Petch
Joe
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]<mailto:[email protected]>> on
behalf of Joe Clarke (jclarke)
<[email protected]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
