Brian: Thank you for the review. Please see inline.
On 12/14/2013 04:10 PM, Brian E Carpenter wrote:
[...]
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.)
This blanket statement was added at the behest of the WG that preferred
such a statement in lieu of most sentences starting with "If a SIP
client supports ...".
"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.)
You are right that most, if not all, proxies would support overload
control on the client and server side. When the proxy acts as a server,
it will ask the upstream client to throttle messages if the proxy is
overloaded. When the proxy acts as a client, it is performing
throttling for the downstream server.
However, the pedantic notion in the text you quote is that the proxy
scrubs the overload control parameters from the Via header corresponding
to the upstream client, and adds overload control parameters in the Via
header the proxy inserts in the request going further downstream. To
make this notion clear, 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."
Let me know if that captures the intent of your comment.
"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.
So, draft-ietf-soc-overload-rate-control is an informative
reference to this draft. This follows from the fact that draft-
ietf-soc-overload-control defines a framework where different classes
of overload control algorithms could be plugged in. Performing
overload control by using a rate-based algorithm is one such example.
Implementors of draft-ietf-soc-overload-control only implement the
loss-based traffic reduction algorithm, but the text exhorts them to
play better with other class of algorithms by pointing out that other
traffic reduction schemes may be used as well.
Your comment above actually triggered me to ensure that draft-ietf-soc-
overload-rate-control has a normative dependency on draft-ietf-soc-
overload-control. It does not. I will inform the author of the rate-
control draft.
Ditto I-D.ietf-soc-load-control-event-package (section 8).
Ditto as above.
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"?
Oh gosh, yes, indeed. It is supposed to be a PS.
Thanks for your time, Brian. I appreciate your comments.
Cheers,
- vijay
--
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
