On 11/02/2016 20:21, "OPSAWG on behalf of [email protected]" <[email protected] on behalf of [email protected]> wrote:
>Send OPSAWG mailing list submissions to > [email protected] > >To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/opsawg >or, via email, send a message with subject or body 'help' to > [email protected] > >You can reach the person managing the list at > [email protected] > >When replying, please edit your Subject line so it is more specific >than "Re: Contents of OPSAWG digest..." > > >Today's Topics: > > 1. Re: Way forward? Re: Procedural issues with the TACACS+ > document (Alan DeKok) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 11 Feb 2016 15:21:03 -0500 >From: Alan DeKok <[email protected]> >To: Eliot Lear <[email protected]> >Cc: "[email protected]" <[email protected]> >Subject: Re: [OPSAWG] Way forward? Re: Procedural issues with the > TACACS+ document >Message-ID: <[email protected]> >Content-Type: text/plain; charset=us-ascii > >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. So the protocol itself is not intended to be vendor specific, and if you spot any vendor specific elements, please shout them out so that we can discard them. > And for which the *functional* change control will still reside with >the vendors. In terms of the data on top of the protocol, such as specific commands and arguments, then I think this is a higher level on the stack. I would suggest that this would generally be regarded as application layer configuration in the TACACS+ servers. > 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 am not aware of any refusal to standardise the TACACS+ protocol. In fact it was only a couple of years ago that I realised that TACACS+ had never been approved as a standard by IETF, it is so pervasive that I assumed it had been. I had it on my todo list to try to rectify that situation, and so when some engineers from outside Cisco, who were users of the protocol suggested moving forward with standardisation I was very happy to contribute, and generally the response has been favourable. > > 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. Certainly, the content that the protocol carries must be flexible enough to support the needs of whatever applications vendors and users need, as requirements evolve. But we can standardise the way the commands are encoded, and that is the purpose of the document. Is this level of standardisation, I.e. How device application level commands are encoded, acceptable to you, rathe than requiring we standardise the application level commands themselves? Thanks, Regards, Doug. > > Alan DeKok. > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 105, Issue 65 >*************************************** _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
