Hi Joe, Thanks for the comments.
Please see inline. Cheers, Med De : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org> Envoyé : mardi 22 octobre 2024 17:16 À : Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org>; opsawg@ietf.org Objet : [OPSAWG]Re: CALL FOR ADOPTION: A YANG Model for Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3 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/ [Med] ACK 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. [Med] The plan is to remove this note in future versions. 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 [Med] ACK 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. [Med] 9105 does not have a list. The initial intent was to cover when there are more addresses to reach the same server identifier by the same domain-name for redundancy and so on. We could configure two sever entries, but then all the credentials will need to be repeated for each member of the group. Also, if there is a procedure to fall back when an instance is not responsive, that will be difficult to control with the separate entries. Would that makes sense? Does the new domain-name leaf need to be mandatory if certs are used? [Med] I don’t think so as DNS-ID and IP-ID are allowed for identification. No? This prompted me that a check is needed when SNI is enabled but we don’t have a knob to control SNI activation. I think we need one. 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. [Med] Good point. Will cover this in future iterations. Joe From: Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>> Date: Tuesday, October 22, 2024 at 09:24 To: opsawg@ietf.org<mailto:opsawg@ietf.org> <opsawg@ietf.org<mailto: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. Thanks. Joe ____________________________________________________________________________________________________________ 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
