[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Protocol operations proposal deadline
At 05:56 PM 9/4/2002 +0200, Wijnen, Bert (Bert) wrote:
>Mmm... I thought Sharon also recently published a new rev (03) of her
>SNMP Extended Protocol MIB.
>>From: Glenn Waters [mailto:email@example.com]
>>Sent: woensdag 4 september 2002 17:14
>>Subject: Protocol operations proposal deadline
>>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:
>>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.
I have read the SNMP Extended Capability Negotiation draft, and I have some
1) new protocol version vs. retrofitted features
I think this draft provides a good framework for retrofitting
existing versions of SNMP with new protocol features, but I don't
think we should attempt to do this. If one decides to retrofit,
then the only choice is to overload the varbind list somehow.
That's what this draft (and other retrofit proposals I've seen)
does. I don't think this approach simplifies code design. On
the contrary, it creates new coupling between the message processing
module and the command responder application that doesn't exist
in current implementations. It does this in a kludgey way,
that may cause implementations more work than simply adding
a new message wrapper that supports new features efficiently
(i.e. not by overloading the varbind list).
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 and could get even worse when you
consider all the possible permutations and corner cases an agent
needs to check. The capabilities should apply to the entire PDU,
not individual varbinds. (If we had session-based SNMP-over-TCP,
then the capabilities should apply to the entire session.)
3) Specification of extended capabilities:
The draft list some extended features in a TC:
ExtendedCapabilities ::= TEXTUAL-CONVENTION
"Provisional list of extended SNMP capabilities."
These features are not defined or even described anywhere in the
draft. I think it's a feature of the proposal that the feature
negotiation is independent of the actual feature extensions, but
they illustrate an important point -- it's very likely that these
features cannot be cleanly retrofitted to existing SNMP versions
because they will require that rules for the contents of the
Response PDU will be violated for some protocol operations.
In summary, I think we should leave existing versions of the SNMP
PDU alone, and add new features to a new message structure in the
cleanest manner possible.