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

From: "Kevin Lingle \(klingle\)" <[email-masked]>
Date: Fri, 15 Jul 2005 14:13:45 -0400

hi dan.  sorry for the delayed response.   please see inline for my
comments.  j-f, please feel free
to chime in.

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Romascanu, Dan (Dan)
	Sent: Wednesday, June 01, 2005 8:48 AM
	To: [email-masked]
	Cc: Wijnen, Bert (Bert); [email-masked]
	Subject: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review

	Here are my review comments. I apologize for the delay, but
unfortunately the document is not yet completely problems free, and it
generated some discussions 'in the doctors room':
	 
	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?
	 
	 It would be useful to split the identifiers numbers space into
standard and experimental, and create a second experimental registry
where vendors building an extension method and receive a number in the
experimental space.
	
	[klingle] as long as the IANA administration of the second
registry isn't too much, this is a possibility.
	would you invision something like id values greater than 255
would be experimental space.  
	that's an arbitrary demarcation based on the assumption that
there wouldn't be over 255 offical methods 
	ever defined.   it would still be a vendor's responsibility to
avoid collision by getting an experimental number.
	i would expect the experimental number would forever be
allocated and not re-usuable.
	how much real new method creation is actually going to happen w/
SIP protocol? 
	 
	 This would ensure that collisions are avoided, and experimental
methods are identified at a glance.
	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.
	 
	3. The TC misses a DISPLAY-HINT (probably "d"), which results
into a smilint warning 
	[klingle] ok.  will check on that.
	 
	i will be on vacation next week and will try and address the
editorial comments below
	when i return.
	 
	thanks for the review!
	kevin 
	 
	Some more editorial things. 
	 
	4. Since the document was published the Intellectual Property
boilerplates were updated. See
http://www.ietf.org/ietf/1id-guidelines.txt for the latest version
	5. It is recommended that the module name of the SIP-TC module
be changed to SIP-TC-MIB
	6. typo - DESCRIPTION clause of SipStatusCodeNotifTable -
"seperate"
	7. typo - DESCRIPTION clause of SipMethodIdentifier -
"extention"
	8. typo - DESCRIPTION clause of sipServiceNotifEnable -
"approriate"
	9. type - DESCRIPTION clause of sipServiceWarmStart -
"adminstrative"
	10. There are 129 instances of too long lines in this documents.
Please run idnits for the full list
http://ietf.levkowetz.com/tools/idnits/idnits.pyht
	11. Warnings of weird spacing in lines 
	tmp/draft-ietf-sip-mib-09.txt(4495): Line has weird spacing:
'...CodeIns   rena...'
	tmp/draft-ietf-sip-mib-09.txt(4496): Line has weird spacing:
'...odeOuts  renam...'
	tmp/draft-ietf-sip-mib-09.txt(4789): Line has weird spacing:
'...odTable  in th...'
	12. As Section 8 including the Log of Changes will be taken out,
but there are other sections after this section it would be better to
move it to an annex and renumber, making sure that proper references
from the text go to the intended place.
	 
	Regards,
	 
	Dan

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Kevin Lingle \(klingle\)" <[email-masked]>
Date: Thu, 28 Jul 2005 16:28:18 -0400

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:[email-masked]] 
Sent: Friday, July 15, 2005 2:52 PM
To: Kevin Lingle (klingle)
Cc: Romascanu, Dan (Dan); [email-masked]; Wijnen, Bert (Bert);
[email-masked]
Subject: Re: [Sip] draft-ietf-sip-mib-09.txt - 'MIB Doctor' review

> 	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.
maintained 
> list of latest officially assigned method id

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 
GETs 
> and then has the opportunity to present
we 
> thought the use of string methods indexing

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