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

Re: Protocol operations proposal deadline

At 10:21 PM 9/6/2002 +0100, Dave Shield wrote:
>> 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.

I think there are ways to allow for the requests to be for the
whole PDU, but the response to indicate that some varbinds did
not comply with all requests.  The agent should not have to deal
with reconciling a potentially long list of conflicting option
requests on a per varbind basis.  It's not that useful to
request OID compression method A for varbind 1,3,5 and OID
compression method B for varbind 2,4,6, and dontWrapColumns
for varbind 1 and 7, etc. This also assumes that the NMS wants
to micro-manage these requests.  I think the NMS developers
want simple features that they can count on being implemented
the same in every agent.

>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.