Many thanks Eric, for taking the time to dig into the doc. Please see responses inline, we’ll upgrade the doc appropriately, it will definitely improve it, and if you have any concerns about the responses, please let us know.
I have one query (please see below) Re: s/separate TCP/IP port number /separate TCP port/ For Clarification Eric, can you let me know if the issue is the “/IP” or the “number”? We have recently ensured that all applicable mentions of “port” are replaced with “port number”. From: Éric Vyncke via Datatracker <nore...@ietf.org> Date: Tuesday, 24 June 2025 at 13:08 To: The IESG <i...@ietf.org> Cc: draft-ietf-opsawg-tacacs-tl...@ietf.org <draft-ietf-opsawg-tacacs-tl...@ietf.org>, opsawg-cha...@ietf.org <opsawg-cha...@ietf.org>, opsawg@ietf.org <opsawg@ietf.org>, mohamed.boucad...@orange.com <mohamed.boucad...@orange.com>, Joe Clarke (jclarke) <jcla...@cisco.com>, Joe Clarke (jclarke) <jcla...@cisco.com> Subject: Éric Vyncke's Yes on draft-ietf-opsawg-tacacs-tls13-23: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-tacacs-tls13-23: Yes 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.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tacacs-tls13-23 CC @evyncke Thank you for the work put into this document. Please find below 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 especially the relationship to the informational RFC 8907. I hope that this review helps to improve the document, Regards, -éric ## COMMENTS (non-blocking) ### Header The header part is missing the draft name (not critical at this stage). ### QUIC At least, some justifications why TLS was preferred to QUIC or HTTPS would be welcome. TACACS+ has a specific wired datacentre context, with establish deployments and infra, which guides us the TCP route for incremental (but necessary) improvements to its commonly deployed stack. That being the case, QUIC’s advantages for speeding up the web scale were not seen as being applicable and same applies really for introducing HTTPS into this stack. Adding context to the TLS preference will definitely be an improvement, but I thin, that we may skip covering the QUIC and HTTPS alternatives, unless we get feedback to the contrary. ### Section 3.1 I was unaware that the TLS handshake can be done not immediately after the TCP handshake as hinted by `Therefore, when a TCP connection is established for the service, a TLS handshake begins immediately.` or should this sentence be removed ? This clarification anticipates the STARTTLS discussion, wherein some TCP traffic may be processed before the handshake. Now that STARTTLS has been fully discounted, then, we will clarify to try to avoid confusion. s/separate TCP/IP port number /separate TCP port/ For Clarification Eric, can you let me know if the issue is the “/IP” or the “number”? We have recently ensured that all applicable mentions of “port” are are replaced with “port number”. ### Section 3.2 s/in which case the ticket might be invalidated/in which case the *session resumption* ticket might be invalidated/ I am not a security expert, but s/might/SHOULD/ seems more appropriate with an explanation *when* it can be kept. Understood. Proposed change, hopefully this will clarify: OLD: Why it closed has no bearing on TLS resumption, unless closed by a TLS error, in which case the ticket might be invalidated. NEW: Why it closed has no bearing on TLS resumption, unless closed by a TLS error, in which case it is possible that the ticket has been invalidated. ### Section 3.4.1 When can the "SHOULD" by bypassed in `TLS Cached Information Extension [RFC7924] SHOULD be implemented.` ? In prosaic terms: this caching enhancement is a specific enhancement to the stack, if it is not available in the stack, this doc would not preclude that stack being used. ### Section 7 Unsure how to read `IANA (has allocated) is requested ` as the IANA has not yet allocated a port number (you may want to suggest a value). Agreed, and this has been cleaned in a later version. Currently, we have: “The authors request that, when this draft is accepted by the working group, the OPSAWG Chairs submit a request to IANA for an early allocation, per [RFC4020<https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-07.html#RFC4020>] and [RFC6335<https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-07.html#RFC6335>], of a new well-known system TCP/IP port number for the service name "tacacss" (referenced in this document also as "TACACS+ TLS well-known port ([TBD])"), described as "TACACS+ over TLS". The service name "tacacss" follows the common practice of appending an "s" to the name given to the Non-TLS well-known port name. This allocation is justified in Section 5.3<https://www.ietf.org/archive/id/draft-ietf-opsawg-tacacs-tls13-07.html#wellknown>.This document requests IANA to add a new entity from the "Service name and Transport Protocol Port Number Registry" available at https://www.iana.org/assignments/service-name-port-numbers/” ### Operational considerations Should the impact of the use of mutual TLS authentication be described ? Notably the provisioning of certs to all peers. Probably, we have not identified all the operational impacts of mutual authentication, and I certainly agree that this specific you mentioned would be worth drawing attention to. We will draw attention to iot.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
