----- Original Message ----- From: "Alan DeKok" <[email protected]> To: "Eliot Lear" <[email protected]> Sent: Friday, February 12, 2016 12:23 PM
On Feb 12, 2016, at 5:19 AM, Eliot Lear <[email protected]> wrote: > Actually the work started long before THAT, even. I think it dates to > 1993 if memory serves. RFC1492 is dated July 1993 but what I find more interesting than the timeline is the content of that RFC " The original TACACS protocol specification does exist. However, due to copyright issues, I was not able to obtain a copy of this document and this lack of access is the main reason for the writing of this document. This version of the specification was developed with the assistance of Cisco Systems, who has an implementation of the TACACS protocol that is believed to be compatible with the original specification. To be precise, the Cisco Systems implementation supports both the simple (non-extended) and extended versions. It is the simple version that would be compatible with the original. Please keep in mind that this is an informational RFC and does not specify a standard, and that more information may be uncovered in the future (i.e., the original specification may become available) that could cause parts of this document to be known to be incorrect." which I find delightful. How you build an Internet Standard with that as a starting point I am unsure but an ISE submission from an involved manufacturer (which, in the end, the IESG has to say does or does not conflict with the work of the IETF) would seem more appropriate. Tom Petch Pretty much. RFC 2989 and RFC 3127 are the outcomes (~y2000), not the start of the process. > But speaking plainly, this isn't a science experiment. It isn't > something anyone is floating as a suggestion. It's what's being done in > the network today, and it is supported across multiple implementations. > It is a defacto standard. Like IPX, or any number of other non-IETF protocols. That doesn't mean they deserve RFC status, much less a standards track document. > Unless there's very good reason not to do > so[*], let's just call it what it is. And again, I would reiterate: > let's also make clear what it's not. A good applicability statement > should help with that. > > Eliot > [*] A very good reason would be if it doesn't meet the requirements for > specifications that the IETF generally laid out. The discussion here has been that TACACS+ is a AAA protocol. If I believe that, I also have to believe that it's such a terrible AAA protocol, that it wasn't even considered in the discussion in RFC 3127. i.e. at the time the original draft was published, the major networking companies (including Cisco via their employees) and the ITEF consensus was that TACACS+ was not suitable for consideration as an AAA protocol. We're welcome to re-visit that decision. Priorities change, and we learn new things. But the cognitive dissonance here is mind-boggling. People say that TACACS+ is a AAA protocol, but the requirements on AAA protocols don't apply, because it's not a AAA protocol. It's a device management protocol. Even though the document doesn't describe device management, or even contain the terms "device management" or "device administration". By that logic, war is peace, freedom is slavery, ignorance is strength. I've asked repeatedly why the document should be granted standards track status. The argument is largely "it's widely used". Well, so what? Many other protocols are *more* widely used, and aren't standards track. Again, while there are many widely used protools as information, or not even RFCs, while there are inconsistent arguments in favour of the protocol, while a self-described AAA protocol goes against IETF consensus, while a self-described AAA protocol is so inadequate that it wasn't even considered in RFC 3127, while there were procedural issues making it a WG document... Why, exactly, are is the WG full-steam ahead in making it a standards track document? It looks like the IETF ideal of "individuals" is failing here. There are large forces behind the scenes pushing for standardization, and that is winning over petty things like individuals without deep pockets, and IETF process. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
