As a contributor… I support the adoption of this work as I feel it will help inform the overall T+ TLS 1.3 specification. I have some specific comments and nits, though:
Abstract: s/This modules augments/This module augments/ Section 1: Do you need to state that the first version of this spec used a pruning approach? Ultimately, when this is published that won’t matter. In the module itself, I’d like a few abbreviations expanded in the descriptions: leaf target-kdf • expand KDF container ca-certs • expand CA (yeah, I know) container ee-certs • expand EE Why do you define a new grouping, tcp-server-info? Why not just augment what is in 9105? This adds complexity with minimal, if any, benefit that I see. Does the new domain-name leaf need to be mandatory if certs are used? Finally, on operational data, should this module introduce any TLS-specific stats in addition to those in 9105? I feel like certificate issues or PSK problems might be useful. Joe From: Joe Clarke (jclarke) <[email protected]> Date: Tuesday, October 22, 2024 at 09:24 To: [email protected] <[email protected]> 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. Thanks. Joe
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
