I have read much of rfc5706bis, and Richard's complaint. I have some sympathy for whether or not it's within opsawg's mandate; however if the AD and the IESG say it's the place to do this, then it is.
I was around when RFC2223 and RFC3552 were created. I note how trivial the text in RFC2223 is (there will be a secton says Postel), but also note that RFC3552 was needed to clarify, and doing so was an IAB act. (With EKR a member, and acting, I think, as editor of the document). If this document came from the IAB, I wonder if people would feel differently. Toerless Eckert <[email protected]> wrote: > Sec: I do agree that security considerations are often? not as good as > they should be. Maybe SEC AD should more often ask "have co-authors > read rfc3552 and applied it to the security considerations section". > But i am also not sure if rfc3552 is the best it could be after now > being 22 years old. But i need some more time (independent of this > rfc5706bis effort) to have more well founded technical opinion about In some documents, Security Considerations is the first anyone thinks about security. That's a flaw. SC should review the threats, and point out the mitigations that are aleady in the protocol description. No BCP14 language belongs there, because it SHOULD already be elsewhere. Having said that, there are many protocols which are mere extensions of others, and there really is little more to be said. That's okay: the poit of the mandatory sections is to have people think about the topic. > Mandatory Ops/Mgmt section: I also don't think that a simple "all IETF > proocol specification MUST have an Ops/Mgmt section" to be the best > possible outcome of the WG process we are starting now. I think the > starting point really is "all IETF protocol specification MUST have > Ops/Mgmt documentation". I think that the document explains itself well enough when it says: Retrofitting operations and management mechanisms is often hard and architecturally **unpleasant** while I would not insist that a YANG model be created for every protocol, I think that the activity of thinking about what things need to go into that is important. And I think that the document goes to some length to say exactly that. (IPsec, for instance, has a "PAD", which I find obtuse to talk/reason about, as there aren't really any sensible primary keys) I think that it's acceptable for "Operations Considerations" to say nothing, and that option is very clearly included in section 3.2. > The fact that security sections turn out to be less good than they > could be in cases is, i think also a good reference for attempting to > improve on our Ops/Mgmt documentation: I find about half the Security Considerations sections to be inadequate, and of those I find many to be "harmless but useless" (a term I learned from Adrian). I got bored/lost-interest reading rfc5706bis around section 5. If I have any complaint, this document could probably be 1/3 in size. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
