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

From: <[email-masked]>
Date: Wed, 2 Jan 2013 10:08:43 +0000

I would say it is the « local policy » defined by the carrier but it has to comply with the regulation in force in the country where the carrier is operating.   “Should” could be understood as providing room for not honoring any local policy except one that has been hard-coded by the vendor of the equipment.  An undesirable side-effect would be that different SIP entities from different vendors could react differently while being used in the same network.
BC

De : Janet P Gunn [mailto:[email-masked]]
Envoyé : lundi 31 décembre 2012 18:17
À : Charles Shen
Cc : CHATRAS Bruno OLNC/OLN; [email-masked]; NOEL, ERIC (ERIC C); Henning Schulzrinne; Arata Koike; [email-masked]; [email-masked]
Objet : Local Policy Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt

I would  be happy with "MUST", but I'd like to hear form the carriers- especially from Keith Drage, as he is the one who initiated the new wording.

It may be a question of  WHOSE local policy we are talking about.   There is the "local policy" as defined by the government (which may politically correct but technically unstable).  There is also "local policy" defined by the "carrier" (which may be  technically stable, but politically incorrect).

"Should" leaves some wiggle room as to WHICH local policy  is being honored.

Janet

From:        Charles Shen <[email-masked]<mailto:[email-masked]>>
To:        [email-masked]<mailto:[email-masked]>
Cc:        Janet P Gunn/USA/CSC@CSC, "NOEL, ERIC (ERIC C)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Arata Koike <[email-masked]<mailto:[email-masked]>>, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>
Date:        12/18/2012 10:32 PM
Subject:        Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt
Sent by:        [email-masked]<mailto:[email-masked]>
________________________________

Hi Bruno, I noticed your comment, can we reach a consensus on this list so I can update the draft accordingly?

Thanks!

Charles

On Mon, Dec 17, 2012 at 10:28 AM, <[email-masked]<mailto:[email-masked]>> wrote:
I agree that both drafts should use the same text but I’m still not sure to understand why we use “SHOULD” rather than “MUST”?  Setting a local policy is optional but if there is one it seems to me that  SIP clients MUST honor it.

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] De la part de Charles Shen
Envoyé : samedi 15 décembre 2012 16:06
À : Janet P Gunn
Cc : NOEL, ERIC (ERIC C); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Arata Koike; Henning Schulzrinne
Objet : Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt

Hi Janet, I will revise as suggested. Thanks you again!

Charles

On Fri, Dec 14, 2012 at 3:56 PM, Janet P Gunn <[email-masked]<mailto:[email-masked]>> wrote:

You can count my review for IESG.

I only have a couple of things to add.

In section 4.4, you have the text:
“In addition, whatever the actual policy is, SIP
   servers SHOULD honor the local policy for prioritizing SIP requests
   such as policies based on the contents of the Resource-Priority
   Header (RPH) [RFC4412].  The RPH contents may indicate high priority
   requests that should be preserved as much as possible, or low
   priority requests that could be dropped during overload.  Other
   indicators, such as the SOS Uniform Resource Name (URN) [RFC5031]
   indicating an emergency request, may also be used for prioritization.”

During the last IETF meeting, there was an exchange on the list  about this wording (in multiple IDs) with apparent agreement (on the list) to use  the same text in all the overload drafts

"   A SIP client SHOULD 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 SHOULD 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 SHOULD honor any local policy for prioritizing SIP
 requests relating to emergency calls, as identified by the SOS
 URN [RFC5031] indicating an emergency request."

So would you please use this revised wording.

nits

Sec 5.8 last sentence of first paragraph
“A subscriber receiving the notification first installs
   these rules and then filter incoming requests to enforce actions on
   appropriate requests, for example, limiting the sending rate of call
   requests destined for a specific SIP entity.”
“filter” should be “filters”

Pg 18
This
“this solution does not permit to define a filter that excludes
   all E.164 numbers in that country but retain all short service
   numbers.”
Should be
“this solution does not permit the definition of filter that excludes
   all E.164 numbers in that country but retain all short service
   numbers.”

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:        "NOEL, ERIC  (ERIC C)" <[email-masked]<mailto:[email-masked]>>
To:        "'Charles Shen'" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:        Arata Koike <[email-masked]<mailto:[email-masked]>>, Henning Schulzrinne <[email-masked]<mailto:[email-masked]>>
Date:        12/13/2012 03:01 PM

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

Sent by:        [email-masked]<mailto:[email-masked]>

________________________________

Charles,

I went through your latest version and have no comments beyond what was already posted.

