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

Re: Protocol operations proposal deadline

> 2) Complexity of feature negotiation
>    I think this draft goes overboard in complexity. 
>    The ability to specify which features are requested for which
>    varbinds is very complicated

OK - firstly, I think it'd be perfectly valid for an agent to advertise
support for an "all-or-nothing" implementation - perhaps via an AGENT
CAPABILITIES definition (why is everybody laughing at me?) or some
other mechanism.
  So if the agent didn't want to deal with the complexity of per-varbind
capabilities (and was geared up to deal with a particular feature across
the board), then it'd be at perfect liberty to do so.

>                    The capabilities should apply to the entire PDU,
>    not individual varbinds.

That's certainly an ideal, but I'm not convinced it's realistic.
At the very least, I think it's vital to be able to _advertise_ support
for particular features on individual portions of the overall MIB tree.

Taking a concrete example - the "filled-holes" feature (which would be
needed for Wes' object-based proposal, even if it wasn't supported as
a separate capability).

   I'm most familiar with the code of the Net-SNMP agent, and the new
agent architecture that Wes developed makes implementing this feature
very straightforward - simply a couple of lines of code.  But that's
only with MIB implementation modules that use these new mechanisms.
Anything implemented using the old APIs (which are still supported)
couldn't fill in such holes without quite a lot of fiddling.  And that
includes most of the modules currently in the agent (since we haven't
really started migrating them across).

  So with an all-or-nothing model of advertising capabilities, we'd
have a choice between claiming to support the new feature (and praying
not to have to prove it for the older modules!), or denying such support
(even though we might be able to handle it).  At least with a finer
granularity of advertised support, the management application can
attempt to make the most of the agent.

  When it comes to requesting the use of such features, it's perhaps
less important to have this level of flexibility.  The management
application could always split a request into two - one using a
particular feature, and one without - then merge the two sets of
results afterwards.  But this seems a bit over-complicated - if the
agent is prepared to support a more granular form of request, then
I think this could be useful.

  I've often had discussions with Wes regarding the design of various
aspects of the Net-SNMP suite, and I've tended to argue in favour of
greater flexibility - trying to give the application programmer the
option to use the suite in ways we haven't necessarily thought of.
I'm really taking a similar line here.  If an individual implementation
wants to take a relatively simple approach, then that's fine - but
(ideally at least) it shouldn't prevent another implementation following
a somewhat richer (and possibly more complicated) line.

Maybe that's an inappropriate stance in the case of network protocol
design - I don't know.  But I think it's worth considering.