Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt

[Janet P Gunn <[e-mail]>]

I prefer MUST to SHOULD.

The original wording was based on Req 13 of RFC 5390:
" REQ 13:  The mechanism must not dictate a specific algorithm for
      prioritizing the processing of work within a proxy during times of
      overload.  It must permit a proxy to prioritize requests based on
      any local policy, so that certain ones (such as a call for
      emergency services or a call with a specific value of the
      Resource-Priority header field [RFC4412]) are given preferential
      treatment, such as not being dropped, being given additional
      retransmission, or being processed ahead of others."

which has a lower case "must".

If we are going to say "MUST honor" (rather than "must permit"), I think 
we need to change "any" to "the" . (you can permit many alternatives, but 
you can really only honor one).  I think this also reflects the intent of 
Martin's  comment

So I would prefer


   A SIP client MUST honor the local policy for prioritizing SIP
   requests such as policies based on message type, e.g., INVITEs vs.
   requests associated with existing sessions.

   A SIP client MUST honor the local policy for prioritizing SIP
   requests 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.

   A SIP client MUST honor the local policy for prioritizing SIP
   requests relating to emergency calls, as identified by the SOS
   URN [RFC5031] indicating an emergency request.


Thanks

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.



From:   "Vijay K. Gurbani" <[e-mail]>
To:     Charles Shen <[e-mail]>
Cc:     "DRAGE, Keith (Keith)" <[e-mail]>om>, Janet P 
Gunn/USA/CSC@CSC, "[e-mail]" <[e-mail]>rg>, Arata 
Koike <[e-mail]>jp>, "NOEL, ERIC (ERIC C)" <[e-mail]>om>, 
Henning Schulzrinne <[e-mail]>
Date:   01/03/2013 11:42 AM
Subject:        Re: [sip-overload] Local Policy Re: I-D Action: 
draft-ietf-soc-load-control-event-package-05.txt



On 01/03/2013 07:34 AM, Charles Shen wrote:
> Sounds good, I can update the wording in the event package draft, if
> Vijay is OK with the other one.

I just want to make sure we are all agreeing to the same thing.

It seems to me that the question of using SHOULD versus MUST is being
decided slightly in favour of a MUST.  Martin and Bruno prefer a MUST,
Janet is okay with, although her original text used a SHOULD; and Keith
could go either way.

Is the consensus, then, that the text on honoring local policy contains
MUST?  If so, the text to be inserted would be the following:

   A SIP client MUST honor any local policy for prioritizing SIP
   requests such as policies based on message type, e.g., INVITEs vs.
   requests associated with existing sessions.

   A SIP client MUST honor any local policy for prioritizing SIP
   requests 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.

   A SIP client MUST honor any local policy for prioritizing SIP
   requests relating to emergency calls, as identified by the SOS
   URN [RFC5031] indicating an emergency request.

Yes?

Thanks,

- 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} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/