> -----Original Message----- > From: Alan DeKok [mailto:[email protected]] > Sent: Friday, May 19, 2017 1:40 AM > To: t.petch > Cc: Tianran Zhou; Ignas Bagdonas; IETF OOPSAWG; > [email protected]; [email protected] > Subject: Re: [OPSAWG] draft-ietf-opsawg-tacacs-06 Contributions, Status > and Plans > > 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. > > They may ask for some sections to be removed (i.e. servers pushing keys > to clients). But everything else is pretty much fine. >
Good to know this information. Thanks. > The idea is that having a documented protocol, with warnings and caveats, > is much better than an undocumented one. > Yes. It's what we got from the previous WG consensus. Tianran > Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
