RE: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review

["Kevin Lingle \(klingle\)" <klingle at cisco.com>]

hi juergen,

sorry for the late reply, i was on vacation.   you make good points.
i am attempting to get with jean-francois mule (co-author of the I-D) 
so we can discuss this issue.  

kevin 

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder at iu-bremen.de] 
Sent: Friday, July 15, 2005 2:52 PM
To: Kevin Lingle (klingle)
Cc: Romascanu, Dan (Dan); sip at ietf.org; Wijnen, Bert (Bert);
jf.mule at cablelabs.com
Subject: Re: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review

On Fri, Jul 15, 2005 at 02:13:45PM -0400, Kevin Lingle (klingle) wrote:

> 	A few issues were found related to the definition of the 
> SipMethodIdentifier TC and its usage:
> 	 
> 	1.  The way it is defined the TC encourages extensibility, and
this 
> can be regarded as a good thing. In order to do this a vendor must 
> invent some numerical assignment, which is not yet used by the 
> standard, and the DESCRIPTION requires that this assignment "MUST 
> ensure no collision with officially assigned method identifier values"

> but says nothing about how collision can be avoided.
> 	[klingle] one would avoid collision by checking the IANA
maintained 
> list of latest officially assigned method id
> 	values... at least that was the intent/expectation.   if that is
> sufficient, can we simply add that text?

I fail to see how that avoids collisions.
 	 
> 	2. Another MIB Doctor asked 'why the method name has not been
used as 
> an index as this would be the natural naming scheme. Having to go 
> through a lookup table (in case the SipMethodIdentifier has only local

> significance) is painful and the alternative to establish another IANA

> registry to number the SIP methods seems also kind of costly.'. I am 
> not sure that a change is necessary at this stage, as nothing is 
> broken, but as I would suggest that you provide a rationale for this 
> design choice.
> 	[klingle]  i think this was discussed at some point in the past.
> the rationale i recall had to do with the ease of 
> 	integral indexing in snmp tables vs. variable-length string
> indexes.   keep in mind that the mib's generally a 
> 	machine interface in that a NM application should be doing the
GETs 
> and then has the opportunity to present
> 	the data in a more user-friendly fashion to a human being.  so
we 
> thought the use of string methods indexing
> 	the tables everywhere was less efficient for the agent 
> implementations.

We all know that MIBs are a machine interface. We also know that lots of
people use generic MIB browsers short of a suitable machine interface.

The more important point I think is that the native identification of a
method is the method name. Introducing a new numeric numbering scheme
plus a mapping mechanism adds complexity and increases the potential to
get things wrong - I would be very careful in trading simplicity,
clarity and ease of use against agent implementation efficiency gains,
which clearly depend on the SNMP toolkit you use (and with many good
toolkits, there hardly would be a difference).

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen,
Germany

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip