On Feb 12, 2016, at 2:03 PM, Brian E Carpenter <[email protected]> 
wrote:
> No, that it's *used* by many operators. However, the real point about putting 
> it
> on the standards track is that it would move change control of the text to 
> the IETF.

  TACACS+ the *existing* protocol is not under change control of the IETF.  
That's my reason for suggesting publication of the protocol *as it exists 
today* via an informational RFC.  First, to document it.  Second, to make it 
clear that the protocol being documented was not created under IETF change 
control.

  TACACS+ as it exists tomorrow is absolutely well within the scope of the 
IETF.  Any "future TACACS+" can be produced under IETF change control, with 
whatever label the IETF wants.

> That's a valid point to debate. Is there any win in that for the community, as
> opposed to leaving it entirely in the hands of "large companies"?

  I've tried to make my argument clear.  I have *never* suggested leaving the 
protocol entirely in the hands of large companies.

> If this was only about rubber-stamping I would agree with you.

  I see the current document as conflating the two points I discussed above. 

* As such, it comes across as "rubber stamping" the historical TACACS+ protocol 
as an IETF standard, because it's issuing a standards-track document for 
"historical TACACS+ plus TLS".

*  the OPSAWG is defining a new (to the world and IETF) standard network 
administration protocol as work so minor that it doesn't require a charter 
update, Where more commonly we would have a WG devoted to defining a critically 
important network administration protocol

*  It's an AAA protocol, but the AAA requirements shouldn't apply, because it's 
not really an AAA protocol.

*  It's a network management protocol for "device administration" or "device 
management", a use-case which is so vital that the phrases aren't even 
mentioned in the document.

*  It's not a new protocol because it's been around for 18 years, but in order 
to give the IETF change control, we have to add new bits and TLS transport... 
which makes it a new protocol.


  The whole thing looks like special pleading to me.

  As such, I'm requesting a clear separation of topics, and a clear statement 
of applicability.  That the historical protocol be documented separately from 
the future protocol.  That documents clearly state it's *not* a AAA protocol, 
and *should not* be used in situations where AAA protocols are used today.  
That it's a network management protocol, and it should be limited to that 
use-case.

  The thing which is amazing for me is that there is enormous push-back to my 
request for consistently applying logic, the IETF process, and IETF consensus.

  Alan DeKok.

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

Reply via email to