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

Re: Direction of Row Operations


After further thought, I'm not quite so sure
that 1.b (below) is the correct choice.  It sort of
depends on how other things shake out.

For example, if we decide that, for the
sake of easing transition to an EOS network,
some implementations might in the short term
support only EditRow and the GetRow requests
(but not CreateRow and DeleteRow), then the
correct approach might be 1.c (one bit for each

Such an approach would allow many (if not most)
implementations to use simple PDU translation schemes
to translate EditRow and GetRow requests to traditional
SNMP requests (or subagent ops).  Then later, as they
evolve to allow configuration of MIBs via SNMP (CreateRow
and DeleteRow), those requests (which cannot be directly
translated) could be supported as well.  This approach would
need one bit per request.

Thanks, Lauren

Lauren Heintz wrote:
> Hi Sharon,
> It was my impression there is consensus to
> add a getBulkRow type of rowOp, as well as
> support the capability for rowOps to concurrently
> retrieve scalars and other random reads.
> Of course, we have not been able to gauge
> consensus on whether the overall approach
> in the rowOps draft is the correct way to go,
> or even if the name "rowOps" is appropriate.
> Time will tell!
> But assuming for the moment the draft is on track,
> I second your idea of 1.b.
> Thanks, Lauren
> Sharon Chisholm wrote:
> >
> > hi
> >
> > The Row Operations draft proposes 5 new row operations
> >         1) Create Row
> >         2) Modify Row
> >         3) Delete Row
> >         4) Get Row
> >         5) Get Next Row
> > which are, in theory, bits-on-the-wire efficient as well as
> > simpler to implement than using traditional operations to
> > perform row operations.
> >
> > I have two questions related to the direction we want to go
> > with all this.
> >
> > 1) When defining the bits for the IANASnmpExtendedProtocol
> >    object, did we want
> >         a) One bit for all row operations
> >         b) one bit for get row operations and one for set row operations
> >         c) one bit for each of the five operations
> >
> >    My preference is b)
> >
> > 2) Did we want to keep these as row operations, or try and build something
> >    which maintains the two goals I mentioned above, but can also be used
> >    for non-row related operations? As in something which can simply and
> >    efficiently be used for both row-oriented and scalar-oriented operations.
> >
> >    I don't necessarily have a preference either way, but it's a question
> > that
> >    we should answer so that we can either define scalar support out of scope
> >    or rename these operations to createStuff, modifyStuff, etc.
> >
> > Sharon Chisholm
> > Preside Management
> > Nortel Networks
> > Ottawa, Ontario