I like this idea! As it happens, the original motivation was simply to secure T+ and clean up the text of the original draft spec. We were less radical that moving to JSON (that¹s a nice idea ;-)) we originally intended to support the old protocol for backwards compatibility and add TLS for the much-needed security. However the consensus was reached in the WG instead for a two phased approach to document the plain protocol first and to follow up with a document which detailed securing the protocol. Rather than admitting simply that the protocol was insecure and how to fix it, we have taken a little longer than originally intended to complete the first phase.
I suspect our efforts may get overtaken soon by de facto securing of T+ anyway... >------------------------------ > >Message: 4 >Date: Sat, 13 May 2017 13:21:43 -0400 >From: Robert Drake <rdr...@direcpath.com> >To: <opsawg@ietf.org> >Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, > Status and Plans >Message-ID: <733ad85f-203e-e252-046f-402af2f23...@direcpath.com> >Content-Type: text/plain; charset="utf-8"; format=flowed > > >On 5/13/2017 7:59 AM, Alan DeKok wrote: >> If you're not going to work towards WG consensus, I suggest the >>chairs replace you with authors who will. >That seems unnecessarily rude. > > >This draft is still about documenting the existing tacacs+ protocol >right? Why? > >You've been discussing this thing for a year and can't reach a consensus >about an existing protocol. I doubt very strongly that a completed >document will be useful to anyone. Nobody needs this to implement the >existing protocol. > >My personal belief is that extending the protocol isn't a good idea >anymore. Instead just rewrite it to use HTTPS/TLS transport with >JSON/XML encoding. That should cut out about half of the documentation >in the draft. The new protocol doesn't have to run on the same port. >It could use 443 or whatever the user declares in the connection URI. >Vendors could leave their existing tacacs+ client in the code until >people don't need it anymore. Servers could be adapted to support both >protocols. > >The most important thing to me is that something gets created. This >should be moving from a thought experiment to a reference implementation >so that people can comment on the details. > > > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >OPSAWG mailing list >OPSAWG@ietf.org >https://www.ietf.org/mailman/listinfo/opsawg > > >------------------------------ > >End of OPSAWG Digest, Vol 120, Issue 6 >************************************** _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
