[OPS-DIR]Re: Opsdir last call review of draft-ietf-opsawg-tacacs-tls13-18

["Joe Clarke (jclarke)" <[e-mail]>]

Thanks, Qin.  The authors have published -19 and look to have incorporated your nit fixes.  Can you confirm https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-tacacs-tls13-19 looks okay, and if so amend your DIR review to Ready?  Thanks.

Joe

From: Qin Wu via Datatracker <[e-mail]>
Date: Thursday, March 13, 2025 at 04:26
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
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.