Subject: Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 May 2009 11:24:47 -0700

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.