You can have my review counted for the IESG review.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174<tel:732.420.4174>
[email-masked]<mailto:[email-masked]>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Charles Shen
Sent: Monday, October 22, 2012 12:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Arata Koike; Henning Schulzrinne
Subject: Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt

Hi all,

I've submitted a new version of draft-ietf-soc-load-control-event-package.

Diff is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-load-control-event-package-05

This version should have incorporated responses to all comments received so far (please let me know if I missed anything). Main changes include adding: 6.3.3 (target-sip-entity, currently optional) 6.5.2 (example message flow), removing 5.12 (state agent), as well as changes and clarifications in a number of other sections, e.g., 6.3.2 (explicit list of method types subjected to control) 6.4 (using redirect as alternative action), 5.8 (terminating policies upon termination of subscription) and 13.2 PSTN references.

Comments are welcome !

Charles

On Mon, Oct 22, 2012 at 12:32 PM, <[email-masked]<mailto:[email-masked]>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIP Overload Control Working Group of the IETF.

       Title           : A Session Initiation Protocol (SIP) Load Control Event Package
       Author(s)       : Charles Shen
                         Henning Schulzrinne
                         Arata Koike
       Filename        : draft-ietf-soc-load-control-event-package-05.txt
       Pages           : 39
       Date            : 2012-10-22

Abstract:
  We define a load control event package for the Session Initiation
  Protocol (SIP).  It allows SIP servers to distribute load filters to
  other SIP servers in the network.  The load filters contain rules to
  throttle calls based on their source or destination domain, telephone
  number prefix or for a specific user.  The mechanism helps to prevent
  signaling overload and complements feedback-based SIP overload
  control efforts.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-load-control-event-package-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sip-overload mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sip-overload
 _______________________________________________
sip-overload mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sip-overload

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Wed, 2 Jan 2013 15:20:44 +0000

I agree with Bruno, in that it needs to be a “MUST”. Why have local policy, if it is not a MUST.

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 02, 2013 5:09 AM
To: Janet P Gunn; Charles Shen
Cc: [email-masked]; [email-masked]; Arata Koike; NOEL, ERIC C; Henning Schulzrinne
Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt

De : Janet P Gunn [mailto:[email-masked]]
Envoyé : lundi 31 décembre 2012 18:17
À : Charles Shen
Cc : CHATRAS Bruno OLNC/OLN; [email-masked]<mailto:[email-masked]>; NOEL, ERIC (ERIC C); Henning Schulzrinne; Arata Koike; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Objet : Local Policy Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt

Janet

Thanks!

Charles

Charles

nits

Pg 18
This

Janet

Charles,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Hi all,

Comments are welcome !

Charles

Abstract:

Thank you.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 2 Jan 2013 20:00:05 +0100

I don't have a problem either way - all I want to ensure is that the text of the two drafts aligns with each other on the behaviour - so if we change this one, we also change the other.

Regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: 31 December 2012 17:17
To: Charles Shen
Cc: [email-masked]; [email-masked]; Arata Koike; NOEL, ERIC (ERIC C); Henning Schulzrinne
Subject: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt

Janet

From:        Charles Shen <[email-masked]>
To:        [email-masked]
Cc:        Janet P Gunn/USA/CSC@CSC, "NOEL, ERIC (ERIC C)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Arata Koike <[email-masked]>, Henning Schulzrinne <[email-masked]>
Date:        12/18/2012 10:32 PM
Subject:        Re: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-05.txt
Sent by:        [email-masked]
________________________________

Thanks!

Charles

On Mon, Dec 17, 2012 at 10:28 AM, <[email-masked]<mailto:[email-masked]>> wrote:
I agree that both drafts should use the same text but I'm still not sure to understand why we use "SHOULD" rather than "MUST"?  Setting a local policy is optional but if there is one it seems to me that  SIP clients MUST honor it.

Charles

In section 4.4, you have the text:
"In addition, whatever the actual policy is, SIP
   servers SHOULD honor the local policy for prioritizing SIP requests
   such as policies based on the contents of the Resource-Priority
   Header (RPH) [RFC4412].  The RPH contents may indicate high priority
   requests that should be preserved as much as possible, or low
   priority requests that could be dropped during overload.  Other
   indicators, such as the SOS Uniform Resource Name (URN) [RFC5031]
   indicating an emergency request, may also be used for prioritization."

nits

Sec 5.8 last sentence of first paragraph
"A subscriber receiving the notification first installs
   these rules and then filter incoming requests to enforce actions on
   appropriate requests, for example, limiting the sending rate of call
   requests destined for a specific SIP entity."
"filter" should be "filters"

Pg 18
This
"this solution does not permit to define a filter that excludes
   all E.164 numbers in that country but retain all short service
   numbers."
