On Feb 10, 2016, at 5:17 PM, Douglas Gash (dcmgash) <[email protected]> wrote:
> TACACS+ cannot compete with RADIUS in the area RADIUS is strong: for
> Network access. The authors have no interest in trying to do so.

  Realistically TACACS+ is an AAA protocol with full AAA functionality.  As 
such, it is competing 100% with RADIUS.

> TACACS+ in 2016 has quite a different use case: for device administration,
> where it is widely deployed by multiple vendors.

  The solution to a common device administration problem would be to either 
create an IETF protocol, or to leverage an existing one.

  Please suggest how:

1) publishing TACACS+ as an *IETF standard* is required to document it

2) any functionality in TACACS+ cannot be implemented in RADIUS

> 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.

  There are many device administration protocols in the IETF.  SNMP for one.

  So this response is a bit too vague to be explanatory.  Call me dumb, but I 
would like to have a clear statement as to what TACACS+ does that RADIUS 
doesn't.

> 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.

  The IETF consensus for the last 20 years is that RADIUS, and then Diameter, 
are the IETF AAA protocols.

  I see no technical reason to re-visit that decision now.

> 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.

  The chairs and ADs are responsible for process administration, not the 
document authors.

  Alan DeKok.

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to