Subject: [Sip] Update of SIP MIB to your MIB Doctor comments

From: Allison Mankin <[email-masked]>
Date: Wed, 15 Mar 2006 08:29:40 -0800

Hi, Dan, Juergen,

The recently released draft-ietf-sip-mib-10 is an update responding to
the MIB Doctor comments.

Because the cycling on this draft is very long, and Dan's time
is going to be very tight (congratulations on the ADship - ulp)
I'm hoping you could re-review this quickly.  If you have any issues
but they are not too big, I'd like to advise Cullen to send the document
to IETF Last Call with your concerns as Last Call comments.  Depending
of course on the needed fixes, a revision or Notes to the RFC
Editor could even be possible after the IESG review.

Bottom line: re-review?

Allison

A reminder of your 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. 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. 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.
> 3. The TC misses a DISPLAY-HINT (probably "d"), which results into a
> smilint warning
> 
> 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