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

[Charles Shen <[e-mail]>]

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)
<[e-mail]> 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
>
>
>
> ________________________________
>
> 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]> 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]] De
> la part de Charles Shen
> Envoyé : samedi 15 décembre 2012 16:06
> À : Janet P Gunn
> Cc : NOEL, ERIC (ERIC C); [e-mail];
> [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]> 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]>
> To:        "'Charles Shen'" <[e-mail]>du>,
> "[e-mail]" <[e-mail]>
> Cc:        Arata Koike <[e-mail]>jp>, Henning Schulzrinne
> <[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]
>
> ________________________________
>
>
>
>
> 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
> [e-mail]
>
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Charles Shen
> Sent: Monday, October 22, 2012 12:47 PM
> To: [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]> 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]
> https://www.ietf.org/mailman/listinfo/sip-overload
>  _______________________________________________
> sip-overload mailing list
> [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.
>