Let me follow up on that, to make sure there are no obstacles form that perspective.
On 11/02/2016 17:09, "t.petch" <[email protected]> wrote: ><at the bottom> > >Tom Petch > >----- Original Message ----- >From: "Andrej Ota" <[email protected]> >Sent: Thursday, February 11, 2016 12:29 PM > > >> I'll try to answer multiple points from multiple e-mails to try to >avoid >> fragmented discussion. I do not dispute errors or omissions I made and >> which were pointed out. >> >> On he topic of 1st, 2nd, ... AAA protocol: >> My intention was not an ad hominem attack, but I did want to convey my >> strong aversion to statement implying TACACS+ is a late arrival when >it is >> in fact a protocol we have been living with for almost 20 years >without it >> ever being standardised or agreed upon. A feat I do not wish to be >> discounted or ignored, regardless of its origin. Ignoring it serves no >> useful purpose and I don't see it as benefiting anyone who wishes to >> discuss protocols and standardisation on the merit of usefulness to >the >> network operator and vendor communities. >> >> >> On the topic of relation to other AAA protocols: >> TACACS+ definitely is AAA protocol and as such can be seen and used as >a >> competitor to RADIUS. At the same time I do not see it as a direct >> replacement (to consider it a viable competitor) as it caters to a >very >> specific niche related to a very specific work. Track record from last >20 >> years demonstrates the difference in scopes. Is it competing with >RADIUS? I >> would rather say that RADIUS is competing with TACACS+ at this niche >for >> last 20 years and still not doing a stellar job at it. >> >> 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 don't even know what to say about alleged push of vendors *against* >> RADIUS. I have to deal with few of vendors that only implement RADIUS >and >> not TACACS+ while I have yet to bump into a vendor which does the >opposite. >> >> >> 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. >> >> Having done this, we cannot honestly call this an informational RFC in >the >> sense of how RFC 3164 was informational. >> >> >> On the topic of vendor-specific and the message that IETF sends: >> I'm sure I'm missing something here, but from what I understand, the >main >> objection is procedural as in the draft wasn't properly adopted by >> workgroup to work on it. As long as that is addressed in accordance >with >> the procedure, the draft could become IETF draft which WG would >discuss and >> modify as it sees fit and one which could ultimately be considered for >> standards track RFC. I though we were in that process, but if it was >> botched, we certainly want to have that addressed. >> >> I understand and appreciate the sensitivity of IETF even appearing to >give >> "a seal of approval" to some random vendor stuff. I certainly know how >this >> work could be misinterpreted if not handled in a very transparent >manner. >> But instead of a flat out refusal to deal with this protocol as it >stands >> today, I would like to appeal for suggestions on how to address this >in >> order to bring value to the community and industry. It's clear that >this >> was originally a proprietary protocol. I also think it became more >than >> that over two decades of use in a very specific niche area where AAA >is >> used in network operations. With multi-vendor adoption and willingness >of >> original authors to release it to current IETF process (copyrights, >IPR and >> all included) I think we can accept both negative legacy and its >> practically demonstrated usability and viability while not encroaching >on >> the territories which are undisputedly RADIUS and Diameter dominated. >> >> >> On the topic of slapping anyone in the face: >> Continued long-term existence of non-IETF and non-RFC AAA protocol, >its >> widespread adoption in a single niche area and impact it has on the >day to >> day network operations cannot be ignored or discounted. As much as >RADIUS >> can be used in the same niche (as any other AAA protocol and other >stuff >> like LDAP can be used for the same purpose), it did not supplant the >> non-standard solution for the last 20 years. I do not see how TACACS+ >RFC >> (if it ever comes to it) would change this. >> >> While IETF is and should be forward-looking in defining how things >could >> and should be done better, this doesn't mean that it should avoid >dealing >> with sometimes ugly issues at hand as long as the work helps the >community >> of users and vendors to do their work more efficiently. >> >> >> 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. >> >> My personal opinion is that TACACS+ is simple and dumb enough protocol >to >> be cheap to implement and still fit for the purpose. This two >properties >> combined make it an attractive choice for both users and vendors. >> >> My personal experience is that TACACS+ appears to work more >consistently >> over a range of different vendors than I can say for devices which >provide >> RADIUS exclusively. I also find it easier to diagnose and debug as it >uses >> reliable transport. RFC6613 was supposed to change the latter, but >after 3+ >> years I still don't see it adopted for the purpose of network >management >> AAA. >> >> >> On the topic of proprietary and vendor lock-in: >> I don't see any evidence of vendor lock-in after 20 years of use, but >I do >> see a risk because there is no authoritative and standard definition >of >> what is TACACS+. The IETF process is aimed to address this and I don't >> think calling out current proprietary status is an argument against >> considering the proposal, but rather an argument to work on a >proposal. >> >> The IETF process should ensure that proprietary monicker is removed >after >> all conditions are met. Proprietary protocol probably isn't evil by >itself, >> but is made evil by the fact that even the original author cannot be >held >> accountable if it changes it or ignores it. This effort aims to >address >> that as well and is an argument to work on the proposal, not throwing >it >> out. >> >> Current state of IPR for any TACACS+ implementor is unknown. The IETF >> process must and will ensure that all IPR will be ultimately disclosed >> which will take away a lot of stress an unknowns from both vendors and >> users. How can this ever be a wrong thing to do and how could it be >bad if >> IETF is the one forcing the issue? I again see this as an argument to >work >> on this within IETF and not reject all work on it. > >The IETF process is that each contributor must disclose any known IPR - >"all those contributing to the working group's discussions must disclose >the existence of any IPR the Contributor or other IETF participant >believes Covers or may ultimately Cover the technology under >discussion." [BCP0079] >except that I know that US legal liability makes companies there keep >their staff in ignorance of such IPR so what I expect, and do not yet >see, is a disclosure from the company in question. That can and does >make a difference to the decisions of the IETF. > >Tom Petch > > >> >> -- >> -- >> Andrej Ota >> >> Google Ireland Ltd., Google Docks, Barrow St., Dublin 4, Ireland >> Registered in Dublin, Ireland - Registration # 368047 >> > > >------------------------------------------------------------------------ >-------- > > >> _______________________________________________ >> OPSAWG mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg >> > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
