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
