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

RE: Open/Closed Issues on SNMP Extended Protocol MIB


Given that 'New' is only new once and utterly uninformative, could
new status codes have better names like 'notRowWritable' or
'notEosWritable', please?

Separately, even if SubAgent behavior was deemed out of scope for EOS,
I don't see how EOS is useful unless SubAgent behavior _is_ specified
and (my opinion) AgentX is compatibly extended.

The problem of discovering which subtree supports EOS is terrible
for NMS scripts to cope with.

- Ira McDonald, consulting architect at Sharp and Xerox
  High North Inc

-----Original Message-----
From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
Sent: Friday, June 29, 2001 1:14 PM
To: Lauren Heintz
Cc: Juergen Schoenwaelder; eos@ops.ietf.org
Subject: RE: Open/Closed Issues on SNMP Extended Protocol MIB


Well, first off, we had decided that subTree (subAgent) differences
in support for EOS features was out of scope.  Is there rough 
consensus that this should be a requirement?  It would be good to agree
on that before solving it.

Now, charging ahead to solve it before it is a requirement, the MIB table 
I sent out this morning provides a simple means to determine which
functionality a subtree supports above and beyond what the rest of 
the system supports. 

I had originally also said that the traditional set support could 
also be done that way, but now I don't think that is the 
correct approach. The notWritable/notNewWritable currently makes more 
sense to me.


-----Original Message-----
From: Lauren Heintz [mailto:lheintz@cisco.com]
Sent: Friday, June 29, 2001 1:06 PM
To: Chisholm, Sharon [CAR:5K32:EXCH]
Cc: Juergen Schoenwaelder; eos@ops.ietf.org
Subject: Re: Open/Closed Issues on SNMP Extended Protocol MIB

Sharon Chisholm wrote:
> notWritable - This object is not setable via traditional sets
> notNewWritable - This object is not setable via new sets

One of the issues I've been trying to figure out with the
current draft is how command responders behave when certain
ops are supported or not:

                 | MasterAgent |
                    |        |
                    |        |
              -----------   --------------
              | EosSub1 |   | NonEosSub2 |    
              -----------   --------------

- this scenario assumes worst-case that the
subagent protocol does not permit subagents
to declare to the MA they are EOS-capable.

- if the MA doesn't recognize any given PDU at all,
I had assumed it would simply handle it as
per the rules of the message processing model
in place.

- otherwise, say Sub1 accepts EOS requests
but Sub2 doesn't (instead it expects conventional
SNMP requests).  The MA dispatches an EOS
rowOp to Sub1 and ostensibly a response
or error is returned that the MA can dutifully
return.  However, when it dispatches a similar
EOS rowOp to Sub2, Sub2 treats it as a conventional
request and very probably a normal error (e.g. NoSuchObject
or other) is returned because the OID suppressions will
confuse sub2, and notNewWritable can't be returned by the MA
(cause it doesn't know that's the problem).

Thus, if we support these mixed-arch's (and I think we
would) NMSs have to figure out when to send (and when not to
send) EOS requests.  This is true even if the subagent
protocol allows subs to declare whether they are EOS
capable or not (though the MA could at least
in this case return notNewWritable errors and avoid
having to send a wasted EOS subop to Sub2).  Hopefully,
NMSs won't have to use trial-error to figure out which
MIB regions are EOS capable and which are not.

Not sure views are the asnwer because the views themselves
may not be viewable, and even if they are, the NMS would
have to first retrieve them (and would they use EOS requests
or not?).  Could new AGENT-CAPs statements help here?  Does
the extended protocol MIB have to address this issue of
MIb region granularity for EOS capability?

Thanks, Lauren