--- Original Message ----- From: "Warren Kumari" <[email protected]> To: <[email protected]> Sent: Monday, February 15, 2016 8:14 PM > Dear OpsAWG: > > This is the second of three messages [0] to determine what the OpsAWG > should do with TACACS+ > > Should the ID, as presented, or as revised by the WG, be published as one > or more RFCs?
No, it should not. A similar situation arose with syslog, a widely used, well-understood protocol without a standard definition. In this case, the aim was for the IETF to add security so first, it had to define the protocol, which it did with RFC3164. The I-D adding security seemed to progress well until it ran into strong objections at IETF meetings which led to substantial changes, essentially saying that RFC3164 got it wrong, that it may describe one flavour of syslog but that it did not describe what was in widespread use. In due course, RFC5424 appeared and is an excellent RFC. But ... some time later, the question arose, on an IETF list, did it describe what was happening in the Internet, and the feeling was that it did not. When the time came to model syslog in YANG, the authors of the I-D looked at five implementations and then chose the obsoleted, Informational RFC3164 as the best description of the protocol! So is the IETF's Standards track specification of syslog of any benefit to the Internet? The problem is that for all the following of the correct procedures by the syslog WG, documenting consensus, gaining participation and so on, the end result is flaky. With hindsight, I think that the syslog WG did not have a wide enough participation to represent all the different flavours of the protocol and that if it had have, then it might have been clear that a single, Standards track specification was impossible. You may have pairwise compatability between the products of six different manufacturers with TACACS+ but that just may mean that each manufacturer has learnt that, in the market place, they have to cope with five other flavours of the protocol to sell a product and that a single specification does not exist. (Famously, there have been cases of Microsoft getting a specification wrong and smaller manufacturers then building faults into their products in order to interoperate - such is the commercial world). So, I believe that the IETF should not get involved with TACACS+; for all the enthusiasm displayed on the list, we do not have sufficiently wide skills. I do not doubt the wishes of those on the list to have a Standards track specification but that does not mean that it is possible to produce such a specification that reflects what is happening on the Internet. (It would, of course, be different if, as has happened in other cases, a trade body came to the IETF and asked for their work to come under the change control of the IETF but I see no evidence that such a body exists; or, if a manufacturer, say Xxx, wants to submit an ISE I-D on "Xxx's implementation of TACACS+", then I would fine with that). Tom Petch p.s. You do not say which I-D - I assume draft-ietf-opsawg-tacacs-00 and not draft-grant-tacacs-02.txt - but from my perspective, that makes no difference. > Scott, Tianran and Warren > > [0]: The first one was the IPR one ( "Untangling - Explicit call for IPR on > draft-ietf-opsawg-tacacs-00") > ------------------------------------------------------------------------ -------- > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