Should be
"this solution does not permit the definition of filter that excludes
   all E.164 numbers in that country but retain all short service
   numbers."

Janet

Charles,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Hi all,

Comments are welcome !

Charles

Abstract:

---

From: Charles Shen <[email-masked]>
Date: Thu, 3 Jan 2013 08:34:09 -0500

Sounds good, I can update the wording in the event package draft, if
Vijay is OK with the other one.

Thanks

Charles

On Wed, Jan 2, 2013 at 2:00 PM, DRAGE, Keith (Keith)
<[email-masked]> wrote:
> I don’t have a problem either way – all I want to ensure is that the text of
> the two drafts aligns with each other on the behaviour – so if we change
> this one, we also change the other.
>
>
>
> Regards
>
>
>
> Keith
>
>
>
> Subject: [sip-overload] Local Policy Re: I-D Action:
> draft-ietf-soc-load-control-event-package-05.txt
>
>
>
>
> I would  be happy with "MUST", but I'd like to hear form the carriers-
> especially from Keith Drage, as he is the one who initiated the new wording.
>
> It may be a question of  WHOSE local policy we are talking about.   There is
> the "local policy" as defined by the government (which may politically
> correct but technically unstable).  There is also "local policy" defined by
> the "carrier" (which may be  technically stable, but politically incorrect).
>
> Cc:        Janet P Gunn/USA/CSC@CSC, "NOEL, ERIC (ERIC C)" <[email-masked]>,
> "[email-masked]" <[email-masked]>,
> "[email-masked]" <[email-masked]>, Arata Koike
> <[email-masked]>, Henning Schulzrinne <[email-masked]>
> Subject:        Re: [sip-overload] I-D Action:
> draft-ietf-soc-load-control-event-package-05.txt
> On Mon, Dec 17, 2012 at 10:28 AM, <[email-masked]> wrote:
> I agree that both drafts should use the same text but I’m still not sure to
> understand why we use “SHOULD” rather than “MUST”?  Setting a local policy
> is optional but if there is one it seems to me that  SIP clients MUST honor
> it.
>
>
>
>
>
>
>
> De : [email-masked] [mailto:[email-masked]] De
> la part de Charles Shen
> Cc : NOEL, ERIC (ERIC C); [email-masked];
> [email-masked]; Arata Koike; Henning Schulzrinne
> Objet : Re: [sip-overload] I-D Action:
> draft-ietf-soc-load-control-event-package-05.txt
>
>
>
> On Fri, Dec 14, 2012 at 3:56 PM, Janet P Gunn <[email-masked]> wrote:
>
> During the last IETF meeting, there was an exchange on the list  about this
> wording (in multiple IDs) with apparent agreement (on the list) to use  the
> same text in all the overload drafts
>
> 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:        "NOEL, ERIC  (ERIC C)" <[email-masked]>
> To:        "'Charles Shen'" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> Cc:        Arata Koike <[email-masked]>, Henning Schulzrinne
> <[email-masked]>
> Subject:        Re: [sip-overload] I-D        Action:
> draft-ietf-soc-load-control-event-package-05.txt
>
> Sent by:        [email-masked]
>
> P: 732.420.4174
> [email-masked]
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Charles Shen
> To: [email-masked]
> Subject: Re: [sip-overload] I-D Action:
> draft-ietf-soc-load-control-event-package-05.txt
>
> Hi all,
>
> Diff is available at:
> This version should have incorporated responses to all comments received so
> far (please let me know if I missed anything). Main changes include adding:
> 6.3.3 (target-sip-entity, currently optional) 6.5.2 (example message flow),
> removing 5.12 (state agent), as well as changes and clarifications in a
> number of other sections, e.g., 6.3.2 (explicit list of method types
> subjected to control) 6.4 (using redirect as alternative action), 5.8
> (terminating policies upon termination of subscription) and 13.2 PSTN
> references.
>
> Comments are welcome !
>
> Charles
>
>
>
> On Mon, Oct 22, 2012 at 12:32 PM, <[email-masked]> wrote:
>
> [email-masked]
> [email-masked]
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange is not liable for messages
> that have been modified, changed or falsified.
> Thank you.
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 03 Jan 2013 10:43:21 -0600

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

---

From: <[email-masked]>
Date: Thu, 3 Jan 2013 17:04:08 +0000

yes

> -----Message d'origine-----
> De : [email-masked] [mailto:sip-overload-
> [email-masked]] De la part de Vijay K. Gurbani
> Envoyé : jeudi 3 janvier 2013 17:43
> À : Charles Shen
> Cc : [email-masked]; Arata Koike; NOEL, ERIC (ERIC C); Henning
> Schulzrinne
> Objet : Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-
> load-control-event-package-05.txt
>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 3 Jan 2013 12:52:05 -0500

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

   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" <[email-masked]>
