----- Original Message ----- From: "Alan DeKok" <[email protected]> Sent: Thursday, May 18, 2017 6:40 PM
On May 18, 2017, at 12:57 PM, t.petch <[email protected]> wrote: of thought. > > This I-D, as Alan has commented and Doug acknowledges, has several > places where the description of security is more 1997 than 2017. If we > turn such parts into a clear, concise specification, we may then find > that we have wasted our time since the Security Directorate then says > that no > way can that appear in an RFC, even an Informational one. They've approved RADIUS RFCs... by holding their nose. > Would it be worth seeking guidance now on what is or is not likely to be > acceptable to a Security Directorate review? Not a line by line > analysis but rather > higher level guidance as to whether such things as MD4, ASCII login, > RFC2433 as Best Practice and so on can appear. I've been on the Security Directorate for a while now. While I don't claim to speak for everyone, I think the current approach in the draft will be fine. <tp> Ah, I did not know that. Scrub my suggestion (while I hold my nose:-) Tom Petch p.s. I notice that one of the addressees is now OOPS A WG; mmm, yes. They may ask for some sections to be removed (i.e. servers pushing keys to clients). But everything else is pretty much fine. The idea is that having a documented protocol, with warnings and caveats, is much better than an undocumented one. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
