[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: EOS Row Operations (and other documents)
- To: Robert Story <firstname.lastname@example.org>
- Subject: Re: EOS Row Operations (and other documents)
- From: Lauren Heintz <email@example.com>
- Date: Fri, 30 Mar 2001 13:03:49 -0800
- CC: "EOS WG (E-mail)" <firstname.lastname@example.org>
- Delivery-date: Fri, 30 Mar 2001 13:10:51 -0800
- Envelope-to: email@example.com
Robert Story wrote:
> on page 14
> >Conveying Column Indicator
> > Can be implicit or explicit
> I'm not sure that I believe that it can be implicit. I'm assuming that the
> conversion between the compressed from and the expanded from will take
> place in the agent engine (otherwise sub-agents would have to handle the
> conversion, and that would mean changes to AgentX). Since a sub-agent could
> register to handle a table by specifying the table OID (or a higher level
> OID), the master agent can't expand the column OIDs.
I think column ID needs to be explicit. The OID names
of each varbind could be of the form 0.columnSubid (if
we re-use the existing SetRequest PDU structure).
I think this is needed because it gives agents the ability to validate
that the version of the MIB it implements actually corresponds to
the version the SNMP manager thinks is there. Some devices may
have an older version of a MIB than newer devices and thus support
different verions of the affected table (lesser or fewer columns,
or even the same number of columns but logically different ones and
with or without the same SYNTAX).
Regarding AgentX, I'm thinking the master agents needs to
be able to recognize that a SetRow has been recieved (so as
not to reject it because of errors that OID compression
might otherwise cause on traditional implementations), BUT
as you say, it cannot fully validate or expand the SetRow
because it doesn't know if the tableEntryOid actually
corresponds to a real table.
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. For one thing, even if the master agent does expand
the SetRow into a conventional Set PDU, then one of the stated
requirements for even considering SetRow (eases agent implementation)
isn't realized and the whole reason for inventing it has to
Depending on how SetRow is structured, the master agent may be
able to pass it down as separate varbinds within a single
AgentX-TestSet PDU. For example, the first VB can contain
the tableEntry and commonInstance data (name=tableEntry and the
value(OID)=0.commonInstance), and remaining VBs could be the
column variables actually being set (whose names are in 0.X format).
One problem I think I see using AgentX is that the AgentX subagent
needs to know that the SetRow PDU (inside the AgentX TestSet PDU)
is indeed a SetRow and not a conventional SET PDU. This means the
master agent needs to say to the subagent, "Hey, treat this as a
SetRow instead of a Set." I.e. don't raise an exception on these
strange varbinds that have the 0.X pattern (and so on), and instead
expand them into real OIDs. But AgentX protocol doesn't allow such
info to be conveyed to the subagents (unless you trick it somehow).
One possible solution is (?) to use the RESERVED field in the TestSet
PDU to have a SetRow operation indicator. Pre-existing AgentX impls
would ignore that field and would reject the SetRow with predictable
errors, while newly wired impls would know how to distinguish
SetRow PDUs from convention Sets. Another solution is to have the
first TestSet varbind refer to a special MIB scalar that all SetRow-
capable subagents pretend to implement (but don't register for) and the
SetRow semantics can be conveyed therein. Again, this would cause
predictable errors in legacy impls, as desired.
Sorry for the length of that!