To:     Charles Shen <[email-masked]>
Cc:     "DRAGE, Keith (Keith)" <[email-masked]>, Janet P 
Gunn/USA/CSC@CSC, "[email-masked]" <[email-masked]>, Arata 
Koike <[email-masked]>, "NOEL, ERIC (ERIC C)" <[email-masked]>, 
Henning Schulzrinne <[email-masked]>
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

Yes?

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Fri, 11 Jan 2013 15:06:58 +0100

Janet, All,

while this sounds good in most cases, the concern I have is that there 
may be situation where a proxy is forced to violate local policy. E.g., 
a policy "emergency calls can never be dropped" will have to be violated 
eventually if overload reaches levels where only emergency calls are left.

Maybe this boils down to formulating policies in a reasonable way. It 
has to be made clear, however, that not all policies call be kept under 
all circumstances.

A SHOULD would imply this to the developer. With a MUST, I think one 
would have to add explanatory text.

Thanks,

Volker [with individual contributor hat on]

On 03.01.2013 18:52, Janet P Gunn wrote:
>        overload*.  It must permit a proxy to prioritize requests based on*
> *      any local policy*, so that certain ones (such as a call for
> 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
>    A SIP client MUST honor *the *local policy for prioritizing SIP
>    A SIP client MUST honor *the *local policy for prioritizing SIP
> written agreement or government initiative expressly permitting the use
> of e-mail for such purpose.
>
>
>
> Koike <[email-masked]>, "NOEL, ERIC (ERIC C)"
> <[email-masked]>, Henning Schulzrinne <[email-masked]>
> ------------------------------------------------------------------------
>
>
>

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 11 Jan 2013 09:25:01 -0500

Good point

If you say it MUST honor "local policy", then you  need  constraints on 
what the local policy can do (e.g., it can only prioritize within the 
number of messages permitted by the overload algorithm, it can't over ride 
the overload mechanism/algorithm)

Janet

[email-masked] wrote on 01/11/2013 09:06:58 AM:

> From: Volker Hilt <[email-masked]>
> To: <[email-masked]>
> Date: 01/11/2013 09:07 AM

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 14 Jan 2013 14:56:27 +0200

my reading of the mailing list is that the question of using SHOULD 
versus MUST
is being decided in favor of MUST

however it would be great to also address the Valker concerns
inserting a caveat/constraints explaining that the local policy can not
override the overload mechanism/algorithm

can someone propose text ?

note this is the only remaining issue that we have to address in this 
event-package draft
before we can ship to the IESG

/Salvatore

On 1/11/13 4:25 PM, Janet P Gunn wrote:
>
> Good point
>
> If you say it MUST honor "local policy", then you  need  constraints 
> on what the local policy can do (e.g., it can only prioritize within 
> the number of messages permitted by the overload algorithm, it can't 
> over ride the overload mechanism/algorithm)
>
> Janet
>
>
>

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Volker Hilt <[email-masked]>
Date: Mon, 14 Jan 2013 15:21:34 +0100

I think SHOULD would, in fact, be the more appropriate wording here. 
There may be reasons why a local policy cannot be kept: a conflict with 
another policy, legal requirements, or very high levels of overload.

In the end, the local policy will be a local matter including its 
enforcement. In other words, if a service provider has a SIP server that 
ignores his policies, I'm sure the service provide will know who to call.

I've added a short explanatory sentence to the first paragraph:

A SIP client SHOULD 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 is expected generally to 
honor local policy except for very rare occasions when, for example, 
overload is so severe that messages, which should be preserved according 
to local policy, need to be discarded or local policies are in conflict.

A SIP client SHOULD 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 SHOULD honor the local policy for prioritizing SIP requests 
relating to emergency calls, as identified by the SOS URN [RFC5031] 
indicating an emergency request.

Thanks,

Volker [as individual]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jan 2013 08:32:13 -0600

On 01/14/2013 06:56 AM, Salvatore Loreto wrote:
> versus MUST is being decided in favor of MUST  [...]

Sal: Funny --- my reading of the mailing list after Volker and Janet's
emails suggests that Janet is okay with a SHOULD.

Given the number of people expressing an interest now, I think things
are weighing in favour of a SHOULD.

It will be good to close this so we can get the drafts out.

Thanks,

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 14 Jan 2013 09:56:00 -0500

I am OK with either MUST or SHOULD.

Janet

Date:   01/14/2013 09:30 AM

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jan 2013 09:02:48 -0600

I think the text Volker proposed below works, although it appears that
the explanatory sentence Volker added is applicable to only the first
paragraph.  I think that the sentence is equally applicable to all the
three SHOULDs.

I would, thus, suggest a small modification as detailed below.

> indicating an emergency request.

I would re-word as:

    A SIP client is generally expected to honor local policy for
    prioritizing SIP requests except for very rare occasions, when,
    for example, overload is so severe that messages that would
    otherwise be preserved according to local policy need to be
    now discarded.  Another example where local policies may not be
    honored is if these are in conflict.  Accordingly, the normative
    statements in the next three paragraphs should be interpreted in
    the context provided here and with the understanding that the SIP
    client will aim to preserve local policy to the fullest extent
    possible.

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

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

Unless someone has objections, I will put this into the
soc-overload-control draft, and I suspect that Charles will do the same
for his draft.

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Mon, 14 Jan 2013 16:02:00 +0100

Sounds good to me.

Volker

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 14 Jan 2013 17:08:58 +0200

while I am OK with the
"/A SIP client is expected generally to //
//honor local policy except for very rare occasions when, for example, //
//overload is so severe that messages, which should be preserved 
according //
//to local policy, need to be discarded/"

I don t like the last "/or local policies are in conflict/."
as it can generate confusion
i.e. what to do when local policies are in conflict, what policy then 
apply etc.

/Sal

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 14 Jan 2013 10:09:46 -0500

No, I don't like your added sentence.

A VALID local policy prioritizes within the volume of messages permitted 
by the algorithm.   A VALID local policy doe not attempt to send more 
messages than permitted by the Overload algorithm. 

A Local policy that attempts to override teh Overload Control Algorithm is 
not permitted

That is pretty clear in the wording of Req 13.

If you are going to say "MUST", then you must also define what constitutes 
a VALID local policy, in some detail.

If you are going to say "SHOULD", then you do not need to define a VALID 
local  policy in detail

But the way you have written it implies that it is permissible to have  a 
Local Policy that  attempts to override the Overload control algorithm, 
and so must, in turn  be over ridden by the Overload Algorithm.

I don't even what to suggest that such a case would occur.    I DO NOT 
WANT TO MENTION IT.

The SHOULD takes care of it.

Janet

[email-masked] wrote on 01/14/2013 09:21:34 AM:

> Date: 01/14/2013 09:22 AM

> >> > Subject: Re: [sip-overload] Local Policy Re: I-D Action: 
draft-ietf-
> >> > soc-load-control-event-package-05.txt
> >> > eventually if overload reaches levels where only emergency calls 
are
> >> left.
> >> > > If we are going to say "MUST honor" (rather than "must permit"), 
I
> >> think
> >> > > Gunn/USA/CSC@CSC, "[email-masked]" 
<[email-masked]>,
> >> Arata

---

From: Volker Hilt <[email-masked]>
Date: Mon, 14 Jan 2013 16:23:16 +0100

Janet,

the root of this discussion is probably that there is no definition of 
what local policies can be and what a valid local policy would be. I 
also don't think we should open this can worms right now, which is I 
think what you are suggesting also.

I do think, however, that it is useful to provide explanation to a 
developer why we used a SHOULD here.

We could say that it is expected a SIP client will follow local policy 
as long as the result leads to an acceptable load under current conditions.

This way we're not giving an example for a bad policy.

Thanks,

Volker

On 14.01.2013 16:09, Janet P Gunn wrote:
> A Local policy that attempts to override teh Overload Control Algorithm
> is not permitted
>
> If you are going to say "MUST", then you must also define what
> constitutes a VALID local policy, in some detail.
>
> But the way you have written it implies that it is permissible to have
>   a Local Policy that  attempts to override the Overload control
> algorithm, and so must, in turn  be over ridden by the Overload Algorithm.
>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 14 Jan 2013 11:04:31 -0500

I agree, except I would say 

"It is expected a SIP client will follow local policy 
 as long as the result is consistent with the SIP Overload Algorithm."

Janet

Volker Hilt <[email-masked]> wrote on 01/14/2013 10:23:16 AM:

> To: Janet P Gunn/USA/CSC@CSC
> Cc: <[email-masked]>, <[email-masked]>
> Date: 01/14/2013 10:23 AM
draft-ietf-
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP 
requests
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP 
requests
> >  > A SIP client SHOULD honor the local policy for prioritizing SIP 
requests
draft-ietf-
> >  > >> > while this sounds good in most cases, the concern I have is 
that
> > there
> >  > >> > a policy "emergency calls can never be dropped" will have to 
be
> >  > >> violated
> >  > >> > eventually if overload reaches levels where only 
emergencycalls are
> >  > >> > A SHOULD would imply this to the developer. With a MUST, 
Ithink one
> >  > >> > >        prioritizing the processing of work within a proxy 
during
> >  > >> times of
> >  > >> > >        overload*.  It must permit a proxy to prioritize 
requests
> >  > >> based on*
> >  > >> > > If we are going to say "MUST honor" (rather than "must 
permit"), I
> >  > >> > >    indicate high priority requests that should be preserved 
as
> > much as
> >  > >> > >    low-priority request that is eligible to be dropped 
during
> > times of
> >  > >> > > This is a PRIVATE message. If you are not the intended 
recipient,
> >  > >> please
> >  > >> > > written agreement or government initiative expressly 
permitting
> >  > >> the use
<[email-masked]>,
> >  > >> > >  > Sounds good, I can update the wording in the event 
package
> >  > >> draft, if
> >  > >> > > 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
> >  > >> > >    indicate high priority requests that should be preserved 
as
> > much as
> >  > >> > >    low-priority request that is eligible to be dropped 
during
> > times of

---

From: Volker Hilt <[email-masked]>
Date: Mon, 14 Jan 2013 17:09:03 +0100

That works for me!

Volker

On 14.01.2013 17:04, Janet P Gunn wrote:
>  > >  > >> > >    indicate high priority requests that should be
> preserved as
>  > > much as
>  > >  > >> > >    indicate high priority requests that should be
> preserved as
>  > > much as

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jan 2013 10:15:54 -0600

> That works for me!

Volker: Can either you or Janet please propose the exact wordings
to go into the modified text I proposed in [1]?  This will avoid
any guesswork and expedite the process of getting the drafts out.

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.html

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Mon, 14 Jan 2013 17:15:04 +0100

Vijay,

the sentence Janet has proposed works for me. You can replace the 
sentence I had suggested after the first paragraph with Janets proposal.

Cheers,

Volker

---

From: Charles Shen <[email-masked]>
Date: Mon, 14 Jan 2013 11:36:34 -0500

Hi Volker, Janet and Vijay,

Since we are talking about putting the same texts in the
overload-control and event-package draft, would it be better to
clarify a bit about "the SIP Overload Algorithm" in this sentence?

Specifically, are we referring to mechanisms in both drafts (and in
that case, should we add cross reference to them?) as well as any
future Overload Algorithms?

Thanks

Charles

On Mon, Jan 14, 2013 at 11:15 AM, Volker Hilt
<[email-masked]> wrote:
> Vijay,
>
> the sentence Janet has proposed works for me. You can replace the sentence I
> had suggested after the first paragraph with Janets proposal.
>
> Cheers,
>
> Volker
>
>
>
>
>> [1]
>> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00885.html
>>
>> Thanks,
>>
>> - vijay
>

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 14 Jan 2013 11:49:52 -0500

My personal thought is that in each case, it would refer to the Overload 
Algorithm(s) in effect at that node.

But that brings up a whole can of worms about interaction between 
algorithms..

If the Event package has set up an a-priori Overload  Control, and then an 
actual overload triggers a "feedback" Overload Control, how do they 
interact?  The max? the min? the "product"

Is that a can of worms we want to open at this point?

Janet

[email-masked] wrote on 01/14/2013 11:36:34 AM:

> To: Volker Hilt <[email-masked]>, Janet P Gunn/USA/
> CSC@CSC, "Vijay K. Gurbani" <[email-masked]>
> Cc: [email-masked]
> Date: 01/14/2013 11:37 AM
sentence I

---

From: Charles Shen <[email-masked]>
Date: Mon, 14 Jan 2013 12:03:22 -0500

I am not in favor of opening up more cans of whatever at this stage :)

I think we just need to define and clarify the line. At least "the Overload
 Algorithm(s) in effect at that node" sounds much better than "the
Overload Algorithm(s)" alone. (Optionally) plus something like "the
interactions of those Overload Algorithms are out of scope".

Thanks

Charles

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 14 Jan 2013 18:27:52 +0100

I'm not convinced we have got to the bottom of the requirement yet. Writing SHOULD is not an excuse for writing a poor requirement, yet that seems currently to be the excuse for wring SHOULD instead of MUST. Ideally I should still be able to still identify conformance or no conformance to a SHOULD requirement.

I suspect what we need to do is find a more specific requirement and then cover the rest of the problem in more informative text, rather than trying to address everything in a single requirement sentence.

I agree that if we end up writing a SHOULD, then there should be associated informative text that identifies the example circumstances for ignoring the SHOULD. That has long been an unwritten rule, and without it the SHOULD always gets interpreted as a MAY.

Regards

Keith

> -----Original Message-----
> Sent: 14 January 2013 17:03
> To: Janet P Gunn
> Cc: [email-masked]; Hilt, Volker (Volker)

---

From: <[email-masked]>
Date: Mon, 14 Jan 2013 18:08:36 +0000

I'm not really happy with the SHOULD. I think we are mixing two different things: priority and preservation. For example, a local policy that gives priority to BYE requests over any other request MUST always be honored even in case of severe overload. This does not imply that BYE requests MUST always be preserved; just that they MUST be given priority over other requests. 

I don't see any problem with using MUST for local policies that assign priorities to some requests. Use of MUST would of course be a problem if we were to define local policies about preserving some requests, but it's not what we are trying to do.

BC

> [email-masked]] De la part de DRAGE, Keith (Keith)
> Envoyé : lundi 14 janvier 2013 18:28
> À : Charles Shen; Janet P Gunn
> Cc : [email-masked]; Hilt, Volker (Volker)
> I'm not convinced we have got to the bottom of the requirement yet.
> Writing SHOULD is not an excuse for writing a poor requirement, yet
> that seems currently to be the excuse for wring SHOULD instead of MUST.
> Ideally I should still be able to still identify conformance or no
> conformance to a SHOULD requirement.
> 
> I suspect what we need to do is find a more specific requirement and
> then cover the rest of the problem in more informative text, rather
> than trying to address everything in a single requirement sentence.
> 
> I agree that if we end up writing a SHOULD, then there should be
> associated informative text that identifies the example circumstances
> for ignoring the SHOULD. That has long been an unwritten rule, and
> without it the SHOULD always gets interpreted as a MAY.
> 
> Regards
> 
> Keith
> 
> 
> > draft-ietf-soc- load-control-event-package-05.txt
> >
> > > If the Event package has set up an a-priori Overload  Control, and
> > > then
> > an
> > >> draft-ietf- soc-load-control-event-package-05.txt
> > >> "It is expected a SIP client will follow local policy as long as
> > >> the result is consistent with the SIP Overload Algorithm."
> > >>
> > >> >> Volker: Can either you or Janet please propose the exact
> > >> >> wordings to go into the modified text I proposed in [1]?  This
> > >> >> will avoid any guesswork and expedite the process of getting
> the drafts out.
> > >> >>
> > >> >> [1]

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 14 Jan 2013 12:17:38 -0600

