some more stray thoughts
This modules
/s//
Concretely, this first version
of the specification uses a pruning approach rather that a reuse of
**eh??
the groupings defined in [I-D.ietf-netconf-tls-client-server].
made sense by the end but a reference to the 'refine's would have helped and an
explicit statement as to what is being prunec
A server instance may be identified by an IPv4 address, IPv6
address, or both.
any precedence thereof?
The same or distinct port numbers may be used per address family.
perhaps 'different port'
Both explicit and reference are supported.
could do with more detail IMHO
"This module provides configuration of TACACS+ over TLS
clients.
reads slightly oddly IMHO - perhaps
"This module provides configuration of TACACS+ clients over TLS ...
must 'not(deref(.)/../ks:public-key-format) or '
I struggle with
must 'not ... or ...
because of precedence of operators. I cannot recall if American mathematicians
use the same rues as Europeans. (I know they differ with 'strictly':-( A
clarifying phrase in the description clauses (lots of) would help.
type uint16;
description
"Specifies the protocol for which a PSK is imported for
use.";
reference
"RFC 9258: Importing External Pre-Shared Keys (PSKs) for
TLS 1.3, Section 3 ";
I do not see from the reference how the uint16 is turned into a protocol
"A choice between a reference of explicit configuration.";
/of/or/? in several places around here
"TLS 1.2 is not supported as min TLS version";
....
"TLS 1.2 is not supported as max TLS version";
reads a bit oddly. It seems to avoid saying that TLS 1.3 is the only supported
version
"Indicates that a TLS-level client identity has been
configured.
This statement is present so the mandatory descendant do not
imply that this node must be configured.";
reads a bit oddly - I am not clear what it is telling me
default "1234"; // to be replaced by TACACS-TLS-PORT
from where - is this
Port Number: [TBD] in draft-ietf-opsawg-tacacs-tls13-14 ??
TBD would seem better
[I-D.ietf-netmod-rfc8407bis].
IMHO needs to be Normative
Tom Petch
________________________________________
From: tom petch <ie...@btconnect.com>
Sent: 01 November 2024 12:52
To: Joe Clarke (jclarke); opsawg@ietf.org
Subject: Re: CALL FOR ADOPTION: A YANG Model for Terminal Access Controller
Access-Control System Plus (TACACS+) over TLS 1.3
p.3
Discussion Note: RFC 9105bis or keep the current augment design.
Is this a topic that needs resolving prior to adoption?
I do not know what the ramifications are.
Tom Petch
________________________________________
From: Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>
Sent: 22 October 2024 14:23
To: opsawg@ietf.org
Subject: [OPSAWG]CALL FOR ADOPTION: A YANG Model for Terminal Access Controller
Access-Control System Plus (TACACS+) over TLS 1.3
The IPR poll has concluded (no known IPR has been disclosed), and we would like
to start a two week adoption poll for
draft-boucadair-opsawg-secure-tacacs-yang<https://datatracker.ietf.org/doc/draft-boucadair-opsawg-secure-tacacs-yang/>.
Please respond on-list with support and especially comments.
The adoption call will run until November 5.
BANG
Thanks.
Joe
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
