[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: snmpconf Issue #18 resolution - Update capabilities table


This issue hasn't been appropriately aired, based upon what
I see in the mail archive.  I'm going to try to collect in a
single message where we are.  I hope those who will only read
mail that fits in a vt100 will forgive the length of this.

To summarize for those who won't read the whole thing:

  I believe the coarse granularity of capabilities information
  in the capabilities table is useful for short-circuiting
  downloads of useless policies.  Regardless of the
  implementation of that idea, I think it's a useful mechanism.
  I have not been convinced that this idea is fundamentally
  wrong or useless.

  As such, I continue to believe that the capability tables
  as proposed by Jon - perhaps with some adjustments - are
  fundamentally the right thing to do.

Now...  It seems reasonable to remind ourselves what the
capabilities table is for.  Based on what I believe was a
reasonable consensus in Minneapolis, the capabilities table
is to be a relatively high-level way of being able to say
what a box can do.  As I see it, the purpose is specifically
to short-circuit downloading meaningless policy scripts to a
policy engine that can't possibly implement it.  Why bother
sending a diffserv-based policy to a policy engine that has
no diffserv support?  Of course, you can go ahead and send it
if you want and it should result in exactly nothing happening
on the box.

Given that, why bother having the mechanism?  I believe there
is real value in short-circuiting the process so that policy
engines aren't wasting cycles on useless scripts, memory
doesn't get used storing them, plus it's _possible_ that bad
things could happen if you send inappropriate scripts to a
policy engine.

I say all this because I think it's important to understand
why it's there at all before going deeper into the way
it's implemented.  The raison d'Ítre for the table is quite
important, in my view.  I'm less attached to the implementation
of it.

Of course, you _could_ use existing MIB infrastructure to
determine capabilities, at least to some degree.  However,
the capabilities table gives you single place to look for
capabilities.  I suspect we are going to find that you might
need to do other complementary checks, but, frankly, we don't
know that yet.

Jon published, in
http://www.snmp.com/snmpconf/mailing-list/msg00732.html, a
suggested updated capabilities table that reflected a phone call
that he had with David Perkins (his take on that call, anyway).
That text is the basis of the discussion below.  By the way,
David Perkins's issues (at least some of them) are outlined
in http://www.snmp.com/snmpconf/mailing-list/msg00727.html

I then tried to close the issue and got a bit of response :-) 

David Perkins wrote, on Mon, 16 Apr 2001:
perkins> I haven't read Jon's update message after
perkins> speaking with him on the phone. The talk troubled me
perkins> greatly due to my perception of Jon's lack of knowledge
perkins> about MODULE-COMPLIANCEs and AGENT-CAPs.  I believe that
perkins> it is bad for the SNMP community to use MODULE-COMPLIANCEs
perkins> to specify capabilities.

If I understand correctly, your argument is that
MODULE-COMPLIANCEs are for implementors and AGENT-CAPs for
capabilities and it's an abomination to use MODULE-COMPLIANCEs
for capabilities.

Given the (very) limited support for AGENT-CAPs, what would you
suggest as being the right thing to stuff in pmCapabilitiesType?

perkins> Whatever small gain that would
perkins> help SNMPCONF, is offset by the damage that it can and I
perkins> believe will do the SNMP community.

Can you help me understand what damage you believe this is going
to cause?

perkins> Additionally, I have a major problem with trying to
perkins> use some sort of capabilities specification that an
perkins> agent provides to assist an unknown manager. I believe
perkins> that EVERY management application must have either a
perkins> separate program or a component within it to probe an
perkins> agent to determine if it has the capabilities that are
perkins> needed to support its requirements.

I completely agree.  What this table does, though, is give you a
reasonable first place to look.  We're creating the practice
of SNMP-based policy work here, and creating a central place to
say, "I can be configured using the diffserv MIB" or "I can be
configured using the IPsec policy MIB" seems a Good Thing.  To
say that we cannot do that today doesn't strike me as reason
enough not to try here.

perkins> Only the management
perkins> app knows its requirements. Only after a management app
perkins> is written and the requirements specified, can an agent
perkins> developer determine if it meets the requirements.  It is
perkins> "just silly" for an agent to advertise capabilities for
perkins> future and of course unknown management apps and HOPE that
perkins> the capabilities specification is complete and precise
perkins> enough to allow a management app to determine if it can
perkins> interoperate with an agent without probing the agent.
perkins> Once you need to probe an agent, when why bother with
perkins> checking for a capabilities specification.

I certainly wouldn't claim that that's what this table is
supposed to do.  This table has pretty coarse granularity, but I
believe that it provides enough utility to include it.  You
probably would disagree with that.

Joel Halpern responded to David Perkins:

