Re: [Gen-art] Gen-ART LC review of draft-ietf-soc-overload-control-14.txt

[Brian E Carpenter <[e-mail]>]

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