Please enlighten me - what did IETF have to do with the TACACS running code? Did anybody among those who want it on the standards track even see the sources of that code (and could point me at an available reference implementation)?
Normally a protocol completed outside of IETF is described in an Informational RFC if it's popular enough to justify that. TACACS is deployed widely enough, no argument there - but why should a protocol that managed to get born, deployed, and wide-spread for more than two decades, suddenly need an IETF standards-track RFC to define it? Why isn't Informational good enough? I've no stake in this fight, and don't really care - just want to hear the reasons. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Benson Schliesser Sent: Tuesday, February 16, 2016 18:14 To: Randy Bush Cc: opsawg Subject: Re: [OPSAWG] Detangling - Q3: Publish TACACS+ as a standards track RFC? +1 to Randy's observation. It's almost as if we value our own opinions more than we value running code... -Benson On Tuesday, February 16, 2016, Randy Bush <[email protected]> wrote: >> One thing to keep in mind is that, if the document describing the >> currently deployed protocol is informational, we may have a tricky time >> making the extensions be standards track; it would (presumably) require >> a downref. > > it would; it is not logically a huge problem, merely wierd. > > I doubt very much that a push for better securing of an existing mature > protocol is the likely source of controversy there. what is amusing is that some folk seem to be contemplating that the rfc of an old and widely distributed and used protocol should not be standard. randy _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
