On Jun 27, 2025, at 7:40 AM, [email protected] wrote: > I hear you, but the situation is more complex. > Upleveling the full protocol to PS is a distinct work item vs what the WG > agreed and committed to deliver. That work would end up BTW with specifying > “something” that is not interoperable with the currently widely deployed > TACACS+. I’m not sure we are ready for TACACS+ to have the same situation we > had with SYSLOG (RFC 3164, RFC5424), Cisco NETFLOW > (RFC3954)/IPFIX(RFC5101-RFC7011), and so on. That discussion should happen > outside the rush of IESG telechats :-) > Once we publish the TLS extension, the WG can start that discussion (if it > whishes so) and see if there are volunteers/interest from the operators > community to explore that path.
On a strictly technical note, RFC8907 is simply documenting the protocol which has been around for decades. Its status is informational because the original specification was developed outside of the IETF. i.e. the IETF did not have change control over the specification. The TLS document is standards track, because it's entirely new (i.e. no one implemented TLS support), and the spec is under IETF change control. The question then, is what benefit is there to making the base protocol standards track? We can't really change anything in the protocol, as there are perhaps millions of deployments of it. So we would be left with a very narrow set of choices: a) make RFC8907 standards track as-is, with no changes b) Publish the TLS document as standards track, but leave it as just "wrapping" RFC8907 in TLS, and leave RFC8907 alone. c) Add the RFC8907 text to the TLS document, and make the resulting document standards track. Option (b) is the least amount of work. It also means that the base protocol is well documented, even if it has "informational" status. I'll also note that most implementers tend to blur the lines between "informational" and "standards" RFCs. Option (a) is relatively simple, but I don't know why it's useful. Simply changing the document label won't affect much, because we can't change the underlying protocol. Option (c) is just copying text, and has the same issues as option (a). So I'm not sure why there's a push for the PS label. What practical benefit does it have? And if the WG isn't prepared to put in the effort to revisit / rewrite the document, it seems that it won't happen anyways. I'll also note that RADIUS accounting (RFC2866) is also informational. It's been much more widely deployed than TACACS+. Do we want to revisit that, too? FWIW, RFC2866 was made informational because the IESG at the time didn't want to standardize a protocol which could lose accounting / billing data. 30+ years of deployments have shown that this isn't much of an issue in practice. My $0.02 is to leave RFC8907 alone, and to publish the TLS document as-is. IMHO there is insufficient resources to make TACACS+ standards track. There is very little benefit to simply putting a "PS" label on an un-changed RFC8907. Alan DeKok. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
