Hi Vijay, On 17/12/2013 03:36, Vijay K. Gurbani wrote: > 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 ...".
OK, if it is a hard-won rough consensus let it stand! > >> "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. Exactly. (I know it is stating the obvious, but it removes any doubt from the reader's mind.) > >> "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. It's fine as long as you've thought about it. The official rule is in RFC 2026: the document must 'stand as a complete and understandable document with or without the reference to the "Work in Progress".' > >> 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. You're welcome! Brian _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
