Telechat Review of draft-ietf-soc-overload-control-14
review-ietf-soc-overload-control-14-genart-telechat-carpenter-2014-02-03-00

Request Review of draft-ietf-soc-overload-control
Requested rev. no specific revision (document currently at 15)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-02-04
Requested 2014-01-31
Authors Vijay Gurbani, Volker Hilt, Henning Schulzrinne
Draft last updated 2014-02-03
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-telechat-carpenter-2014-02-03
Reviewed rev. 14 (document currently at 15)
Review result Almost Ready
Review completed: 2014-02-03

Review
review-ietf-soc-overload-control-14-genart-telechat-carpenter-2014-02-03

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 wait for direction from your document shepherd
or AD before posting a new version of the draft.

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: 2014-02-06

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

Comments:
---------

Most of my LC comments were resolved, but one small change is
expected (see below). Also the IESG has to fix the nit mentioned
below.

Note: 

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



Minor Issue:
-----------

"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.)  Vijay suggested: I can insert the following
sentence as the last sentence of the lone paragraph in S5.6:

   "Of course, the proxy can add overload control parameters pertinent
    to itself in the Via header it inserts in the request going
    downstream."

This would be fine.

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"?