I believe the content isn¹t entirely vendor specific. For example, for command authorisation, the standard authorisation packet from the document is:
service=shell cmd=<command name> cmd-arg=<arg1> cmd-arg=<arg2> ... This level of content is specified in the document, but if the comment is that it is insufficiently clear then I would accept that and we can raise its visibility. If, on the other hand you mean that the <command name> and <argN> are vendor specific, then clearly, this is the case, but that is a feature of a higher level in the stack than this document could specify. 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. 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. > > > >------------------------------ > >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
