On 6/27/2025 2:11 PM, Alan DeKok wrote:
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.
Exactly.
"Cisco Systems NetFlow Services Export Version 9" (RFC3954) was
documenting a Cisco protocol: what exist(s/ed), with no change control
given to the IETF. Hence Informational. IPFIX, on the hand, is Standard
Track
Exactly the same for TACACS+ RFC8907, again a Cisco protocol.
I guess we would not have these discussions if RFC 8907 would be called
"Cisco Systems TACACS+ Protocol"
I propose that we don't try to solve a problem that doesn't really exist.
Regards, Benoit
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]
