Re: Methods in SMIng?

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Today, yes today, methods are being implemented in SNMP. However,
you have to be a "MIB investigator" to discover them in SNMP MIBs.
If you are "normal engineer", you probably will miss them unless
the MIB module designer does a good job of pointing them out.
There are MIB design patterns that can be easily followed to
implement any method. Of course, as Juergen points out, it
is sort of messy. You have constraints due to the SNMP protocol,
such as a small max message size, limited flow control, and
no builtin retries.

Unfortunately, I've seen poor MIB designs to implement methods.
For example, they might only work if a manager has a long timeout,
or if only one manager tries the method (that is, they don't
cope with concurrent invocations).

So, I would rather see a high level specification of a method,
and then "generate" object definitions in SMIv2 format than
try to discover method definitions in SMIv2 format.

Difficult choices.
/david t. perkins

At 04:22 PM 3/5/2001 +0100, Juergen Schoenwaelder wrote:

>>>>>> Jerome Duprez writes:
>
>Jerome>     I am new to IETF procedures, and acknowledge there are
>Jerome> timing issues between the various draft documents, but I'd
>Jerome> like to get more information, even informal, on this subject :
>Jerome> - What is the current status about methods definition?
>
>There is an ongoing debate on the requirements, methods are one part
>of it. So you need to follow or participate in the requirements
>discussion if you have an opinion.
>
>Jerome> - Which are the arguments against them?
>
>I can give you my favourite - but there might be others: Both, COPS-PR
>and SNMP do not support method invocations in the protocol. So if we
>add methods to SMIng, then we have three options (I can think of):
>
>1 You can define them, but they just do not work with COPS-PR or SNMP.
>2 We emulate method invocation on top of what the protocol provides
>  us. In other words, we define some interesting SNMP/COPS-PR tables
>  to emulate method invocations with set/install/remove operations.
>3 We convince the protocol folks to support method invocations in SNMP
>  and COPS-PR.
>
>For me, option 1 is a bit stupid because allowing people to define
>methods without being able to invoke then seems like a waste of time.
>Option 2 is what I consider a truely ugly hack rather than a solution
>of the problem. Option 3 is IMHO technically the only way to do
>methods, but I doubt that the protocol folks are willing to go
>there. So there is a dilemma. And given this dilemma, I prefer to stay
>away from methods at this point in time (but make the language
>extensible so they might be added later).
>
>Jerome> - In case a majority of the WG still desires to specify
>Jerome> methods, is there some proposed syntax, and examples of method
>Jerome> signatures?
>
>Not yet since we first need to find out whether we are going into this
>direction. I think Maria did post some ideas.
>
>Jerome> - Otherwise, what is the foreseable schedule for the next
>Jerome> revisions of SMIng drafts adressing this topic?
>
>See above. We first need resolution whether we want to do methods at
>all at this point in time.
>
>/js