Last Call Review of draft-ietf-soc-overload-control-14

Request Review of draft-ietf-soc-overload-control
Requested rev. no specific revision (document currently at 15)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-12-23
Requested 2013-12-12
Authors Vijay Gurbani, Volker Hilt, Henning Schulzrinne
Draft last updated 2013-12-14
Completed reviews Genart Last Call review of -14 by Brian Carpenter (diff)
Genart Telechat review of -14 by Brian Carpenter (diff)
Secdir Last Call review of -14 by Joseph Salowey (diff)
Assignment Reviewer Brian Carpenter 
State Completed
Review review-ietf-soc-overload-control-14-genart-lc-carpenter-2013-12-14
Reviewed rev. 14 (document currently at 15)
Review result Almost Ready
Review completed: 2013-12-14


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

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



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).


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