Hi Alan, TACACS+ cannot compete with RADIUS in the area RADIUS is strong: for Network access. The authors have no interest in trying to do so.
TACACS+ in 2016 has quite a different use case: for device administration, where it is widely deployed by multiple vendors. Its application for device administration is why the authors approached opsawg. The authors believe that it has a place for device administration in the datacenter and would seek to get the TACACS+ protocol definition documented and straightened out for this purpose, and registered with IETF. I understand that you hold different view in this matter. I¹m sure that the IETF checks and balances will resolve the conflict for the best interests of the whole, and I¹ll happily follow their decision. I don¹t think there was any conspiracy by Cisco not to pursue the publication before. Cisco initiated the process to get the protocol approved by IETF in 1996/1997 (https://tools.ietf.org/html/draft-grant-tacacs-02), but the original authors pursued other endeavours, and no one followed up until now, with a process that actually started up outside Cisco. Regarding procedural matters, if we have missed any steps, that is my bad and I will consult with those more versed in procedure to rectify that. Best Regards, Doug. On 10/02/2016 20:57, "Alan DeKok" <[email protected]> wrote: > And some more notes > >7. The charter says: > >"The Operations and Management Area receives occasional proposals for >the development and publication of RFCs dealing with operational and >management topics that are not in scope of an existing working group >and do not justify the formation of a new working group. " > >8. This document is competes directly with two existing working groups, >RADEXT and DIME, to create a third AAA protocol. > >9. As such, this document should be explicitly outside of the scope of >the OPSAWG. > >> On Feb 10, 2016, at 3:51 PM, Alan DeKok <[email protected]> >>wrote: >> >> On Feb 10, 2016, at 3:31 PM, Alan DeKok <[email protected]> >>wrote: >>> There are a host of procedural problems with how the document was >>>adopted. I suggest that the document be withdrawn, and re-submitted as >>>an individual draft. >> >> To be clear: >> >> 1. the document never had a WG call for adoption as required in Section >>4.2.1 of RFC 6174 >> >> 2. the charter has not been updated to reflect this work. >> >> 3. the charter says: >> >> "All new work items and rechartering proposals will be brought for >>approval with the IESG." >> >> 4. I can find no record of this approval taking place. If it had taken >>place, the charter would have been updated. >> >> 5. I had objected to this in person at the OPSAWG meeting in IETF 94. >>However, the web site shows no minutes from that meeting: >> >> https://tools.ietf.org/wg/opsawg/minutes >> >> 6. I believe that this document is an incorrect technical choice as per >>section 6.5.1 of RFC 2016. >> >> As such, I ask the chairs to withdraw the document as a WG document >>until such time as the procedural issues above have been addressed. >> >> Alan DeKok. >> >> _______________________________________________ >> OPSAWG mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
