Re: [secdir] SECDIR review of draft-ietf-soc-load-control-event-package-11.txt

[Volker Hilt <[e-mail]>]

Charles,

Thanks for taking care of these comments!

Volker

On 04.12.2013 17:31, Charles Shen wrote:
> Hi Donald, thanks for reviewing, please see responses inline:
>
>
> On Tue, Dec 3, 2013 at 6:31 AM, Donald Eastlake <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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.
>
>
>
> Interestingly that thought occurred to me before. I think the ones we
> are listing now is slightly different from DoS in the sense that they
> are more real-people-calling overload vs. DoS where machine-made calling
> can be common. Also DoS is usually seen as an attack, while those listed
> examples seem all have legitimate causes. That said, I do think the
> network server still observes the fact of overload during DoS, so I have
> no problem adding it to the list.
>
>
>     In Section 10, in answer to REQ 17, there is a reference to Section 10
>     that, I believe, should be to Section 11.
>
>
> Good catch!
>
>
>     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."
>
>
> Done.
>
>     Misc:
>
>     The document contains lots of XML that I did not run through any
>     formal syntax check.
>
>
>
> I ran them through xmlvalidation.com <http://xmlvalidation.com>.
>
> thanks!
>
> Charles
>
>
>
>     Thanks,
>     Donald
>     =============================
>       Donald E. Eastlake 3rd [phone] <tel:%2B1-508-333-2270> (cell)
>       155 Beaver Street, Milford, MA 01757 USA
>     [e-mail] <mailto:[e-mail]>
>
>