While I consider much of this document thoughtful and useful, there are a number of assertions in Section 1 which concern me.
Section 1.2 of the document states that this document does not make a recommendation with respect to publication requirements: Any decision to make a Management Considerations section a mandatory publication requirement for IETF documents is the responsibility of the IESG, or specific area directors, or working groups, and this document avoids recommending any mandatory publication requirements. For a complex protocol, a completely separate draft on operations and management might be appropriate, or even a completely separate WG effort. However, at the same time Section 1 provides a potential justification for imposing such a requirement: Often when new protocols or protocol extensions are developed, not enough consideration is given to how the protocol will be deployed, operated and managed. Retrofitting operations and management mechanisms is often hard and architecturally unpleasant, and certain protocol design choices may make deployment, operations, and management particularly hard. Since the ease of operations and management may impact the success of IETF protocols, this document provides guidelines to help protocol designers and working groups consider the operations and management functionality needed by their new IETF protocol or protocol extension at an earlier phase. This paragraph caught my eye, since the case studies in RFC 5218 challenge some of our beliefs about what elements contribute to the success of a protocol. One of the takeaways from RFC 5218 is that the IETF may be setting the wrong bar for new protocol design efforts (too many requirements, but not necessarily the right ones), rather than focusing enough scrutiny on successful protocols undergoing revision. While we like to think that it is critical for new protocol designs to take issues such as security and O&M into account from the start, a look back at the evolution of some of the Internet's most successful protocols teaches us that it is more important that a new protocol solve an important problem and that it get enough of the basic design right (e.g. extensibility) to be able to add those critical capabilities later. If that is true, then it is important that this document differentiate between those O&M considerations that need to be thought through in an initial design, and those that need to be handled in a subsequent revision effort (where presumably the bar would be a lot higher). Given this, I would urge the authors to rethink much of Section 1, so as to carefully differentiate those issues that can cripple a new protocol versus those issues that are essential for global deployment of a successful protocol.
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
