Re: Protocol operations proposal deadline

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi,

Here is my two cents...most, if not all, of this has been said before:

(1) I like the idea of extended message processing capabilities
negotiation between communicating SNMP entities on a session by session
basis.  I would like to see a new message processing model with the same
base behavior as SNMPv3, and, with optionally modified behavior via
negotiation of supported extended processing capabilities.  I agree with
others stating that overloading the PDU with metadata should not occur.

Capabilities should apply to all varbinds within all messages within a
session until such time as the session closes, or, additional caps
negotiation occurs on the session.  I think capabilities that actually
simplify agent processing  (holes in tables come to mind) should receive
first priority of attention, and capabilities that are determined
useful, but not for every situation (PDU data compression comes to mind)
should at least be accounted for within any caps architecture.  There is
a need to accommodate a range of CR environments, from small cpu and
memory challenged embedded devices through larger sophisticated devices
that have dedicated hardware resources for encryption and payload
compression.  I don't believe the least capable environment should
determine the goodness of any proposed capability.  Rather, the least
capable environment would not support an extended processing capability
that is too resource intensive.

(2) There really needs to be better support for set operations involving
larger lists of objects.  I don't know if a larger message size for PDUs
within SNMP messages using the TCP transport will actually scale to a
sufficient number of varbinds for distributing configuration changes to
configuration rich devices.  Maybe there needs to be some way of
chaining multiple SNMP set messages- caching the list of messages as
they arrive at the CR and treating the (ordered and ?) concatenated list
of varbinds as a single operation.  There are of course issues with how
errors would be communicated, etc.  But this approach may prove simpler
for the CR than any other transaction scheme since the CR is currently
responsible for treating a single PDU as an atomic transaction.

(3) I like very much the fundamental suggestions in
draft-hardaker-eos-oops.  There are also some good additional
suggestions/refinements posted to this list.    By factoring out the OID
object-type prefix information, OID object instance information, the
objected oriented PDU (really an sming WG item) reduces the OID name
overhead and information redundancy within the PDU.  I would also like
to see additional filtering added to the new oops operations.  There are
two sorts of filtering to suggest here.  The first is a mechanism to
specify which components within an oo-object should be returned  (e.g.
which columns within a row).  The second sort of filtering would require
the CG to supply a secondary varbind list containing metadata (in a
proper placement within the oops message) to facilitate getting the next
object/row with a particular characteristic.  An example was posted wrt
to scli where the next ifEntry associated with an ethernet interface was
desired.  This mechanism might prove useful in reducing overall message
exchange between CG and CR.

(4) There needs to be some way that strongly encourages device vendors
to implement standard MIBs in a compliant manner.  There may have been a
thread (possibly on the sming list) about adding a section to MIBs
containing CG scripts that can be used to gauge compliance of a CR.
Short of establishing an independent industry lab responsible for
running conformance test suites on new devices, and publishing the
results as assigned agent-capabilities statements for the new device, I
am pessimistic about true multi-vendor interoperability for management
applications which rely upon standard MIB modules.   ( I guess this
thought may be off topic for this mail list...sorry).

Thank you to all contributors- I've enjoyed reading and following SNMP
related issues and hope to see, and participate in, additional progress
in evolving an increasingly useful SNMP standard.

Regards,

Mark Ellison
Ellison Software Consulting, Inc.

Glenn Waters wrote:

>
>
> As was discussed in Yokohama and published in the minutes, the cutoff
> date for new protocol operations drafts is September 15, 2002.
>
> The drafts that I have seen so far are:
>
>
> ttp://www.ietf.org/internet-drafts/draft-shield-eos-capabilities-00.txt
>
> http://www.ietf.org/internet-drafts/draft-hardaker-eos-oops-00.txt
>
> There has been a reasonable amount of comment and support of the
> Hardaker draft. The Shield draft is reasonably new -- please read and
> supply comments.
>
> Thanks, /gww