halpern> In your description Dave, you state that the
halpern> management app should "probe the capabilities of the
halpern> individual device.  Given taht what we are trying
halpern> to do is provide a means my which a common set of
halpern> configuration can be defined by the administrator,
halpern> and applied across a number of devices, there is
halpern> no way that the application can "know" much about
halpern> what capabilities are required unless the language /
halpern> libraries / objects tell it so.  What we are trying
halpern> to define are the hooks that make it likely that the
halpern> policy will be applicable / useful.  We recognize that
halpern> you can not define fine enough grained capabilities
halpern> in a general fashion.  Instead we are trying to
halpern> provide coarse grained information that will help
halpern> the management system determine whether a given
halpern> configuration policy is likely to be useful to send
halpern> to a given system.

Funny how it took me paragraphs to say what Joel said in one :-)

perkins> I hope that we can agree that this is a potentially
perkins> difficult problem.

There's no question about that.  What I keep coming back to
in my thinking is that what SNMPCONF is busy creating is -
to some degree - uncharted territory.  We don't always know
what's going to be useful or not.  Often we can make intelligent
guesses, but we're unlikely to get it all right the first time.
My guess in this case is that the capabilities table is going
to be very useful.  We may discover that saying "I do diffserv"
is not nearly enough for this to be useful or that it solves
80% of the problem at very little cost.  That'd be a real win.

perkins> However, in the case that you
perkins> bring up, I believe that one has to run a classifier
perkins> program that probes the managed systems. Of course
perkins> if you have 100 systems, and 30% are brand X, 45%
perkins> are brand Y, and the remaining 25% are brand Z,
perkins> you don't need to do extensive probing of each of
perkins> the 100 systems for each new management app.

Perhaps the capabilities table would allow you to ask once at
each box...

perkins> I get a little worried about deploying a new
perkins> management app (or script) on 100 systems at the
perkins> same time on a live network that I have not tested
perkins> pretty extensively on a single system in a controlled
perkins> environment.

I don't think anyone's suggesting that we're going to remove
this requirement by some sort of SNMPCONF magic.  I completely
agree that this has to be done.

perkins> A capabilities mechanism that allows me to skip
perkins> testing, but will fail sometimes (because of
perkins> approximate completion and low precision in its
perkins> description of capabilities) doesn't seem like a
perkins> prudent addition.  I've still got to test in my world.

I don't for a second think this eliminates ANY kind of testing.

I think Jon's answer
addressed these points as well.

David Harrington, on 23 Apr 2001, wrote:

dbh> I am concerned that the resulting text is not what
dbh> was specified on the todo list.

I hope we won't get too wrapped around the axle on that
one.  I didn't put much effort into guarding myself on the
formulations in the to-do list...

dbh> The pmCapabilitiesType seems to have been greatly
dbh> expanded from what is mentioned in the todo list.

Frankly, I don't see it.  I think the tables do exactly what is
on the to-do item.

dbh> The purpose of the IETF is to provide standardized
dbh> solutions. The wide-open nature of this object seems
dbh> to work against standardization.  The ability to
dbh> define any OID without it being a module identity
dbh> or a compliance OID means that vendors can use
dbh> OIDs that are proprietary "codes" for their own
dbh> applications to recognize, promoting the use of
dbh> "hidden" capabilities. This does not work toward
dbh> interoperability and industry standardization.

This same argument can be used for _anything_ vendor-specific.
We specifically created a management framework which
allows for vendor extensions.  Essentially, we say, "Define
vendor extensions, but do them in a standards-compliant way
(SMIv2)."  Sure, allowing vendors to put their own OIDs into
pmCapabilitiesType means it's vendor-specific.  We clearly,
in my view, just have to live with it.

dbh> According to the todo list, the
dbh> pmCapabilitiesOverrideTable would contain two objects
dbh> - one which could be set to valid or invalid, and a
dbh> rowstatus object.  The text proposed has additional
dbh> functionality beyond a valid/invalid switch and
dbh> a rowstatus.

I didn't put everything in the to-do item.  It seems very clear
to me that if you're going to override or add a capability
using the management interface, you have to say what that
capability is.  That's what the additional object you point
out does.

dbh> I am particularly concerned about a manager being
dbh> allowed to override the agent by asserting that a
dbh> capability is present even though the agent says
dbh> it is not.  There is no way for a manager to better
dbh> understand the agent implementation than the agent
dbh> itself. This smacks of creeping featurism.

Perhaps an example might help...  Let's say that I have a device
that does diffserv, but I, as a manager, determine that I _never_
want to send any diffserv policies to it.  When the policy engine
boots, it'll automagically include a diffserv capability.  I
would use pmCapabilitiesOverrideType to say, "Don't download
diffserv policies".

Or, let's say that the manager _knows_ that the policy engine
in fact can do diffserv, despite the fact that the box doesn't
include the diffserv MIB - it might do it in a proprietary
MIB - and doesn't register a diffserv capability.  I can use
pmCapabilitiesOverrideType to say, "but you really do have
that capability".

dbh> I am concerned about the multiple manager problem
dbh> and the override table.

I agree with Jon here.  There's nothing new about this table in
this respect.  Managers have always been able to mess each other
up by scribbling on common memory.  If you don't want that, you
have to set up access control to prevent it.   Or perhaps I
missed your point.