[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RowStatus versus RowState
I've responded inline to a couple of the issues discussed by Mike and
Lauren in regards to the requirements list. To save space I've only
included those issues that I have responded to :
> > > 5. If a tradeoff must be made, then efficiency on the wire
> > > may involve a more complex message processing subsystem and
> > > dispatcher within the SNMP engine [RFC2571], while
> > > allowing for (but not mandating) simplified method routine code
> > > with respect to set processing.
> Mike> I can't even make sense of this one.
Lauren> I *think* this means increasing complexity of certain
Lauren> NMS/agent subsystems may be OK if it results in more efficient
Lauren> on-wire PDUs.
I think the idea here is also that the modifications may be
acceptable if they allow for simplified set processing down at the method
routine level. For example, a createRow operation may result in an entire
row being passed down to the method routines to take full advantage of
this new feature. One of the things that the new RowOps were intended to
address was the difficulty in creating rows in parts and pieces. The
createRow operation would be more efficient and would make it easier to
create an entire row of values at once. So, to really take advantage of
this, you could carry the entire row down into your method routine code if
you are willing to make changes to the SNMP engine's dispatcher.
> > > 6. Information in SET requests containing row operation data
> > > should have a well defined (lexicographical) ordering within MIB
> > > groups. That is to say, in table row SETs, the atomic objects
> > > MUST be lexicographically ordered. (This requirement is
> > > designed to simplify SET processing on complicated requests with
> > > interrelated objects).
> Mike> Change MUST to MAY. Specifically, OID suppression by
> Mike> relative index
> Mike> specification will not have its efficiency impacted by
> Mike> this requirement, and
> Mike> so this would become a restriction with no benefit in that
> Mike> case.
I'm not sure I understand what you are saying here. Regardless of whether
you use OID suppression with explicit or implicit column identification,
the idea of ordering is that it simplifies the processing of SET requests
with objects that have interdependencies that must be enforced. If you
can assume ordering, this allows you to also make some assumptions
about what may be contained in the rest of the VarBind list as you are
processing each VarBind.
Lauren> One big question is do we use existing PDUs and data structures
Lauren> to their best effect, or do we define new ones? What
Lauren> compell us to define new ones (i.e. efficiency? elegance?). Is
Lauren> it worth the pain to define new ones, and what pains would we
Lauren> For example, I surmise that the current draft does not obsolete
Lauren> utility functions, though adding a new varbind aggregate type
Lauren> might do that. It's unclear whether new aggregate structures or
Lauren> PDUs result in more efficent PDUs than the current draft.
What sort of "utility functions" are you concerned about in regards
to using an aggregate row type object? Would these utilities not also
be affected by the use of the createRow and deleteRow PDUs?
> > > 18a. New AgentX PDU-types MUST NOT be needed
> > > to support RowOps, though existing ones MAY
> > > be tweaked.
> > >
> > > 18b To take full advantage of the new simplified row operations
> > > made possible by this work, additional master agent/subagent
> > > communication PDUs MAY be required.
> Mike> No tweaking. AgentX is moving for standardization, and
> Mike> if we can
> Mike> meet #3, then no tweaking is needed.
Lauren> Current draft would break current AgentX if an impl were required
Lauren> to implement CreateRow, DeleteRow or GetBulkRow (but maybe not
Lauren> EditRow, GetRow, GetNextRow).
If we want to implement the really useful features of the RowOps draft
like CreateRow, DeleteRow, and GetBulkRow, then AgentX is going to
be broken. But, how much would having just an EditRow, GetRow, or
GetNextRow operation really buy us if this doesn't get translated
down to the method routines so that we can save compatibility with AgentX?
The increased efficiency on the wire seems like the only real gain that
we would achieve from these operations. But, I didn't think that was the
only intention, nor even the main goal, for the RowOps draft.