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

Re: EOS WG Status

> Does anyone want to step up to the plate with any comments on the future
> direction of the EOS WG?

I'm sorry I never got around to responding to the earlier message, and I'm
not able to join you in Minneapolis.  But I'd like to offer a couple of
questions, and an observation.

   Is the EOS work expected and/or permitted to extend the syntax of a PDU?
   I.e. are we free to introduce new types (analogous to Counter64 in the
   v1->v2 transition), or is this work concentrating on simply extending the
   semantics of the current basic structure (analogous to GetBulk in v1->v2)

   Is EOS concerned with defining new protocol _operations_, or new protocol
   _capabilities_ ?  Such capabilities might include new operations, but is
   conceptually somewhat wider.
      For example, if the group defined a new feature (say 'priority'), and
   the agent had indicated to the manager what it supported this feature,
   could the manager apply that new feature to existing protocol operations
   ('snmpget -pri=high sysUpTime.0') or would this require the use of a new
   operation ('snmppriget -pri=high sysUpTime.0') ?

   A number of the features under discussion feel to be less strongly related
   than they are often regarded.  For example, DP's "GetCols" suggestion
   includes both a new protocol operation, and a method for OID compression.
      While these obviously complement each other quite neatly, they are
   actually separate concepts (IMO).  It would be quite possible to implement
   the new operation using the existing OID representation, or vice versa.
   Such an implementation wouldn't yield the same benefits as supporting both,
   of course, but even in isolation, either of these would be a step forward
   from the existing behaviour.
      I wonder whether it might be helpful to try and consider the various
   features independently (as far as possible), rather than bundling them