On Jun 29, 2022, at 2:26 PM, heasley <h...@shrubbery.net> wrote: > We have received no comments about this draft, which I presume means no > technical objections exist. So, I would like to ask the Chairs for an > adoption call.
I would suggest that ~3 weeks is a little too short a time frame to claim that there are no objections. I'll point to the previous TACACS+ document, where there were multiple reviews which got addressed by the authors many months later. I'll also point to my earlier review of draft-dahm-tacacs-tls13-00.txt, where I had concerns with extending the 1990s style TACACS+ packet format. The same concerns apply here. If we're going to extend TACACS+ by adding major new features, I would suggest that it's a priority to design these features correctly, the first time. Experience shows that it is extremely difficult to extend fixed-field packet formats. It's almost always better to use an extensible format, as with DHCPv4, DHCPv4, DNS options, YANG, RADIUS, Diameter, etc. Using a format with fixed fields now makes it more difficult to extend TACACS+ in the future. There will just be one complex format added after another. The alternative is instead to define an extensible format, in which case new extensions become trivial. Alan DeKok. _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
