Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
Sam, Thanks for posting your review. It caused me to have a look at the document, because I've been considering writing something of a missive on my own. I have to say that I enjoyed reading this draft up to about Section 3, and then I came to some problems. I'll spell those out in a separate message, but I agree with you on one key point: this document does not does not provide actionable guidance, and actually avoids the use of 2119 language. Clearly that was a design goal. But I think in the end it has led to a good INFORMATIONAL document, or even the beginnings of a good text book, and not necessarily a BCP. Also, I agree with you that interoperability is not the first and primary goal. Clearly, and I hope Dave and others will agree, the primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one has understood the network impact (or total cost, if you will) for that service. And Section 2 provides a really nice illustration of that, with regard to what happened at Berkeley. I have another problem with 3.2: I think the SMI and other registry-based forms of structured data may be overrated in some cases. Sometimes what is being managed is very simple data, through a central service. One has to question who the consumer of the data is prior to determining how one encodes that data, or even what data is truly necessary. Consider the case of an application that is simply calling home to determine if there are patches. How much structured data does that service need? In this context, 3.2 is often irrelevant to the application running on some host, but it may be very relevant to the central system that is doing the updating. What I would suggest is that some additional context is necessary throughout the document to indicate really who we are talking to. Are we limiting our role to router management? What happened to the toaster with an SNMP stack? Would we use SNMP today for that toaster? Who would manage it? Well, let's put it in a more serious context and swap toaster for major appliance like air conditioner or refrigerator or PDU. Ok, and again. Thanks Dave and others for writing the doc. Eliot On 6/3/09 9:22 PM, Sam Hartman wrote: I was assigned this document as a secdir review. I'm not sure I have any comments in that capacity. However, I do have significant comments on the last call of this document. I appreciate the work that has gone into this document. People have worked hard to find examples, cases and even pithy sayings/architectural principles from many areas of the IETF. The document tries to be broad and to look at a lot of options. I think that it would be reasonable to publish this document as the current thinking of the ops WG or ops area. It may even be reasonable to use something like this as guidelines for network/routing/sub-network layer protocols to think about management and operations. However this document is not suitable for publication as a BCP because: * It does not reflect practices across significant areas of the IETF * It does not provide clear, actionable guidelines * It is not sufficiently clear to be understood outside the OM area. My background. I have never formally been involved in the OM area. However, I have studied SNMP as a participant and AD for the ISMS Wg. I have studied syslog as a user, operator, and as the AD who sponsored many of syslog's base documents. I have studied netconf as an AD who reviewed the spec. I've worked as a small enterprise operator. I'm a chair of a WG (LISP) that needs to consider operations and management issues. I believe that I should be able to read and understand this document; I believe that I'm well within its target audience. I got as far as the bottom of page 18 before giving up. Here are details on my concerns based on what part of the document I've read. I'm happy to invest significant time to get other reviewers to evaluate whether I have valid concerns; if I get others to read the document and consider whether I have a point, then I've done what I set out to do. 1) It does not reflect practices across significant areas of the IETF This is a concern that the document does not have broad enough consensus to be a BCP. I believe that significant areas of the IETF do not view management interoperability as a goal--much less a guiding principle of management. I've been involved in discussions in the Kerberos working group where we explicitly discussed this and came to the conclusion that management interoperability was not something anyone in the room was going to work on. We did work on an information model which covers aspects where people believed some degree of management interoperability would be desirable. It does not cover monitoring, faults, or the like--only provisioning of the database. Similarly, I'm quite certain that most web server vendors, ATOM
Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
At 12:22 03-06-2009, Sam Hartman wrote: I appreciate the work that has gone into this document. People have worked hard to find examples, cases and even pithy sayings/architectural principles from many areas of the IETF. The document tries to be broad and to look at a lot of options. I think that it would be reasonable to publish this document as the current thinking of the ops WG or ops area. It may even be reasonable to use something like this as guidelines for network/routing/sub-network layer protocols to think about management and operations. However this document is not suitable for publication as a BCP because: The document is a good piece of work. The considerations discussed in it may help other areas understand the thinking of the ops area as management and operations considerations are often overlooked. Bernard Aboba posted some interesting comments on Section 1 of this draft for the Last Call. I don't think that the document scales well from an IETF perspective as a BCP. As such, I do not support its publication as a BCP. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
Hi - From: Eliot Lear l...@cisco.com To: Sam Hartman hartmans-i...@mit.edu Cc: ops...@ietf.org; ietf@ietf.org Sent: Wednesday, June 03, 2009 11:15 PM Subject: Re: [OPSAWG] Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP ... Also, I agree with you that interoperability is not the first and primary goal. Clearly, and I hope Dave and others will agree, the primary goal is the ability to roll out new useful functions and services in a way in which they can be managed in a scalable manner, where one has understood the network impact (or total cost, if you will) for that service. And Section 2 provides a really nice illustration of that, with regard to what happened at Berkeley. Unfortunately, I think the IETF has only adopted the first sentence of this paragraph. The hard work (and it is hard work) to build interoperable *management* seems to have largely been abandoned in the IETF. I think the state of the netconf work attests to the shift to just shoveling around vendor-specific blobs, rather than management information. I have another problem with 3.2: I think the SMI and other registry-based forms of structured data may be overrated in some cases. They're not a panacea. The SMI has weaknesses that can make models cumbersome. I haven't seen a data representation or way of representing data semantics that was ideal for all purposes, and I doubt I ever will. Unfortunately, this recognition that nothing is perfect seems to have led the IETF dangerously close to anything goes. One would hope that this document would help WGs avoid the worst excesses. Sometimes what is being managed is very simple data, through a central service. One has to question who the consumer of the data is prior to determining how one encodes that data, or even what data is truly necessary. Consider the case of an application that is simply calling home to determine if there are patches. How much structured data does that service need? If there will ever be more than one patch, if there are dependencies between patches, if there is every the need to revert, if there are hardware or model dependencies It's really easy to over-simplify, and end up needing a whole bundle of band-aids as the system's needs evolve (or are recognized). ... What I would suggest is that some additional context is necessary throughout the document to indicate really who we are talking to. Are we limiting our role to router management? What happened to the toaster with an SNMP stack? Would we use SNMP today for that toaster? Who would manage it? Well, let's put it in a more serious context and swap toaster for major appliance like air conditioner or refrigerator or PDU. The IETF management discussions have increasingly limited themselves to what it takes to manage a few types of network gear. It seems to me that the IETF abandoned any hope of doing system management, or even management of multi-vendor systems, a long time ago. This may be a bug, this may be a feature. The thrust of this document seems to me to be a recognition of this state of affairs, and that consequently, if we're going to let a thousand vendor- or application-specific flowers bloom, a little advice to help avoid some of the mistakes of the past would be helpful. Consequently, I think having this document is a good thing. The advice it gives reflects the current fragmented state of affairs with respect to management information, and would be useful to folks trying to do a good job in this environment. I can support this as an informational document. I could somewhat reluctantly go along with making it BCP - our experience with that catch-all designation makes it clear that Best only means what we could more-or-less agree on and Current can mean we really hope something better will come along, but aren't going to hold our breath. Randy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
I was assigned this document as a secdir review. I'm not sure I have any comments in that capacity. However, I do have significant comments on the last call of this document. I appreciate the work that has gone into this document. People have worked hard to find examples, cases and even pithy sayings/architectural principles from many areas of the IETF. The document tries to be broad and to look at a lot of options. I think that it would be reasonable to publish this document as the current thinking of the ops WG or ops area. It may even be reasonable to use something like this as guidelines for network/routing/sub-network layer protocols to think about management and operations. However this document is not suitable for publication as a BCP because: * It does not reflect practices across significant areas of the IETF * It does not provide clear, actionable guidelines * It is not sufficiently clear to be understood outside the OM area. My background. I have never formally been involved in the OM area. However, I have studied SNMP as a participant and AD for the ISMS Wg. I have studied syslog as a user, operator, and as the AD who sponsored many of syslog's base documents. I have studied netconf as an AD who reviewed the spec. I've worked as a small enterprise operator. I'm a chair of a WG (LISP) that needs to consider operations and management issues. I believe that I should be able to read and understand this document; I believe that I'm well within its target audience. I got as far as the bottom of page 18 before giving up. Here are details on my concerns based on what part of the document I've read. I'm happy to invest significant time to get other reviewers to evaluate whether I have valid concerns; if I get others to read the document and consider whether I have a point, then I've done what I set out to do. 1) It does not reflect practices across significant areas of the IETF This is a concern that the document does not have broad enough consensus to be a BCP. I believe that significant areas of the IETF do not view management interoperability as a goal--much less a guiding principle of management. I've been involved in discussions in the Kerberos working group where we explicitly discussed this and came to the conclusion that management interoperability was not something anyone in the room was going to work on. We did work on an information model which covers aspects where people believed some degree of management interoperability would be desirable. It does not cover monitoring, faults, or the like--only provisioning of the database. Similarly, I'm quite certain that most web server vendors, ATOM implementors, etc do not want management interoperability. I understand that ISP operators very much do want management interoperability. I think that we have a significant conflict here and I think that we cannot approve such a BCP without addressing that conflict. One possible resolution would be to find an subsection of the IETF that actually agrees with these guidelines and scoping the BCP. Similarly, it has been my experience that the desire to standardize information model semantics is not universal across the IETF. My recommendation for determining if I have a valid concern here is to get one or two WG chairs from each area to read this document and comment explicitly on whether the approach to management and managability outlined in this document is consistent with practice in their area and WG. Far too much of the text was specific to management of network elements such as routers, switches and the like. The apps and security area use LDAP for a lot of things that I think would count as management in this spec. I don't know how to separate control plane and data plane issues on my web server. Enough of the text seemed specific to network management instead of service/application management that I would find applying this document in such a context more frustrating than helpful. This specific sub-concern could be entirely addressed by properly scoping the applicability of the document. 2) It does not provide clear, actionable guidelines I was looking at this document and trying to figure out what it would mean for my WG if this document was approved. As best I can tell it would simply add justifications for discusses that would be hard to debate fairly. Do I have to write up an information model for my protocol? If the ops AD says I do, what grounds do we use to determine whether that's reasonable? The answer may be yes and you don't get to disagree, but I can't tell from the document. If it's going to be a BCP, that needs to be clear to me as a WG chair. For what it's worth, I don't think we have the necessary consensus to require people to write up information models and would not be part of such a consensus at this time. If this is a list of things I might want to consider then why is it a BCP? If we want to come up with a set of things that need
Re: Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
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 OM 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 OM 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
Last Call: draft-ietf-opsawg-operations-and-management (Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions) to BCP
The IESG has received a request from the Operations and Management Area Working Group WG (opsawg) to consider the following document: - 'Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions ' draft-ietf-opsawg-operations-and-management-07.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-06-02. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-management-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16452rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
