Re: [sip-overload] draft-ietf-soc-overload-design-05

Vijay,

What is there now is fine with me. I see no need for change.

Janet

sip-overload-bounces@ietf.org wrote on 04/19/2011 11:02:00 AM:

> [image removed] 
> 
> Re: [sip-overload] draft-ietf-soc-overload-design-05
> 
> Vijay K. Gurbani 
> 
> to:
> 
> sip-overload
> 
> 04/19/2011 11:00 AM
> 
> Sent by:
> 
> sip-overload-bounces@ietf.org
> 
> On 04/19/2011 09:30 AM, ken carlberg wrote:
> > I think the subject has been beaten to a pulp. And to a large degree, 
we
> > have gone much further into topics than perhaps was necessary. The
> > purpose of the suggested new next was to broaden the picture and bring
> > up topics that are attributed to the RPH. The only position that was
> > taken in the text was to suggest in the form of a "should" the use of
> > the first RPH (which I meant to be the first "recognized/supported"
> > RPH). But I conceded that i was fine to remove that position.
> [...]
> 
> As the editor of draft-ietf-sip-overload-control, I have read this
> thread with interest.
> 
> So, the question now is: what, if any, from this thread carries over
> into the draft-ietf-sip-overload-control draft?  I am certainly not
> up to verse with RPH as some of the members of this working group
> are, so I will depend on them to point out any text that should be
> modified in draft-ietf-sip-overload-control.
> 
> For the sake of completeness, here is what
> draft-ietf-sip-overload-control has to say about prioritizing
> requests containing the RPH header:
> 
>     A SIP client SHOULD honor the local policy for prioritizing SIP
>     requests such as policies based on the content of the Resource-
>     Priority header (RPH, RFC4412 [RFC4412]).  Specific 
(namespace.value)
>     RPH contents may indicate high priority requests that should be
>     preserved as much as possible during overload.  The RPH contents can
>     also indicate a low-priority request that is eligible to be dropped
>     during times of overload.  Other indicators, such as the SOS URN
>     [RFC5031] indicating an emergency request, may also be used for
>     prioritization.
> 
> Do we deem this to be enough?
> 
> Thanks,
> 
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload