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

Re: Open/Closed Issues on SNMP Extended Protocol MIB


"McDonald, Ira" wrote:
> Hi,
> Given that 'New' is only new once and utterly uninformative, could
> new status codes have better names like 'notRowWritable' or
> 'notEosWritable', please?

I like notSupported, since we have to also return
errors in case of GetBulkRow, and a "notWhateverWritable"
sounds wrong for that case.

> 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.

I agree, though I assume the rowOp doc is not
the place to specify this (other than to point
out something has to be done).
> The problem of discovering which subtree supports EOS is terrible
> for NMS scripts to cope with.

I agree.  And I think I can think of a general way of
avoiding this problem (if the NMSs follow some rules):

1) GetRow, GetNextRow and EditRow can always be translated
into conventional subops by EOS-capable master agents (MA)
that also support both EOS-capable and EOS-noncapable subs.
These MAs would ostensibly not translate **any** EOS request
if targetted to a EOS-capable sub (assuming AgentX has been
updated to support EOS).

2) CreateRow and DeleteRow can also be translated **if**
the rowOp contains a ref (operand) to either RowStatus
or RowState, as appropriate.  Presumably, CreateRow
requests most typically will contain one or more operands
anyway (unless you can create the row using all DEFVALs).
If a Create/DeleteRow RowOp without operands is received for
an EOS-noncapable sub, the request cannot be translated by the
MA and an error would have to be returned. EOS subs can handle
such requests without problem.

FYI: Actually, in this case, it would be more efficient to
convert a RowOp with only one operand into a Singleton
(see the draft).  And I don't think one Singleton is less
efficient than one Create/DeletRow RowOp without an operand.

3) GetBulkRow, as defined in the draft, cannot (I think)
be translated into conventional subops.  We could always
redefine it so that it is translatable (back toward its
current incarnation), but then the head/tail capability
(and the termination condition) is lost.  The request
and response would both still be more efficient though.

Thanks, Lauren

P.S. If someone has a better name than "Singleton"
(see the draft) please advise! :-)

> Cheers,
> - 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
> hi
> 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.
> Sharon
> -----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