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

Re: RowStatus versus RowState

Hi Sandra,

Sandra McLeod wrote:
> 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> considerations
> 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> experience?
> Lauren>
> Lauren> For example, I surmise that the current draft does not obsolete
> Lauren> existing
> 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?

The key word above was "surmise". :-) You can probably better answer
this question regarding the aggregate struct you have proposed.
Existing impls have libraries of util functions that are coded
around the current varbind struct.  Depending on how these libraries
are designed, I'm just wondering if adding a new varbind type
would expose some possible risk that SOME impls may have to recode
these library utilities???  For example, maybe (or maybe not) something
like the following would have to be recoded to support the new
aggregate type:

    size = SizeOfVarbind(varbind1);

The current draft uses existing structs, types, PDUs, etc, so it
seems to me most of the low-level utils work as-is.

> > > > 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.

It seems that EOS-capable networks will require a major
paradigm shift from current SNMP networks.  It is not going
to be a painless transition from old to new.  All I'm saying
is that existing devices and instrumentation can at least make use
of a subset of the EOS operations (as per current draft) by simply
replacing their master agents (but keeping old subagent protocols)
and/or proxy agents.  Tis just a baby step towards a full EOS network,
but possibly a valuable one for environments trying to migrate towards
full EOS compatibility???  Even if these existing impls choose
not to adopt all EOS rowOps, using GetRow, GetNextRow and EditRow
would make things a bit more efficient on-the-wire, and why would
anyone disregard such a benefit if all they had to do was install a
new master agent provided by their SNMP vendor?

Ideally we'd like to be able to translate ALL EOS operations within
a proxy agent or a master agent so that old instrumentation never has
to change even while new instrumentation can take full benefit of
EOS features.  However, I don't think that's easily done (if we define
create/delete/GetBulkRow proto-ops).

Thanks, Lauren
>                         Sincerely,
>                         Sandra McLeod