Certainly we will add more detail to the specification to ensure that there is no ambiguity that:
1) The focus of the specification is to support the device administration use case, and to describe what this means. 2) That there is no intent to compete with other protocols (such as RADIUS/DIAMETER) for the network access use case. On 11/02/2016 19:46, "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: Procedural issues with the TACACS+ document (Robert Drake) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 11 Feb 2016 14:46:11 -0500 >From: Robert Drake <[email protected]> >To: <[email protected]> >Subject: Re: [OPSAWG] Procedural issues with the TACACS+ document >Message-ID: <[email protected]> >Content-Type: text/plain; charset="windows-1252"; format=flowed > > > >On 2/11/2016 9:06 AM, Alan DeKok wrote: >> I'll reply mostly in summary. >> >> TACACS+ is a late arrival to the IETF. It was never considered as >>an AAA protocol by the IETF. 20 years of IETF consensus is that TACACS+ >>is not an IETF protocol. It is not appropriate for a WG to re-consider >>that decision without a larger involvement from the IETF. The fact that >>a proprietary version of TACACS+ is also 20 years old is irrelevant to >>the IETF process. If we ignore the IETF process here, we might as well >>shut down the IETF as irrelevant. >> >> One WG should not be able to over-rule the rest of the IETF. > >Does another WG want to take up the reins of fixing TACACS+? > >> >> TACACS+ catering to a "nice" related to specific work is command >>authorization, or device administration. This use case is so niche that >>it isn't even mentioned in the draft. This use-case *remains* a >>vendor-specific proprietary protocol. It's successfully competed with >>RADIUS in this space because the vendor refused to standardize command >>authorization in RADIUS. Most likely because they saw it as a >>competitive advantage. >> >> So... TACACS+ competed with RADIUS by forcing customers to use a >>proprietary protocol, to the detriment of the standards. And the reward >>for 20 years of this anticompetitive behaviour, is that we reward the >>vendor with the label "IETF approved - standards track protocol". >> >> Again, there is *zero* technical reason to make TACACS+ a standards >>track document. There are many procedural reasons to avoid making >>TACACS+ a standards track document. i.e. 20 years of IETF consensus. >> >> Those are my objections. Please explain how the document is >>*massively different* for implementors with two words changed: >>"Informational" versus "Standards Tack". Please explain why we should >>ignore 20 years of IETF consensus. > >Does anyone want to take up the reins of fixing the procedural errors of >the TACACS+ draft so it meets the requirements for standards track? > >> >>> Is there a meaningful way to address this difference in scopes? Would >>>it help if we make it explicitly about network element AAA for >>>management purposes and avoid chatting about NAS? >> I have no objection to standardization of the functionality which is >>now proprietary in TACACS+. I think it's a good idea. But >>rubber-stamping TACACS+ without even *mentioning* device management in >>the draft is bizarre at best. >I would say it's an oversight and not malicious. Perhaps writing the >authors and asking them to add something about this would be good, or if >you like you might contribute a paragraph or two. It looks like the >original draft does mention device management in the Abstract, as well >as giving documentation on how to do authorization and accounting for >commands (as part of the REQUEST packet body). > >I haven't looked again at the new draft to see if it retains that >information, but if not it probably needs to be put back in. > > >>> On the topic of informational vs. standards track: >>> Authors are aiming for standards track due to two reasons: >>> 1) In the face of differing implementations, we cannot provide a >>>simple recap of what works but we feel we have to make a statement on >>>how it should work in the first place (e.g. removing ambiguities) >>>without introducing major incompatibilities. >>> 2) Device management AAA as used in the field today carries security >>>risks. To address some of them, authors decided to slap some lipstick >>>on a pig in the form of TLS tunnel. >> Neither of those reasons requires a standards track document. >I would argue #1 does require standards track, unless the difference >between "standards track" and "informational" is largely academic. We >need to be able to push vendors on compatibility. I don't know enough >about the IETF processes to know if this is really true, but I don't >think there would be 50 emails about this if it was okay with everyone >to change to informational. > ><deleted some stuff below here> >> >>> On the topic of technical benefits: >>> There must be something that TACACS+ is doing at least good enough >>>while RADIUS isn't doing it so much better to replace it. >> Command authorization, because the vendor refuses to standardize it >>in RADIUS. Which they could have done any time in the last 20 years. >>They refused. >> >> Well... they refused. I fail to see how refusing to follow the >>standards process means the we should reward them with an official >>standards track RFC. >Is the RADIUS WG going to add support for command authorization? It >seems like if RADIUS wanted this then one vendor refusing to submit a >standard wouldn't be a barrier. Surely anyone could write a standard >and propose it as a draft? > > >> >> Alan DeKok. >Robert > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 105, Issue 61 >*************************************** _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
