Last Call Review of draft-ietf-soc-overload-control-14
review-ietf-soc-overload-control-14-genart-lc-carpenter-2013-12-14-00

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-soc-overload-control-14.txt
Reviewer: Brian Carpenter
Review Date: 2013-12-15
IETF LC End Date: 2013-12-23
IESG Telechat date:

Summary:  Almost ready
--------

Comments:
---------

Note: 

http://datatracker.ietf.org/ipr/1364/



Minor Issues:
------------

"  The normative statements in this specification as they apply to SIP
   clients and SIP servers assume that both the SIP clients and SIP
   servers support this specification.  If, for instance, only a SIP
   client supports this specification and not the SIP server, then
   follows that the normative statements in this specification pertinent
   to the behavior of a SIP server do not apply to the server that does
   not support this specification."

I don't find the second sentence useful. A useful sentence would be
a summary of what might go wrong if one side supports this specification
and the other doesn't. (As detailed in 5.10.2 for example.)

"5.6.  Forwarding the overload control parameters

   Overload control is defined in a hop-by-hop manner.  Therefore,
   forwarding the contents of the overload control parameters is
   generally NOT RECOMMENDED and should only be performed if permitted
   by the configuration of SIP servers.  This means that a SIP proxy
   SHOULD strip the overload control parameters inserted by the client
   before proxying the request further downstream."

I think the reader should be reminded at this point that the proxy also
behaves as a client, so will immediately re-insert its own "oc" parameters.
(In fact it would be very odd if the proxy supported overload control
upstream but not downstream.)

"13.2.  Informative References"

I am not convinced that I-D.ietf-soc-overload-rate-control is correctly
classified as an Informative reference; for example see the citation
in section 5.3. It seems to me that an implementor would need to
consult the reference.

Ditto I-D.ietf-soc-load-control-event-package (section 8).

Nit:
----

I hope this is a nit: the Last Call says it's for "Internet Standard"
but surely it's intended to be "Proposed Standard"?