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

["DRAGE, Keith (Keith)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Janet P Gunn
Sent: 31 December 2012 17:17
To: Charles Shen
Cc: [e-mail]; [e-mail]; 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


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 <[e-mail]>
To:        [e-mail]
Cc:        Janet P Gunn/USA/CSC@CSC, "NOEL, ERIC (ERIC C)" <[e-mail]>om>, "[e-mail]" <[e-mail]>rg>, "[e-mail]" <[e-mail]>rg>, Arata Koike <[e-mail]>jp>, Henning Schulzrinne <[e-mail]>
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:        [e-mail]
________________________________



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, <[e-mail]<mailto:[e-mail]>> 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 : [e-mail]<mailto:[e-mail]> [mailto:[e-mail]<mailto:[e-mail]>] De la part de Charles Shen
Envoyé : samedi 15 décembre 2012 16:06
À : Janet P Gunn
Cc : NOEL, ERIC (ERIC C); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; 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 <[e-mail]<mailto:[e-mail]>> 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)" <[e-mail]<mailto:[e-mail]>>
To:        "'Charles Shen'" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Cc:        Arata Koike <[e-mail]<mailto:[e-mail]>>, Henning Schulzrinne <[e-mail]<mailto:[e-mail]>>
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:        [e-mail]<mailto:[e-mail]>

________________________________



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:[phone]>
[e-mail]<mailto:[e-mail]>

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Charles Shen
Sent: Monday, October 22, 2012 12:47 PM
To: [e-mail]<mailto:[e-mail]>
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, <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/sip-overload
 _______________________________________________
sip-overload mailing list
[e-mail]<mailto:[e-mail]>
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.