On 01/14/2013 11:27 AM, DRAGE, Keith (Keith) wrote:
> that seems currently to be the excuse for wring SHOULD instead of
> MUST. Ideally I should still be able to still identify conformance or
> no conformance to a SHOULD requirement.
>

Keith: Do you have specific text you'd like to suggest?  Taking in
account Sal's view of staying away from local policies in conflict
and taking Janet's and Charles' suggestions, I have the following as a
cautionary paragraph before the normative text:

    It is expected that a SIP client will follow local policy as long as
    the results in reduction of traffic is consistent with the SIP
    overload algorithm in effect at that node.  Accordingly, the
    normative behaviour in the next three paragraphs should be
    interpreted with the understanding that the SIP client will aim to
    preserve local policy to the fullest extent possible.

And then we go down the three SHOULD paragraphs.

I believe that suggesting specific text will help close this gap more
expeditiously.

Is the above something that we can go with?

Thanks,

- vijay

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 15 Jan 2013 09:33:35 +0200

I do like the distinction between prioritization  and preservation,
maybe we need clearly distinguish the two cases in the draft

for prioritization a MUST could by reasonable indeed a statement like:
- "It *MUST* honor the local policy for *prioritizing* SIP requests..."
tell that the SIP element has to prioritize requests following the 
policy but has still the possibility to discard in case of severe overload

