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

RFC 1905 Section 4.2.5



I was told that the following enhancement might be incorporated into the
SNMP Row Operations Extensions RFC if appropriate. So here it goes:

Section 4.2.5 of RFC 1905 describes the processing of SetRequest-PDU.
Section 4.2.5 calls for a two phase approach to VAR_BIND processing:

<!--StartFragment-->
   The variable bindings are conceptually processed as a two phase
   operation.  In the first phase, each variable binding is validated;
   if all validations are successful, then each variable is altered in
   the second phase.  Of course, implementors are at liberty to
   implement either the first, or second, or both, of these conceptual
   phases as multiple implementation phases.  Indeed, such multiple
   implementation phases may be necessary in some cases to ensure
   consistency.
<!--EndFragment-->

The two phase approach is archaic in many ways.  As such, rethinking this
approach is in order and/or more specific language is needed.

Several agent development kits in the market have taken the approach that
processing of a VAR_BIND must be individually done.  This, of course,
presents problems with trying to maintain the consistency of multiple
variables.  In a 40 column table then 40 calls need to be made to validate
input.  If a table contains col1, col2, and col3, why should a consistency
check for col1 and col3 be done twice?  If there are underlying DB
resources for persistency then they need to be locked between 41 function
calls.

This approach ties too tightly the Business Logic (BL) associated with data
to the agent.  It should be possible for an agent to call a single function
and this function have the ability to set error-status and error-index as
needed.  One could say that phase 2 is the appropriate place for the single
call approach except the RFC contains vague language and only specifically
allows the following:

<!--StartFragment-->
   If any of these assignments fail (even after all the previous
   validations), then all other assignments are undone, and the
   Response-PDU is modified to have the value of its error-status field
   set to `commitFailed', and the value of its error-index field set to
   the index of the failed variable binding.
<!--EndFragment-->

Toolkit implementors have taken this to mean that the only response for a
failure of a phase 2 call is commitFailed.

Finally, error-status is too simplistic in the face of complex BL.  Giving
the user feedback for row creation problems is not possible via variables,
tables, columns, or traps without correlation problems.  In other words,
protocol support is needed.  As such, is it possible to have all new PDUs
be extended to include an errTxt (DisplayString)?  This could give the user
the ability to augment the explanation given in error-status.

For example, table t has col1, col2, and col3.  For t row creation col1
cannot be set to y when col3 is set to x.  With a violation of the previous
condition, an error-status inconsistentValue does not quite capture what
the problem is.  In other words, BL is customer dependent and as such the
customer should have protocol support to return an extended error message.

Sidney Antommarchi
VXi - Systems Engineering
972-301-1258