Many Thanks Qin, We’ll clean up the nits doc for the next revision (19)
From: Qin Wu via Datatracker <nore...@ietf.org> Date: Thursday, 13 March 2025 at 08:26 To: ops-...@ietf.org <ops-...@ietf.org> Cc: draft-ietf-opsawg-tacacs-tls13....@ietf.org <draft-ietf-opsawg-tacacs-tls13....@ietf.org>, last-c...@ietf.org <last-c...@ietf.org>, opsawg@ietf.org <opsawg@ietf.org> Subject: Opsdir last call review of draft-ietf-opsawg-tacacs-tls13-18 Reviewer: Qin Wu Review result: Has Nits I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document updates the TACACS+ protocol to use TLS 1.3 for confidentiality, integrity and authentication and obsolete insecure mechanism defined in RFC8907. This document is on the right track and I believe it is ready for publication. However I have a few comments on the latest v-18. Major issues: No Minor issues: No Nits: 1. Section 2 Technical Definition Section 2 mostly focus on new terminology definition, it is not reasonable to add section number for each term, suggest to remove section number such as section 2.1, 2.2, 2.3, etc. 2. Section 3.1 OLD TEXT: “ This way the client can ensure that TLS and non TLS traffic are separated even where default port numbers are omitted from its TACACS+ server connection configuration.¶ ” NEW TEXT: “ Through this way the client can ensure that TLS and non TLS traffic are separated even where default port numbers are omitted from its TACACS+ server connection configuration.¶ “ 3. Section 3.4 said: “ TLS Cached Information Extension [RFC7924] SHOULD be implemented. This MAY be augmented with Raw Public Keys [RFC7250], though revocation must be handled as it is not part of the standard ” Why revocation must be handled as it is not part of standard, has no clue. 4. Section 7 OLD TEXT: “ 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] and [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". “ NEW TEXT: “ IANA has allocated a new well-known system TCP/IP port number for the service name "tacacss", per [RFC4020] and [RFC6335] (referenced in this document also as "TACACS+ TLS well-known port ([TBD])"), described as "TACACS+ over TLS". ” 5. Section 6.1 said " the operator must consider the impact of mixed TLS and Non-TLS on security " which security impact of mixed TLS and Non-TLS should be considered? Something specified in section 5, if yes, please make it clear.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
