Hi Éric,
Thanks for the review.
Please see inline.
Cheers,
Med (as author)
> -----Message d'origine-----
> De : Éric Vyncke via Datatracker <nore...@ietf.org>
> Envoyé : jeudi 3 juillet 2025 11:01
> À : The IESG <i...@ietf.org>
> Cc : draft-ietf-opsawg-secure-tacacs-y...@ietf.org; opsawg-
> cha...@ietf.org; opsawg@ietf.org; jcla...@cisco.com;
> jcla...@cisco.com
> Objet : Éric Vyncke's Discuss on draft-ietf-opsawg-secure-tacacs-
> yang-12: (with DISCUSS and COMMENT)
>
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-opsawg-secure-tacacs-yang-12: Discuss
>
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
>
>
>
> --------------------------------------------------------------------
> DISCUSS:
> --------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-secure-tacacs-
> yang-12
> CC @evyncke
>
> Thank you for the work put into this document.
>
> Please find below one blocking DISCUSS points (trivial to address),
> some
> non-blocking COMMENT points/nits (replies would be appreciated even
> if only for
> my own education).
>
> Special thanks to Joe Clarke for the shepherd's detailed write-up
> including the
> WG consensus and the justification of the intended status.
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## DISCUSS (blocking)
>
>
> ### Incoherence between tree view and the actual model
>
> As INT AD, I pay specific attention to addresses and domain names,
> hence I
> noticed in section 3:
>
> ```
> +--rw address inet:host
> +--rw port? inet:port-number
> ```
>
> While the actual model in section 4 is:
>
> ```
> leaf address {
> type inet:host;
> mandatory true;
> description
> "The IP address or name of the TACACS+ server.";
> }
> leaf port {
> type inet:port-number;
> mandatory true;
> description
> "The port number of TACACS+ server.
> Default port number for legacy TACACS+ is 49,
> while it is TBD for TACACS+TLS.";
> }
> ```
>
> I.e., it is unclear whether "port" is mandatory due to conflicting
> information.
[Med] Agree. I have already fixed this one last week in my local copy as you
can seen at:
https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-opsawg-secure-tacacs-yang&url_2=https://boucadair.github.io/secure-tacacs-yang/draft-ietf-opsawg-secure-tacacs-yang.txt
> Moreover, if it is mandatory why specifying default values ?
[Med] We are not using default statements but only remind existing ones as this
may depend on the tacacs+ flavor (with or without TLS).
>
> --------------------------------------------------------------------
> --
> COMMENT:
> --------------------------------------------------------------------
> --
>
>
> ## COMMENTS (non-blocking)
>
> ### Section 4
>
> I will let the SEC ADs have the final word of course, but I wonder
> whe the
> domain-name leaf is not mandatory ? I.e., the client must check
> whether the
> server certificate matches the expected SN of the certificate.
>
[Med] The domain-name here is the one is the used for SNI. We have a must check
for that one:
leaf sni-enabled {
type boolean;
must '../domain-name' {
error-message
"A domain name must be provided to make use of Server
Name Indication (SNI).";
}
> Should the YANG module also include which cipher-suite was actually
> negotiated ?
[Med] We don't include these as we set the scope to be aligned with RFC9645.
>
> ### Appendix B
>
> Thanks for the IPv6 examples ;-)
[Med] At least we made one reader happy :-)
>
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.
This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
