[Sip] Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07

[Kevin Lingle <klingle@cisco.com>]

mary,

responding to the nits/general comments....

Mary Barnes wrote:
> Hi all,
>
> Per my assignment, I've reviewed sections 7.2 and 8 through 10 of the MIB,
> with the following general comments and nits.  I have a few specific points
> that require discussion that I'll post in separate emails to facilitate WG
> discussion and hopefully to allow easier tracking of issues.  I did try to
> conscientiously review previous comments on the mailing list and to review
> previous versions to make sure that I wasn't bringing up things for which
> there had been consensus.  I do apologize if I inadvertently open an issue
> that was truly closed by the WG. 
> - Section 7.2, page 14.  The descriptions need to be updated to reflect RFC
> 3261 (section 6) terminology/definitions for User Agent, Proxy Server,
> Redirect Server and Registrar. 
done.

> - Section 7.2, page 15. Really minor nit, but I found it very difficult to
> read the common MIB objects with no blank lines between the comment lines
> and the object definitions. 
done.

> - Section 7.2, page 20.  sipEntitytype.  Per Cullen's comments not
> separating the Proxy and Redirect Server, this would need to be reflected in
> this object definition. 
pending resolution of cullen's comments on no seperate representation
of proxy and redirect servers in the mib.


> - Section 8:  My understanding is that this section should be removed by the
> RFC Editor.  Thus, I would suggest adding a comment as such (something like:
> "This section to be removed by RFC Editor before publication." and moving
> this section just prior to the Author's address to facilitate that process. 
done (patially).  i added the line you suggested to the section, but
didn't move the section.   the xml2rfc tool we've started using appears
rather ridge in some of the "template" sections.  i'm not exactly certain
on altering the order of sections that are part of the <back></back>.
how important is it that we move this section since it will be removed
anyway?


> - Section 9, page 109.  The statement "If these objects are SET maliciously,
> it may result in
> incorrect or unwanted protocol operation." is probably a bit of an
> understatement with regards to the timer, retry and expire values being
> misconfigured. Certainly, a well designed system would but reasonable
> boundaries on how these things can be configured, so as to hopefully prevent
> significant problems.  Cullen had brought up the more general issue of
> whether all the timers should be configurable in his comments. Like Cullen,
> I haven't thought about this enough to decide whether all these timers
> should be configurable, but at a minimum, I think the  security section
> needs a more robust statement.
is this commented wrt the entire security section or just the area
you referred to on pg 109?

is it that we have not made a strong enough statement about the
protocol impact to these particular timer/retry related objects
being SET??

thanks!
kevin

> Regards,
> Mary H. Barnes
> mbarnes@nortelnetworks.com

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Kevin R. Lingle       919.392.2029
 http://www.klove.com                               http://www.air1.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


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