Thanks for the history of this (I didn't realize that tacacs+ wasn't an IETF protocol). As it stands after this past telechat, it just looks a little funny (nothing wrong with looking funny). The weirdness is that you have a widely deployed protocol that is not even PS (the same logic goes for radius and the other protocols mentioned). It is (academically) interesting to see which protocols update and evolve on some schedule and which are set in concrete. Building protocols that allow evolution and transition is apparently hard (shrug).
Thanks for the time and effort to reply, Deb Cooley On Fri, Jun 27, 2025 at 8:55 AM Benoit Claise <[email protected]> wrote: > > > > 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]
