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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf