[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