Skip to main content

Last Call Review of draft-ietf-soc-load-control-event-package-10
review-ietf-soc-load-control-event-package-10-secdir-lc-eastlake-2013-12-05-00

Request Review of draft-ietf-soc-load-control-event-package
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-12-03
Requested 2013-11-07
Authors Charles Shen , Henning Schulzrinne , Arata Koike
I-D last updated 2013-12-05
Completed reviews Genart Last Call review of -10 by Dan Romascanu (diff)
Genart Telechat review of -11 by Dan Romascanu (diff)
Secdir Last Call review of -10 by Donald E. Eastlake 3rd (diff)
Opsdir Telechat review of -13 by Benoît Claise
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-soc-load-control-event-package by Security Area Directorate Assigned
Reviewed revision 10 (document currently at 13)
Result Has nits
Completed 2013-12-05
review-ietf-soc-load-control-event-package-10-secdir-lc-eastlake-2013-12-05-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This draft provides SIP capabilities (a load control event package)
for filtering calls with the intent of better handling overload
conditions. As you might expect for an extension to an existing
protocol, there are many references to existing SIP RFCs.

The Security Considerations Section appears to be adequate. It
references RFCs 6665 and other sections of the draft and seems to
summarize relevant threats.

Minor points:

The introductions (Section 1) give examples of anticipatable and
unanticipatable causes of overload. I find it curious that denial of
service attacks are not listed as a possible cause of unanticipated
overload.

In Section 10, in answer to REQ 17, there is a reference to Section 10
that, I believe, should be to Section 11.

Editorial:

Section 4 begins with what is said to be a list of requirements. And I
think almost all of them are. But the first item is just not worded as
a requirement. It says "... we focus ...". To be a requirement on the
solution it should talk about the solution, not the authors. I think,
it should be more like "For simplicity, the solution should focus on a
method of controlling SIP load, rather than a generic application
layer mechanism."

Misc:

The document contains lots of XML that I did not run through any
formal syntax check.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3 at gmail.com