One comment I forgot to add. The list server is keyed on name, so in theory we
could have multiple entries in that list to the same server (leaf address).
Should there be a unique statement for leaf address?
list server {
key "name";
On Wednesday, January 22, 2025 at 05:25:39 PM EST, Reshad Rahman via
Datatracker <nore...@ietf.org> wrote:
Reviewer: Reshad Rahman
Review result: Ready with Issues
Disclaimer: I am not a TACACS+ nor a TLS expert.
Overall the document looks good. Here are what I perceive are issues which
should be addressed.
"leaf address": it is of type inet:host, so is not necessarily an IP address as
per the name and description. Rename to "server" or "host"? But this would be a
non backwards compatible change.... At least change the description to say "IP
address or host name of the ACACS+ server."
leaf address {
type inet:host;
mandatory true;
description
"The address of the TACACS+ server.";
}
It is not clear to me why "leaf domain-name" was added. Section 3 refers to
section 3.3 of [I-D.ietf-opsawg-tacacs-tls13] but that section does not mention
domain-name.
'domain-name': Provides a domain name of the server per Section 3.3
of [I-D.ietf-opsawg-tacacs-tls13].
"leaf vrf-instance": not needed if source-type is source-interface (since the
VRF of the source interface would be used)? Add "must not()" statement or
describe the behaviour if vrf-instance does not have the same value as
source-interface's VRF.
"leaf port": remove the commented out “default 49”?
"choice source-type": do we need “mandatary true”? Same question for the 2
instances of “choice ref-or-explicit”
"leaf single-connection": please add a reference. I think that should be to
Section 4.3 of [RFC8907].
_______________________________________________
yang-doctors mailing list -- yang-doct...@ietf.org
To unsubscribe send an email to yang-doctors-le...@ietf.org
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
