[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Sip] Re: NITS/General Editorial Comments on draft-ietf-sip-mib-07
hi mary,
thanks very much for your comments. jean-francios and i will
address them very soon.
kevin
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.
- 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.
- 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.
- 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.
- 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.
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