Hi -
From: "Eliot Lear" <lear(_at_)cisco(_dot_)com>
To: "Sam Hartman" <hartmans-ietf(_at_)mit(_dot_)edu>
Cc: <opsawg(_at_)ietf(_dot_)org>; <ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf