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

Re: EOS Row Operations (and other documents)



Robert Story wrote:
> >Seems to me it has to pass the SetRow down to whatever subagent(s)
> >has registered the affected OID and the subagent has to expand
> >the SetRow.
> >
> I disagree. This would mean changes to AgentX, and I don't want to open
> that can of worms.

It all depends on what SetRow is, or isn't....

- If SetRow is one PDU and only has creation
OR modification semantics, then AgentX supports
this as is and you can easily perform internal
translations to ease transitions.  DOWNSIDE is
you have to continue using RowStatus-like objects
in future MIBs so you can create and delete rows
and do so safely in multi-mgr scenarios.

- If SetRow is multiple PDUs (CreateRow, DeleteRow,
etc), then AgentX doesn't support this as is and
internal translation to an old SET format is not
always possible.  UPSIDE is you don't need
RowStatus-like objects in future MIBs.

- If SetRow is one PDU carrying multiple operators
(i.e. create, delete, modify, replace), then AgentX
does not support this as is and internal translation
to an old SET is not always possible.  UPSIDE is you
no longer need RowStatus-like objects in future MIBs AND
you can wrap this in existing SetRequest structure (put
the operator in the unused error-index field).

- (other?)

I like the last choice (before other) because, as long
as we're wrapping the PDU in the old SET, why not wrap it
in the old AgentX TestSet as well (i.e. stuff an
operator in the RESERVED field).  Thusly, we achieve
full row mgmt at the protocol level and get rid of
the need for RowStatus (and don't force re-spins
of either rfc1905 or AgentX???).  Also, step-wise evolution
of legacy systems (by simple PDU translation) is possible
on a subagent by subagent basis, which may not be any more
difficult for a vendor than upgrading the master agent
(same change in a common code library?)

Lauren