Hi John, Thank you for your notes. Please see our comments below.
> On Nov 13, 2025, at 2:13 PM, [email protected] wrote: > > Wed, Nov 12, 2025 at 03:28:45PM -0800, Sandy Ginoza: >> Hi John, >> >> I’m not sure if we’re saying capitalized “Peer” is correct or if there is a >> preference for the other update Med suggested: >> >> NEW2: >> TLS TACACS+ connections are generally not long-lived. The connection >> will be closed by either a peer if it encounters an error >> or an inactivity timeout. > > hi. Sorry, I mean that capital P is correct. Meaning that either the > server or the client may close the connection. > >> Regarding capitalization, seemingly, lowercase is consistent with use >> throughout the document. The term is capitalized as the definition entry in >> Section 2, but it is lowercased in running text. > > As editor, please educate/correct me. My understanding is that "Peer" is > not the same as "peer"; the former having been defined in section 2. The > distinction disambiguates which definition is intended. While we see that “Peer” is defined in section 2, the capitalized form only appears in the instances noted below. Because “Peer” only seems to appear as a term or at the beginning of a sentence, we did not realize capitalization was important here. If changes are needed, please let us know. We are not confident we can accurately differentiate between peer in general and Peer defined in section 2. Peer: The peer of a TACACS+ client (or server) in the context of a TACACS+ connection, is a TACACS+ server (or client). Together, the ends of a TACACS+ connection are referred to as peers. 2. Peer authentication: The authentication capabilities of TLS replace the shared secrets of obfuscation for mutual authentication. Peers implementing the TACACS+ protocol variant defined in this document MUST apply mutual authentication and encrypt all data exchanged between them. … Peers MUST NOT use obfuscation with TLS. > While it might not be the case that all occurances should be capitalized, > it was definitely used more than once. Honestly, I think that I missed > some edits. I will re-read the entire document on the plane tomorrow. > > Over-loading the term was clearly a mistake - mine. Perhaps a better > solution is to replace it with one lacking a collision. None come to > mind ATM. We agree this would be ideal, especially as we expect this will be an issue in future documents using the same term. Unfortunately, we also do not have a good suggestion at this time. Please let us know how you would like to update the document. Thank you, Sandy Ginoza RFC Production Center -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
