Hi Rod,
Many thanks for your kind words and previous feedback which helped
significantly.
Regarding your comment, It is a good proposal, but just to clarify, the paras
are intended to convey from the flow perspective: para 4 covers the client
start, para 5 then deals with server behaviour i.e. receiving from the client
and responding) para 6 then deals with the client receiving the response from
the server.
Maybe if these paras had a line prefixing to explain this intent, then it would
reduce the dissonance if reading from the perspective of one component rather
than the flow?
Date: Thu, 27 Jun 2024 12:11:13 +0000
From: Rod Persky <rodper...@microsoft.com>
Subject: [OPSAWG]Re: WG LC: draft-ietf-opsawg-tacacs-tls13
To: "opsawg@ietf.org" <opsawg@ietf.org>
Message-ID: <si2p153mb07195268c5d8975dbd1cf590be...@si2p153mb0719.apc
P153.PROD.OUTLOOK.COM>
Content-Type: multipart/alternative; boundary="_000_SI2P153MB071952
68C5D8975DBD1CF590BED72SI2P153MB0719APCP_"
Hi Everyone,
Great work here! I'm really looking forward to having the TACACS+ with TLS
(TACACSS) protocol progressed, I've been reading the drafts and am glad for the
work everyone has put into progressing this.
Revision 8 brought clarity for SS 3.3. TLS Identification which I had most
concerns about, the document now has a great description for the TLS
identification methods.
I wonder however if there were to be any more revisions if Section 4.
Obsolescence of TACACS+ Obfuscation could be made a bit simpler with paragraphs
4 and 6, both related to how the client handles session packets, being combined.
Kind Regards,
Rod Persky
***********************************
_______________________________________________
OPSAWG mailing list -- opsawg@ietf.org
To unsubscribe send an email to opsawg-le...@ietf.org
