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

Re: draft-ietf-eos-snmp-rowops-00.txt



Let's be clear, Glenn, are you suggesting that groups
of scalars can be referenced using a rowId=groupOid and
separate operands (one for each scalar in that group)?

I believe Robert is instead suggesting that individual
scalar varbinds should also be able to co-exist in the PDUs.

I think we can support both, though in the case of SetRow
I'd prefer not to support individual scalar varbinds because
that may again complicate set method processing because some
of the high-level error checking that could be done in the
master agent might instead have to be done in the subagents
or maybe in every row method.  If in a SetRow you do need to
set scalars (e.g. TestAndIncrement), the rowOp style of
data packing can still be used (primarily an EditRow issue).

Also, I'm not sure why you suggest that by allowing
the ".1" part to be implicit, that scalar
support is thereby unsupportable???

To me, some entity has to be smart enough to know
when to add back the ".1" even if just conceptually.
To my way of thinking, that entity is a subagent.
The subagents seem smart enough to parse OIDs in varbinds
and classify the varbinds as either operands, as rowIds,
or as scalars and then invoke the proper method.

The master agents just have to be smart enough
to recognize the new request types, and shovel
them down (with rowIds and operands properly
bundled) to the appropriate subagent(s) with very
little transformation.  Hopefully, the subagent protocol
makes use of the OID suppression just as does SNMP.
If the master agent tries to get too smart (PDU translation)
then I think problems start developing (the draft talks
a bit about why request translation does not provide a
viable transition scheme).

If we do support individual scalar varbinds, I don't think
we need to add a count of them in the PDU or worry about
where they are located (as long as they aren't inserted into
the middle of a rowOp).  They are instead just treated
as rowIds (without operands) and transmitted to the entity
that knows how to distinguish them from true rowOps.
Of course, I haven't had a chance to work this all out
in detail though, so maybe I'm missing something.

Thanks, Lauren


Robert Story wrote:
> 
> At 9:45 AM -0400 5/2/01, Glenn Waters wrote:
> >I think that one reason you would NOT want to use tablePart instead of
> >tableEntry is that would preclude retrieving a scalar object. The
> >currently proposed encoding method would allow the retrieval of a scalar.
> >
> That's a good point. How about requiring that scalars appear first, and
> have the PDU contain a number of scalars (a-la get-bulk's non-repeaters).