while for preserving a SHOULD seems to be more appropriate indeed a 
statement like this:
- "It *SHOULD* honor the local policy for *preserving* SIP requests..."
tell that SIP element will follow local policy as long as the result 
does not produce a severe overload (i.e. "the result is consistent with 
the SIP Overload Algorithm)

/Salvatore

---

From: Volker Hilt <[email-masked]>
Date: Tue, 15 Jan 2013 10:59:11 +0100

I think my general concern is that we are creating a MUST for something 
that we haven't even defined. I'm not sure what MUST means in this 
context. I think without such a specification SHOULD and some 
explanatory text seems appropriate.

Either way, let's try to close this one remaining issue and wrap up the 
draft.

Thanks,

Volker

On 15.01.2013 08:33, Salvatore Loreto wrote:
>> I'm not really happy with the SHOULD. I think we are mixing two
>> different things: priority and preservation. For example, a local
>> policy that gives priority to BYE requests over any other request MUST
>> always be honored even in case of severe overload. This does not imply
>> that BYE requests MUST always be preserved; just that they MUST be
>> given priority over other requests.
>>
>> I don't see any problem with using MUST for local policies that assign
>> priorities to some requests. Use of MUST would of course be a problem
>> if we were to define local policies about preserving some requests,
>> but it's not what we are trying to do.
>>
>> BC
>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law;
>> As emails may be altered, France Telecom - Orange is not liable for
>> messages that have been modified, changed or falsified.
>> Thank you.
>>

