Hi, > Unless it is absolutely determined that the current work can't doesn't > meet criteria for an IETF standard, I would be opposed to such an > exercise. For one thing, we all have other things to do.
Contrary to that, many people on this list are arguing for their life on the do's or don't's in this area; it seems like they actually have *nothing* better to do than to fight for (or against) TACACS+. Which is a great start for a future working group, BTW; people with dedication and attitude are the fuel for IETF work. > For another, and as or more important, we would be denying the > reality of the situation. I would rather understand now what sort of > changes are being proposed in order for the current work to come up to > snuff. Sorry, I don't understand. The reality is that there's a TACACS+ protocol out there, and that there is a desirable TACACS+-to-be in some people's heads. I'm suggesting to split the documents exactly like reality does: one document for the TACACS+ protocol as it exists, one (or more, depending on the amount of things to be changed) for the future state of it. How is that denying reality? It's much more working with reality as I see it. Maybe my reality is different to yours. Stefan > > Eliot > > > > On 2/12/16 3:12 PM, Stefan Winter wrote: >> Hello, >> >> this debate has been going on for quite a while. It's multi-faceted, >> which doesn't help coming to conclusions. >> >> Maybe we can un-entangle one point: there are suggestions to either make >> this Standards Track or Informational; and one wheteher the protocol >> should be documented vs. improved. >> >> Maybe there should be two (or more) drafts instead: >> >> 1) The TACACS+ Protocol as Deployed in 2016 >> (Informational, *no changes*) >> >> 2-n) The New Feature X for TACACS+ >> (possibly Standards Track, one document per bolt-on feature) >> >> (one of the Xes being TLS encryption, but I'm sure there are more) >> >> Those voices on the list who demanded documentation can then happily >> accept Informational; the documentation is done either way. Those who >> opposed Standards Track for the durrent draft because it's about a >> protocol coming in from outside IETF can now go silent, because >> Informational addresses their concern. >> >> Those who demand new features can then put all their energy into a >> proper, per-feature argument with all those arguments collated in a >> per-topic document. Those who opposed the current draft for Standards >> Track can continue to oppose those new documents; this time in a focused >> discussion with less broadsides fired. >> >> If you can follow my line of thinking to this point, let's take it even >> one step further: we are now discussing a larger effort, involving >> multiple RFCs, taking an existing technology to a level it wasn't >> before. This is usually much rather a job for a working group in its own >> right, with a charter detailing which work happens when; not a job for a >> one-shot effort in the opsawg. >> >> So my ultimate suggestion would be: have a BoF at IETF95, try to form a >> working group, work on all issues that were brought up individually. >> >> (FWIW, this is exactly how RADIUS came to be... from an undocumented >> proprietary protcol to a successful IETF one. And guess what, even we >> had lengthy discussions about TLS encryption; debating is simply part of >> the culture) >> >> Greetings, >> >> Stefan Winter >> >> >> >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >
0x8A39DC66.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
