On Feb 11, 2016, at 2:36 PM, Eliot Lear <[email protected]> wrote: > 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.
I understand. I was involved in those discussions at the time. As a less public figure than I am now, but I was still a participant. > 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. I welcome new protocols (even old ones) to solve problems that existing protocols don't solve. > 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. Those are all good steps. I'd still like to know why it's necessary to have the cachet of an IETF standard for a protocol which is vendor-specific. And for which the *functional* change control will still reside with the vendors. And for which the vendors *could* have standardized it via an IETF protocol at any time in the past 20 years, and refused, because they saw benefits in bypassing the standardization process. i.e. the contents of any device management authorization exchange are entirely vendor specific, and due to the way TACACS+ is being used, *must* remain vendor-specific. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