---

From: <[email-masked]>
Date: Tue, 15 Jan 2013 10:45:33 +0000

The problem I have with SHOULD is that it just means "RECOMMENDED". It implies that a server that handle all requests the same way despite a local policy giving priority to BYE requests can still claim conformance to the RFC.

So I would just replace SHOULD with MUST in the following text since it makes already clear that we are talking about prioritization, not preservation.

///

///

BC

> [email-masked]] De la part de Volker Hilt
> Envoyé : mardi 15 janvier 2013 10:59
> À : [email-masked]
> > does not produce a severe overload (i.e. "the result is consistent
> > with the SIP Overload Algorithm)
> >
> >
> > /Salvatore
> >
> >> policy that gives priority to BYE requests over any other request
> >> MUST always be honored even in case of severe overload. This does
> not
> >> imply that BYE requests MUST always be preserved; just that they
> MUST
> >> be given priority over other requests.
> >>
> >> I don't see any problem with using MUST for local policies that
> >> assign priorities to some requests. Use of MUST would of course be a
> >> problem if we were to define local policies about preserving some
> >> requests, but it's not what we are trying to do.
> >>
> >> BC
> >>
> >>> [email-masked]] De la part de DRAGE, Keith (Keith) Envoyé : lundi
> >>> 14 janvier 2013 18:28 À : Charles Shen; Janet P Gunn Cc :
> >>> [email-masked]; Hilt, Volker (Volker) Objet : Re:
> >>> [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-
> MUST.
> >>> associated informative text that identifies the example
> >>> circumstances for ignoring the SHOULD. That has long been an
> >>> unwritten rule, and without it the SHOULD always gets interpreted
> as a MAY.
> >>>
> >>> Regards
> >>>
> >>> Keith
> >>>
> >>>
> >>>> I am not in favor of opening up more cans of whatever at this
> stage
> >>>> :)
> >>>>
> >>>>> actual overload triggers a "feedback" Overload Control, how do
> >>>>> they interact?  The max? the min? the "product"
> >>>>>
> _____________________________________________________________________
> >> ____________________________________________________
> >>
> >>
> >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
> >> exploites ou copies sans autorisation. Si vous avez recu ce message
> >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi
> >> que les pieces jointes. Les messages electroniques etant
> susceptibles
> >> d'alteration, France Telecom - Orange decline toute responsabilite
> si
> >> ce message a ete altere, deforme ou falsifie. Merci.
> >>
> >> privileged information that may be protected by law; they should not
> >> be distributed, used or copied without authorisation.
> >> If you have received this email in error, please notify the sender
> >> and delete this message and its attachments.

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Jan 2013 16:21:37 +0200

