On Nov 12, 2020, at 5:02 PM, Toerless Eckert <[email protected]> wrote: > > Interesting document (RFC8907). > > Several problems i see that would be good to avoid (althoigh not all are > applicable to subject draft): > > - The RFC It does not mention who developed the protocol. It may be clear to > the ones in the know > (or who read THEDRAFT), but i remember older RFCs that clearly state when a > protocol > is a proprietary vendor protocol not developed by the IETF. I think this RFC > should > have done it too for clarity. BY not writing it clearly, it looks like a > particular > vendor endorsement by IETF in an inappropriate fashion.
That's a reasonable point. But the doc is "Informational", and the protocol has a 20+ year history. So it's pretty clear where it came from. And, that documentation does not imply endorsement. > - This RFC does not not explain who has change control over the protocol. I > would guess > that Cisco wants to maintain change control, but the fact alone that i have > to guess > and that this is not written out makes this a problematic IETF product. Which is why the specification is Informational. It documents existing practices. Updates to the protocol (if any) will be under IETF change control. > - This RFC does seem to mix the solely vendor defined and controlled protocol > with > a profile subset of what the IETF WG deemed to be important enough for > todays use, > but it merges both into a single document. It would have IMHO be a lot > better to > have had a separate document just for the proprietary protocol (in whatever > form, > independent submissions seems good), and then a small RFC solely with the > profile. > That profile RFC could then even have been a BCP. There was a very long discussion about this topic. The document describes WG consensus. In short, there was significant objection (including at the IESG level) to documenting insecure parts of the protocol, even if it was just historical practices. The decision was to document what "worked", while deprecating the worst parts. The remaining bits were acceptable under the "holding your nose" kind of thing. > - Of course, if change control would have been given up by Cisco and passed > to IETF > and this was written into the document, then merging the proprietary > protocol with > the IETF WG defined profile would be ok. Still not my preference. The WG discussion was that any next step was to write a spec which pretty much wraps TACACS+ in TLS, and call it secure. There are additional details, but that's the basic idea. Given the larger implementation deployment of the legacy TACACS+ protocol, it's simply impossible to make substantive changes to it. i.e. any "clean room" redesign is just not going to be supported by _any_ vendor who currently implements TACACS+. > - I don't understand how that RFC can have BCP14 language. I thought that was > reserved to > standards track IETF documents ? That's a question for the IETF process as a whole, not for this WG. There are many other Informational documents which use RFC 2119 language, including RFC 2866 for one. > - I am worried about the shepherd writeup: That's a question for the IETF process. The document has been published. It's a _little_ late to be asking many of these questions. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
