<at the end> ----- Original Message ----- From: "Eliot Lear" <[email protected]> Sent: Thursday, February 11, 2016 7:36 PM
Hi Alan, I'm not unsympathetic to the idea that we should focus efforts where possible, and I'm also not interested in piling on. But I think a comment is in order regarding RFC 3127 and then I have a proposal for a way forward. On 2/11/16 4:25 PM, Alan DeKok wrote: > > - even if there were no procedural issues, the document violates IETF consensus as described in RFC 3127 One has to put into perspective what was going on back then. Many different approaches were proposed to cover not only AAA but policy in general, and the market was at risk of fragmentation. There was a pretty visible and dare I say heated process at the IETF that turned into an attempt to align those who wanted to pursue policy with COPS and COPS-PR and those who wanted to do something with RADIUS/Diameter. RFC 3127 and its predecessor RFC 2989 represented hard work in the context of the efforts going on at the IETF at the time. It was a tool upon which the ADs relied to organize the work of O&M *at the time*. However, in the 15 interceding years, what's become clear is that RADIUS has broad applicability for a great many AAA uses; and for some cases TACACS+ is appropriate. For these purposes, such as command authorization, TACACS+ is a defacto standard, no matter what the IETF process says. The nascence of this space is long past. RFC 3127 was never intended to be a constraint so far into the future but rather a guide to ADs at the time as to how to proceed. The choice here, it seems to me, is really one of change control. I agree with you, Tom, and others who write that the IETF doesn't just rubber stamp protocols. On the other hand, changes should be made with due care toward what is deployed. I personally have faith that our processes and good community involvement would provide for a good path forward on this. In summary, if people want a standard, I propose the following way forward: 1. An applicability statement for TACACS+ that describes when TACACS+ is appropriate for use; 2. The proper following of working group process; 3. Appropriate and timely IPR declarations; and 4. It should be clear that the IETF has the necessary rights to effect changes. Thoughts/Comments? <tp> Eliot Looking at the Informational RFC in the RFC-index, I see Cisco Architecture for Lawful Intercept in IP Networks Cisco Systems NetFlow Services Export Version 9 Cisco's Mobile IPv4 Host Configuration Extensions Cisco Systems UniDirectional Link Detection (UDLD) Protocol Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material [mmm RADIUS!] etc etc so the question in my mind, is why not do the same now (especially as I understand that the work was started along these lines in 1997)? Mikael says "and if you wanted to provide IP core equipment, that's what you had to support" suggesting that a de facto standard exists and provides interoperability without any involvement of the IETF so again, an Informational RFC from a vendor would seem more than adequate. Why does anyone want Standards Track? I am suspicious until I have a plausible answer to that (IPR being only one area of suspicion and even a plausible answer may not allay my suspicions). Tom Petch Eliot ------------------------------------------------------------------------ -------- _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