we have been discussing this issue (i.e. SHOULD vs MUST) over the last 
couple of weeks or even more.
THE result is that an explanatory text is the key thing to have either way
because of the different views on what a policy can and cannot be.

having said that,
my reading is that there is a large preference to use  SHOULD
with the explanatory text proposed by Vijay below

Salvatore

On 1/14/13 8:17 PM, Vijay K. Gurbani wrote:

[snip]

---

From: Volker Hilt <[email-masked]>
Date: Mon, 21 Jan 2013 15:22:34 +0100

Fine with me.

Volker

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 28 Jan 2013 15:53:09 +0200

as co-chair I declare formal consensus on the SHOULD option

the authors of the draft event-package and overload-control are invited 
to update their draft
to reflect the decision

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Charles Shen <[email-masked]>
Date: Tue, 29 Jan 2013 10:29:21 -0500

Dear Vijay, I just want to make sure I include the exact texts that
have been finally agreed on.  Could you please post the complete
version of the final texts on this issue again, and I will update the
event package draft right away.

Thanks!

Charles

On Mon, Jan 28, 2013 at 8:53 AM, Salvatore Loreto
<[email-masked]> wrote:
> the authors of the draft event-package and overload-control are invited to
> update their draft
> to reflect the decision
>
> best regards
> Salvatore
>
>