From bruno.chatras@orange.com Wed Aug 1 01:31:52 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5961F21F8671 for ; Wed, 1 Aug 2012 01:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sWJQ95euYG89 for ; Wed, 1 Aug 2012 01:31:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C421F866B for ; Wed, 1 Aug 2012 01:31:51 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2D6FF264518; Wed, 1 Aug 2012 10:31:50 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 0A7C435C045; Wed, 1 Aug 2012 10:31:50 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 10:31:49 +0200 From: To: Adam Roach , "draft-ietf-soc-load-control-event-package@tools.ietf.org" Thread-Topic: [sip-overload] Comments on SOC Event Package Thread-Index: AQHNbniVvS6tq17eJU+omQ7bHlymbpdEoMzg Date: Wed, 1 Aug 2012 08:31:49 +0000 Message-ID: <3484_1343809910_5018E976_3484_3511_1_88CAD1D4E8773F42858B58CAA28272A00680EA@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5016C3F1.4060709@nostrum.com> In-Reply-To: <5016C3F1.4060709@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A00680EAPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.1.71520 Cc: "SOC \(SIP Overload Control\) WG" Subject: Re: [sip-overload] Comments on SOC Event Package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 08:31:52 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A00680EAPEXCVZYM12corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly = we can cite an international specification for the discussion of call gappi= ng -- doesn't Q.1248 cover this?. [BC] As far as Intelligent Networks are concerned, this is covered in Q.124= 8.2 (CallGap and CallFiltering procedures). Despite its name, the first pro= cedure is for gapping service requests towards IN services (e.g. 800 servic= es), the second procedure enables switch-based call filtering (to any dest= ination, not just IN services) to be configured by an IN server. PSTN cong= estion control is addressed in E.412. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_88CAD1D4E8773F42858B58CAA28272A00680EAPEXCVZYM12corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Finally, I note that we cite GR= -2938-CORE at the top of page 24. Certainly we can cite an international sp= ecification for the discussion of call gapping -- doesn't Q.1248 cover this?.

[BC] As far as Intel= ligent Networks are concerned, this is covered in Q.1248.2 (CallGap and Cal= lFiltering procedures). Despite its name, the first procedure is for gappin= g service requests towards IN services (e.g. 800 services), the second procedure enables switch-based  call = filtering (to any destination, not just IN services) to be configured by an= IN server.  PSTN congestion control is addressed in E.412.

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_88CAD1D4E8773F42858B58CAA28272A00680EAPEXCVZYM12corpora_-- From jgunn6@csc.com Wed Aug 1 02:06:16 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18DB21F8549 for ; Wed, 1 Aug 2012 02:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_43=0.6, MIME_BAD_LINEBREAK=0.5, MIME_HTML_ONLY=1.457, OBFUSCATING_COMMENT=0.973, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0U7sYI4Oqd16 for ; Wed, 1 Aug 2012 02:06:15 -0700 (PDT) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id 30EBC21F8569 for ; Wed, 1 Aug 2012 02:06:15 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-171.messagelabs.com!1343811973!6924731!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31388 invoked from network); 1 Aug 2012 09:06:14 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-13.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Aug 2012 09:06:14 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q7195WMb006743 for ; Wed, 1 Aug 2012 05:06:10 -0400 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , , <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> From: Janet P Gunn To: keith.drage@alcatel-lucent.com Message-ID: Date: Wed, 1 Aug 2012 05:06:07 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.2FP3 July 10, 2011 X-MIMETrack: Serialize by Notes Server on AMER-ML22/SRV/CSC(Release 8.5.2FP3|July 10, 2011) at 08/01/2012 05:06:07, Serialize complete at 08/01/2012 05:06:07, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/01/2012 05:02:16 AM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: charles@cs.columbia.edu, shen@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 09:06:16 -0000
Sounds good to me. Is "Recorder tone" defined there?
=0D =0D
Janet

-----"DRAGE, Keit= h (Keith)" <keith.drage@alcatel-lucent.com> wrote: ----- =0D
=0D
To: Janet P= Gunn/USA/CSC@CSC, "charles@cs.columbia.edu" <charles@cs.columbia.edu>= ;
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>Date: 07/30/2012 06:19PM
Cc: "sip-overload@ietf.org" <sip-overload@i= etf.org>, "shen@att.com" <shen@att.com>
Subject: RE: [sip-overl= oad] Alignment of priority and emergency call handling

=0D
=0D

Can I suggest that we stick to the terminology available in ITU-T Recommendation E.182 (and E.180) as this U.S. ter= minology is very specific to the U.S. and other terms = are used elsewhere in world.

=0D

 

=0D=

Keith

=0D

&n= bsp;

=0D
=0D
=0D
=0D
=0D
=0D

From: sip-overlo= ad-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: 30 July 2012 23:03
To: charles@cs.columbia.edu
Cc: sip-overload@ietf.org; shen@at= t.com
Subject: Re: [sip-= overload] Alignment of priority and emergency call handling

=0D

&nbs= p;

=0D
=0D

Thanks

=0D
=0D

&= nbsp;

=0D
=0D

WRT the last comment - "Reorder tone" is also known (at least in the = US) as "fast busy".

=0D=0D

I agree that there might be "announcement= s"

=0D
=0D

but I do not know what you mean by "Recorder tone". Do you mean the tone= that sometimes comes on just BEFORE an announcement?

=0D
=0D

=  

=0D
=0D

Janet

=0D
=0D


-----charles.newyork@gmail= .com wrote: -----

=0D
= =0D
=0D

To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: charles.newyork@gmail.com
Date: 07/29/2012 = 11:35PM
Cc: vkg@bell-labs.com, sip-overload@ietf.org, shen@att.com
Su= bject: Re: [sip-overload] Alignment of priority and emergency call handling=

Hi Janet, thank you very much fo= r your detailed comments! I've
incorporated them in the new revision. Al= so please see response
inline.

On Sun, Jul 29, 2012 at 5:49 PM, J= anet P Gunn <jgunn6@csc.com> wrote:
> I agree with Keith's comm= ents about priority and emergency calls.
>

done

> I = also have a number of other comments, mostly editorial (I apologize for my<= BR>> lateness in responding).
>
>
> Introduction shoul= d stress that this approach is for situations where you
> can predict= , in advance, a likely traffic surge,
> and its source/destination di= stribution.  For instance, it is appropriate
> for a mass-phone-= voting event, Mother's Day, New
> Years, and even a hurricane (there = is usually some advance notice).
> However, it is less likely to be e= ffective for the initial phase of
> unpredicted/unpredictable mass ca= lling events, such as
> earthquakes or terrorist attacks.  In th= ese latter cases, the local traffic
> load may peak by more than an o= rder of magnitude
> in minutes, if not seconds.  This does not a= llow time to either
> effectively identify the filters needed, nor di= stribute then to the
> appropriate servers, soon enough to prevent co= ngestion
> attack.  Once other, more immediate, techniques (such= as the loss-based or
> rate-based  methods) have prevented the = initial
> congestion collapse, the event package can be used to effec= tively control
> the continuing overload.
> --

agree.
> This sentence
>  Load filtering works best if it preve= nts calls as close to
>  the user agent clients as possible.
= > could be clarified by including the word "originating"
>  L= oad filtering works best if it prevents calls as close to
>  the= originating user agent clients as possible.
> --

right
> There appears to be a cut and past error here
> Secondly, since= we are describing a specific control
>    mechanism based = on filtering, the term "load control" in this
>    specific= ation is used inter-changeably with the term "load filtering"
>  = ;  unless when associated with other explicit context.
> I suspe= ct it is supposed to be
> Secondly, since we are describing a specifi= c control
>    mechanism based on filtering, the term "load= control" in this
>    specification is used inter-changeab= ly with the term "load filtering"
>    unless associated wi= th other explicit context.
> --
>

right

> I am= not sure I understand this statement
> This
>    spe= cification, however, does not preclude the load control document
> &n= bsp;  defined here (Section 6) to be extended in the future for other = forms
>    of control as appropriate.
> What sorts of= "other forms of control" are you referring to?  Presumably not
>= ; service level and QoS control, as you have
> already defined them (= or at least referred to them) as "load control" but
> not "overload c= ontrol".
> --

Yes, it could be confusing, so I removed this se= ntence.

>  Section 3
> I think that
> For destin= ation-specific overload situations, the load filter
>     &= nbsp; needs to be able to describe the callee.
> should be
> Fo= r destination-specific overload situations, the load filter
>   =     should be able to specify the callee.
> --

agree= .

> This bullet
>  To address accidental and intention= al high-volume call generators,
>       the load filte= r should allow to specify the caller.
> does not use correct grammar.=
> I suspect you mean
>  To address accidental and intenti= onal high-volume call generators,
>       the load fil= ter should be able to  specify the caller.
> --

agree
=
> With regard to this bullet,
>    o  For telep= hone numbers, it should be possible to specify prefixes
>   &nbs= p;   which allow control over limited regionally-focused overloads.> This is really an assumption rather than a requirement.
> Furth= ermore, I do not believe it is true.  In these days of number
> = portability, and people retaining their original mobile
> phone numbe= r, as their primary number, when they move across the country,
> the = correlation between "telephone number prefix"
> (aka area code) and "= physical location" is rapidly decreasing.
> I agree that,for regional= calling events, you need a way of identifying the
> geographical loc= ation (originating and/or
> terminating) to determine which calls to = filter.  But I do not think that
> area codes will continue to b= e the most effective
> way of doing this.
> Perhaps an alternat= e wording would be
>    o  It should be possible to sp= ecify particular information in the SIP
> headers (e.g., prefixes in = telephone numbers)
>       which allow control over li= mited regionally-focused overloads
> ---

agree

> sec= 4.2
>  in this statement
>  and that loads are alloc= ated in a way which
>    both prevents overload and minimiz= es the likelihood of network
>    resource under-utilizatio= n.
> would it be better to say "maximizes effective throughput(aka go= odput)"
> instead of "minimizes the likelihood of network
> &nb= sp;  resource under-utilization."?
> ---

agree

>= ; sec 4.3
>
> Should this
> In order for load filters to = be properly distributed, each SIP proxy
>    server in the = network is required to subscribe to the load control
>    e= vent package from all its outgoing signaling neighbors, known as
> &n= bsp;  notifiers (Section 5.6).
> be
> In order for load fi= lters to be properly distributed, each SIP proxy
>    serve= r in the network SHOULD subscribe to the load control
>    = event package from all its outgoing signaling neighbors, known as
> &= nbsp;  notifiers (Section 5.6).
> ? (not sure myself)
>> ---

agree.

> For case II, perhaps "hurricane" (which= has a more predictable, and more
> gradual, increase in traffic) wou= ld be a better
> example than "earthquake", due to the issues mention= ed above.
> --
> Sec 5.3
> In sec 4.4 you say
> Ano= ther important aspect that affects the applicability of SIP load
> &n= bsp;  filtering is that all possible signaling source neighbors need t= o
>    participate and enforce the designated filter.  = ;Otherwise, a single
>    non-conforming neighbor could mak= e the whole control efforts useless
>    by pumping in exce= ssive traffic to overload the server.
> But in section 5.3 you say> a subscriber may be interested in some
>    specific = types of load control policy only.
> Maybe I am misunderstanding what= you mean by "types of load control policy",
> but the statement in 5= .3 ("only interested in
> some") seem inconsistent with the statement= in 4.3 ("all must participate").
> Perhaps you could add a clarifyin= g statement.
> ---

Since the details of the subscription filte= r specification are not
defined anyway, I removed this "For example" sen= tence to avoid the
confusion.


> 5.8
> Modifications = of existing load
>    control policies at the subscriber is= performed after directly
>    receiving notifications cont= aining updated load control policies.
> Grammar
> either
>= ; ... modifications ... are ...
> or
> ...modification ...is ..= .
> but NOT
> ... modifications ... is ...
> ---

r= ight

> 5.11
> This sentence
> "Another factor usually= not known precisely or is
>    computed automatically is t= he validity duration of the load control
>    event."
&g= t; Seems to be a cut and paste error of some sort.
> ...

Chang= ed to "  Another factor that is usually not known precisely or
need= s to be computed automatically is the validity duration of the
load cont= rol event.  "

> 8.1
> Should this
> "... adminis= trative option for routing failed
>    call attempts to eit= her Recorder Tone or a special announcement...."
> be "Reorder Tone" = instead of "Recorder Tone"?
>
>

I think this is somethin= g like a recording machine playing something
message, am I correct?
<= BR>thanks

Charles


> Janet
>
>
>
&= gt; -----sip-overload-bounces@ietf.org wrote: -----
>
> To: sip= -overload@ietf.org
> From: "Vijay K. Gurbani"
> Sent by: sip-ov= erload-bounces@ietf.org
> Date: 07/26/2012 12:03PM
> Cc: shen@a= tt.com
>
> Subject: Re: [sip-overload] Alignment of priority an= d emergency call
> handling
>
> On 07/26/2012 10:23 AM, D= RAGE, Keith (Keith) wrote:
>> I do not believe you need to include= other artifacts.
>>
>> Rather overload-control lists bot= h RPH and sos URN, and the event
>> package lists only RPH.
>= ;
> So it is a simple matter of ensuring that the text in
> dra= ft-ietf-soc-load-control-event-package is consistent with the
> text = in draft-ietf-soc-overload-control?
>
> If so, Charles --- can = you please take care of this in
> draft-ietf-soc-load-control-event-p= ackage?
>
> 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} / vijay.gurbani@alcatel-lucent.com
> We= b:   http://ect.bell-lab= s.com/who/vkg/
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> sip-overload mailing list
&= gt; sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>
>
> This is a PRIVATE message. If you are not= the intended recipient, please
> delete without copying and kindly a= dvise 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
> agreem= ent or government initiative expressly permitting the use of e-mail
>= for such purpose.
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F
> sip-overload mailing list
> sip-overload@i= etf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>

=0D



<= SPAN style=3D"FONT-FAMILY: Verdana; FONT-SIZE: 6pt">This is a PRIVATE messa= ge. If you are not the intended recipient, please delete without copying an= d kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless o= f content, this e-mail shall not operate to bind CSC to any order= or other contract unless pursuant to explicit written agreement or governm= ent initiative expressly permitting the use of e-mail for such purpose.



This is a PRIVATE message. If you are not the in= tended recipient, please delete without copying and kindly advise us by e-m= ail of the mistake in delivery. NOTE: Regardless of content, this e-mail sh= all 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 bruno.chatras@orange.com Wed Aug 1 07:56:38 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D261511E80DC for ; Wed, 1 Aug 2012 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.293 X-Spam-Level: X-Spam-Status: No, score=-1.293 tagged_above=-999 required=5 tests=[AWL=-0.995, BAYES_00=-2.599, MANGLED_PAIN=2.3, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W8Rvsg0kOuO for ; Wed, 1 Aug 2012 07:56:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 68DF411E8097 for ; Wed, 1 Aug 2012 07:56:36 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 51A5D2DC1BA; Wed, 1 Aug 2012 16:56:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 2C52A4C06F; Wed, 1 Aug 2012 16:56:35 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 1 Aug 2012 16:56:34 +0200 From: To: Charles Shen Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package Thread-Index: AQHNbgBnTkHRGiuzQUa9FJtv08a8R5dFB4dw Date: Wed, 1 Aug 2012 14:56:33 +0000 Message-ID: <23338_1343832995_501943A3_23338_11382_1_88CAD1D4E8773F42858B58CAA28272A0068486@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.1.110315 Cc: Volker Hilt , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 14:56:38 -0000 SGkgQ2hhcmxlcywNCg0KIlJvdXRlIiBtYXkgYmUgYSBiaXQgbWlzbGVhZGluZyBhcyB0aGUgbWF0 Y2hpbmcgc2hvdWxkIGJlIHBlcmZvcm1lZCBvbiB0aGUgaWRlbnRpdHkgb3IgYWRkcmVzcyBvYnRh aW5lZCBhZnRlciBhcHBseWluZyBSRkMzMjYzIHByb2NlZHVyZXMgdG8gdGhlIGZpcnN0IHZhbHVl IG9mIHRoZSByb3V0ZSBoZWFkZXIgb3IgdG8gdGhlIFItVVJJIHJhdGhlciB0aGFuIG9uIHRoZSBj b250ZW50cyB0aGUgcm91dGUgaGVhZGVyIGFzIHN1Y2guDQoNCkJDDQoNCg0KPiAtLS0tLU1lc3Nh Z2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogY2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbSBbbWFp bHRvOmNoYXJsZXMubmV3eW9ya0BnbWFpbC5jb21dIERlIGxhDQo+IHBhcnQgZGUgQ2hhcmxlcyBT aGVuDQo+IEVudm95w6nCoDogbHVuZGkgMzAganVpbGxldCAyMDEyIDA1OjA3DQo+IMOAwqA6IENI QVRSQVMgQnJ1bm8gUkQtQ09SRQ0KPiBDY8KgOiBTYWx2YXRvcmUgTG9yZXRvOyBzaXAtb3Zlcmxv YWRAaWV0Zi5vcmc7IFZvbGtlciBIaWx0OyBIZW5uaW5nDQo+IFNjaHVsenJpbm5lOyBBcmF0YSBL b2lrZQ0KPiBPYmpldMKgOiBSZTogW3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mt b2xvYWQtY29udHJvbC1ldmVudC0NCj4gcGFja2FnZQ0KPiANCj4gSGkgQnJ1bm8sIHNvcnJ5IGZv ciB0aGUgZGVsYXllZCByZXNwb25zZSENCj4gDQo+IEkndmUgdXBkYXRlZCB0aGUgbG9jYWwgbnVt YmVyIGdyb3VwaW5nIHRleHQuIEZvciB0aGUgbXVsdGktcGF0aA0KPiBmaWx0ZXJpbmcgcG9saWN5 IHByb2JsZW0sIHNpbmNlIGl0IHdpbGwgYWZmZWN0IHRleHRzIGluIG11bHRpcGxlDQo+IHNlY3Rp b25zLCBJJ2QgbGlrZSB0byBkaXNjdXNzIGEgYml0IG1vcmUgaW4gdGVybXMgb2YgdGhlIHNvbHV0 aW9uLg0KPiANCj4gQXNzdW1pbmcgdGhlIGZvbGxvd2luZyBzY2VuYXJpbywNCj4gDQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQM0ENCj4gYWxpY2VAcDEgLS0tIFAxIC0t LSBQMiAtLSAvICAgICAgIFwgLS0tIFA0IC0tLSBib2JAcDQNCj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgXCAgICAgIC8NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFAzQg0KPiANCj4gd2hlcmUgUDIgY2FuIHJlYWNoIGJvYiB0aHJvdWdoIGVpdGhl ciBQM0Egb3IgUDNCLCB0aGUgY2FsbCBpZGVudGl0eSBpbg0KPiB0aGUgZXhpc3RpbmcgcG9saWN5 IGRvZXMgbm90IGRpc3Rpbmd1aXNoIHRoZSBjYWxscyB0byBib2JAcDQgdGhyb3VnaA0KPiBQM0Eg ZnJvbSB0aG9zZSB0aHJvdWdoIFAzQi4gVGhlcmVmb3JlIGl0IHdvdWxkIGJlIGdvb2QgZm9yIHRo ZSBsb2FkDQo+IGNvbnRyb2wNCj4gcG9saWN5IHRvIGluY2x1ZGUgbm90IG9ubHkgdGhlIGNhbGwg ZGVzdGluYXRpb24gKGUuZy4sIGJvYkBwNCBpbg0KPiB0aGlzIGNhc2UpLCBidXQgYWxzbyB0aHJv dWdoIHdoaWNoIHBhdGggdGhlIGNhbGwgaXMgcm91dGVkLg0KPiANCj4gT25lIHBvc3NpYmxlIHNv bHV0aW9uIGNvdWxkIGJlIHRvIGFkZCBhIG5ldyBzdWItZWxlbWVudCBjYWxsZWQNCj4gPHJvdXRl PiB1bmRlciB0aGUgZXhpc3RpbmcgPGNhbGwtaWRlbnRpdHk+IHNjaGVtYS4gSW4gdGhlIHNpbXBs ZSBjYXNlLA0KPiB0aGUgbmV3IDxyb3V0ZT4gZWxlbWVudCBjYW4gYmUgb2YgdGhlIHNhbWUgdHlw ZSBhcyB0aGUgPGlkZW50aXR5Pg0KPiBlbGVtZW50IGluIFtSRkM0NzQ1XS4gVGhlIGNvbnRlbnRz IG9mIHRoZSA8cm91dGU+IGVsZW1lbnQgaG9sZHMgd2hhdA0KPiB5b3UgY2FsbCB0YXJnZXQgU0lQ IGVudGl0aWVzLg0KPiANCj4gVXNpbmcgdGhlIHNhbWUgZXhhbXBsZSBhYm92ZSwgc2VydmVyIFAx IG1heSByZWNlaXZlIGEgcG9saWN5DQo+IGNvbnRhaW5pbmcgdGhlIG5ldyBlbGVtZW50IGFzIGJl bG93Og0KPiANCj4gPGNhbGwtaWRlbnRpdHk+DQo+ICAgICA8c2lwPg0KPiAgICAgICAgIDx0bz4N Cj4gICAgICAgICAgICAgPG9uZSBpZD0ic2lwOmJvYkBwNC5leGFtcGxlLmNvbSI+DQo+ICAgICAg ICAgPC90bz4NCj4gICAgICAgICA8cm91dGU+DQo+ICAgICAgICAgICAgIDxtYW55IGRvbWFpbj0i cDIuZXhhbXBsZS5jb20iPg0KPiAgICAgICAgICAgICA8bWFueSBkb21haW49InAzYS5leGFtcGxl LmNvbSI+DQo+ICAgICAgICAgICAgIDxtYW55IGRvbWFpbj0icDQuZXhhbXBsZS5jb20iPg0KPiAg ICAgICAgIDwvcm91dGU+DQo+ICAgICA8L3NpcD4NCj4gPC9jYWxsLWlkZW50aXR5Pg0KPiANCj4g DQo+IFNpbWlsYXJseSBzZXJ2ZXIgUDIgbWF5IHJlY2VpdmUgYSBwb2xpY3kgY29udGFpbmluZyB0 aGUgbmV3IGVsZW1lbnQgYXMNCj4gYmVsb3c6DQo+IA0KPiA8Y2FsbC1pZGVudGl0eT4NCj4gICAg IDxzaXA+DQo+ICAgICAgICAgPHRvPg0KPiAgICAgICAgICAgICA8b25lIGlkPSJzaXA6Ym9iQHA0 LmV4YW1wbGUuY29tIj4NCj4gICAgICAgICA8L3RvPg0KPiAgICAgICAgIDxyb3V0ZT4NCj4gICAg ICAgICAgICAgPG1hbnkgZG9tYWluPSJwM2EuZXhhbXBsZS5jb20iPg0KPiAgICAgICAgICAgICA8 bWFueSBkb21haW49InA0LmV4YW1wbGUuY29tIj4NCj4gICAgICAgICA8L3JvdXRlPg0KPiAgICAg PC9zaXA+DQo+IDwvY2FsbC1pZGVudGl0eT4NCj4gDQo+IA0KPiBUaGVuIHRoZSBjYWxsIGZpbHRl cmluZyBjYW4gbWF0Y2ggYm90aCB0aGUgY2FsbCBkZXN0aW5hdGlvbiBhbmQgdGhlDQo+IHBhdGgg KGFzc3VtaW5nIGVpdGhlciBhIFNJUCBSb3V0ZSBoZWFkZXIgaXMgaW5jbHVkZWQsIG9yIGEgbmV4 dCBob3ANCj4gU0lQIHNlcnZlciBpcyBjaG9zZW4gZHluYW1pY2FsbHkpLg0KPiANCj4gVGhlcmUg aXMgc3RpbGwgYSBzbWFsbCBwcm9ibGVtIHRob3VnaCAtIGlmIHRoZSBuZXcgPHJvdXRlPiBlbGVt ZW50IGlzDQo+IGRlZmluZWQgYXMgb25lIG9mIDxpZGVudGl0eT4gZWxlbWVudCBpbiBSRkM0NzQ1 LCB0aGVuIHRoZSA8bWFueT4NCj4gc3ViLWVsZW1lbnRzIHVuZGVyIGl0IGFyZSBub3Qgb3JkZXJl ZCwgd2hpbGUgaGVyZSB3ZSBzZWVtIHRvIG5lZWQgYW4NCj4gb3JkZXJlZCBsaXN0IChhcyBpbiB0 aGUgbGlzdCBvZiBTSVAgUm91dGUgaGVhZGVycykuIFRoZXJlZm9yZSwgd2UNCj4gbWlnaHQgaGF2 ZSB0byBkZWZpbmUgbmV3IHJ1bGVzIGZvciB0aGUgPHJvdXRlPiBlbGVtZW50IHRvIG1ha2UgaXRz DQo+IHN1Yi1lbGVtZW50cyBvcmRlcmVkLg0KPiANCj4gQW55IHRob3VnaHRzPw0KPiANCj4gQ2hh cmxlcw0KPiANCj4gDQo+IA0KPiANCj4gDQo+IE9uIFR1ZSwgSnVsIDE3LCAyMDEyIGF0IDE6MDcg UE0sICA8YnJ1bm8uY2hhdHJhc0BvcmFuZ2UuY29tPiB3cm90ZToNCj4gPiBIaSBDaGFybGVzLA0K PiA+DQo+ID4gU2VlIGJlbG93Lg0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiA+PiBEZSA6IGNoYXJsZXMubmV3eW9ya0BnbWFpbC5jb20gW21haWx0bzpjaGFybGVzLm5l d3lvcmtAZ21haWwuY29tXSBEZQ0KPiBsYQ0KPiA+PiBwYXJ0IGRlIENoYXJsZXMgU2hlbg0KPiA+ PiBFbnZvecOpIDogbWFyZGkgMTcganVpbGxldCAyMDEyIDE4OjM3DQo+ID4+IMOAIDogQ0hBVFJB UyBCcnVubyBSRC1DT1JFDQo+ID4+IENjIDogU2FsdmF0b3JlIExvcmV0bzsgc2lwLW92ZXJsb2Fk QGlldGYub3JnOyBWb2xrZXIgSGlsdDsgSGVubmluZw0KPiA+PiBTY2h1bHpyaW5uZTsgQXJhdGEg S29pa2UNCj4gPj4gT2JqZXQgOiBSZTogW3NpcC1vdmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1z b2Mtb2xvYWQtY29udHJvbC1ldmVudC0NCj4gPj4gcGFja2FnZQ0KPiA+Pg0KPiA+PiBIaSBCcnVu bywgdGhhbmsgeW91IHNvIG11Y2ggZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRz IQ0KPiBJJ3ZlDQo+ID4+IGFkZHJlc3NlZCA4IG91dCBvZiB0aGUgdG90YWwgMTAsIGV4Y2VwdCB0 aGUgZm9sbG93aW5nIHR3byB3aGljaCBJJ2QNCj4gPj4gYXBwcmVjaWF0ZSBtb3JlIGNsYXJpZmlj YXRpb24uDQo+ID4+DQo+ID4+ID4gMikgU2VjdGlvbiA1LjgsIGxpbmUgNTI1LTUyOA0KPiA+PiA+ DQo+ID4+ID4gVGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0cyB0aGF0IGluY29taW5nIHJlcXVlc3Rz IGFyZSBmaWx0ZXJlZA0KPiA+PiBpcnJlc3BlY3RpdmUgb2YgdGhlaXIgYWN0dWFsIGRlc3RpbmF0 aW9uLiBUaGUgc3Vic2NyaWJlciBzaG91bGQNCj4gcmF0aGVyDQo+ID4+IGFwcGx5IGZpbHRlcnMg b24gcmVxdWVzdHMgdGhhdCBhcmUgb3V0Z29pbmcgdG8gdGhlIHByZS1vdmVybG9hZGVkDQo+ID4+ IGRlc3RpbmF0aW9uLiBPbmUgc29sdXRpb24gd291bGQgYmUgdG8gcmVwaHJhc2UgdGhlIGZvbGxv d2luZyB0ZXh0Og0KPiA+PiA+DQo+ID4+ID4gIkEgc3Vic2NyaWJlciByZWNlaXZpbmcgdGhlIG5v dGlmaWNhdGlvbiBmaXJzdCBpbnN0YWxscyB0aGVzZSBydWxlcw0KPiA+PiBhbmQgdGhlbiBmaWx0 ZXIgaW5jb21pbmcgcmVxdWVzdHMgdG8gZW5mb3JjZSBhY3Rpb25zIG9uIGFwcHJvcHJpYXRlDQo+ ID4+IHJlcXVlc3RzLCBmb3IgZXhhbXBsZSwgbGltaXRpbmcgdGhlIHNlbmRpbmcgcmF0ZSBvZiBj YWxsIHJlcXVlc3RzDQo+ID4+IGRlc3RpbmVkIGZvciBhIHNwZWNpZmljIFNJUCBlbnRpdHkuIg0K PiA+PiA+DQo+ID4+ID4gV2l0aA0KPiA+PiA+DQo+ID4+ID4gIkEgc3Vic2NyaWJlciByZWNlaXZp bmcgdGhlIG5vdGlmaWNhdGlvbiBmaXJzdCBpbnN0YWxscyB0aGVzZSBydWxlcw0KPiA+PiBhbmQg dGhlbiBmaWx0ZXIgb3V0Z29pbmcgcmVxdWVzdHMgdG93YXJkcyB0aGUgbm90aWZpZXIgdG8gZW5m b3JjZQ0KPiA+PiBhY3Rpb25zIG9uIGFwcHJvcHJpYXRlIHJlcXVlc3RzLCBmb3IgZXhhbXBsZSwg bGltaXRpbmcgdGhlIHNlbmRpbmcNCj4gcmF0ZQ0KPiA+PiBvZiBjYWxsIHJlcXVlc3RzIGRlc3Rp bmVkIGZvciBhIHNwZWNpZmljIFNJUCBlbnRpdHkuIg0KPiA+PiA+DQo+ID4+ID4gVGhpcyB3b3Vs ZCBob3dldmVyIG5vdCBwZXJtaXQgdGhlIHVzZSBvZiBleHRlcm5hbCBzdGF0ZSBhZ2VudHMgYXMN Cj4gPj4gZGVzY3JpYmVkIGluIHNlY3Rpb24gNS4xMi4gVGhlcmVmb3JlIGl0IHNlZW1zIHRoYXQg YSAidGFyZ2V0IHNpcA0KPiBlbnRpdHkiDQo+ID4+IHBhcmFtZXRlciBzaG91bGQgYmUgYWRkZWQg dG8gb3ZlcmxvYWQgY29udHJvbCBkb2N1bWVudHMuDQo+ID4+ID4NCj4gPj4NCj4gPj4gSSB0aGlu ayBJIG1pZ2h0IGhhdmUgbm90IHVuZGVyc3Rvb2QgeW91ciBwb2ludC4gVGhlIHJlcXVlc3RzIGFy ZQ0KPiA+PiBmaWx0ZXJlZCBiYXNlZCBvbiB0aGUgY2FsbCBpZGVudGl0aWVzLCB3aGljaCBjYW4g Y29udmV5IGluZm9ybWF0aW9uDQo+ID4+IGluY2x1ZGluZyB0aGUgY2FsbCBkZXN0aW5hdGlvbi4g Q291bGQgeW91IGVsYWJvcmF0ZSB3aGF0IHRoaXMgInRhcmdldA0KPiA+PiBzaXAgZW50aXR5IiBp cyBleGFjdGx5IGZvcj8NCj4gPiBbQkNdDQo+ID4NCj4gPiBMZXQncyB0YWtlIHR3byBleGFtcGxl cyB0aGF0IEkgdGhpbmsgYXJlIG5vdCBjb3ZlcmVkIGJ5IHRoZSBjdXJyZW50DQo+IHdvcmRpbmcu DQo+ID4NCj4gPiAxKSBFeGFtcGxlIDENCj4gPg0KPiA+IENhbGwgY29uZmlndXJhdGlvbjogQSBp cyBjb25uZWN0ZWQgc28gU1AxLCBCIGlzIGNvbm5lY3RlZCB0byBTUDIuIFNQMQ0KPiBhbmQgU1Ay IGFyZSBjb25uZWN0ZWQgdmlhIFNQMy4gU1AzIGlzIGNvbm5lY3RlZCB0byBhbiBBcHBsaWNhdGlv biBTZXJ2ZXINCj4gKEFTKS4gVW5kZXIgbm9ybWFsIGxvYWQgY29uZGl0aW9ucywgYSBjYWxsIGZy b20gQSB0byBCIGlzIHJvdXRlZCBhbG9uZw0KPiB0aGUgZm9sbG93aW5nIHBhdGg6IEEtU1AxLVNQ My1BUy1TUDItQi4gVGhlIEFTIHByb3ZpZGVzIGEgbm9uLWVzc2VudGlhbA0KPiBzZXJ2aWNlIGFu ZCBjYW4gYmUgYnlwYXNzZWQgaW4gY2FzZSBvZiBvdmVybG9hZC4NCj4gPg0KPiA+IE5vdyBsZXQn cyBhc3N1bWUgdGhhdCBBUyBpcyBvdmVybG9hZGVkIGFuZCBzZW5kcyB0byBTUDMgYSBmaWx0ZXIN Cj4gcmVxdWVzdGluZyB0aGF0IDUwJSBvZiBJTlZJVEUgbWVzc2FnZXMgYmUgZHJvcHBlZCwgcmVn YXJkbGVzcyBvZiB0aGUNCj4gY29udGVudHMgb2YgdGhlIGZyb20vdG8vUEFJL1ItVVJJLg0KPiA+ DQo+ID4gQWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IHdvcmRpbmcsIFNQMyB3aWxsIGluZGVlZCBm aWx0ZXIgNTAlIG9mIHRoZQ0KPiBJTlZJVEUgcmVxdWVzdHMgd2hpbGUgdGhleSBjb3VsZCBiZSBy b3V0ZWQgdG8gQiB2aWEgU1AyLg0KPiA+DQo+ID4gMikgRXhhbXBsZSAyDQo+ID4NCj4gPiBDYWxs IENvbmZpZ3VyYXRpb246IEFuIDgwMCB0cmFuc2xhdGlvbiBzZXJ2aWNlIGlzIGluc3RhbGxlZCBv biB0d28NCj4gQXBwbGljYXRpb24gU2VydmVycyBBUy0xIGFuZCBBUy0yLiBBIGlzIGNvbm5lY3Rl ZCB0byBTUDEgYW5kIGNhbGxzIDgwMA0KPiAxMjM0IDQ1MjksIHdoaWNoIGlzIHRyYW5zbGF0ZWQg YnkgQVMtMSBhbmQgQVMtMiBpbnRvIGEgcmVndWxhciBFMTY0DQo+IG51bWJlciwgZGVwZW5kaW5n IG9uIGUuZy4gdGhlIGNhbGxlcidzIGxvY2F0aW9uLiBTUDEgZm9yd2FyZHMgSU5WSVRFDQo+IHJl cXVlc3RzIHdpdGggUi1VUkkgPSAiODAwIG51bWJlciIgdG8gQVMtMSBvciBBUy0yIGJhc2VkIG9u IGEgbG9hZA0KPiBiYWxhbmNpbmcgc3RyYXRlZ3kuDQo+ID4NCj4gPiBBcyBjYWxscyB0byA4MDAg MTIzNCA0NTI5IGNyZWF0ZXMgYSBwcmUtb3ZlcmxvYWQgY29uZGl0aW9uIGluIEFTLTEsDQo+IEFT LTEgc2VuZHMgdG8gU1AtMSBhIGZpbHRlciByZXF1ZXN0aW5nIHRoYXQgNTAlIG9mIGNhbGxzIHRv d2FyZHMgODAwDQo+IDEyMzQgNDUyOSBiZSByZWplY3RlZC4NCj4gPg0KPiA+IEFjY29yZGluZyB0 byB0aGUgY3VycmVudCB3b3JkaW5nLCBTUDMgd2lsbCBhcHBseSB0aGUgZmlsdGVyIG9uDQo+IGlu Y29taW5nIElOVklURSByZXF1ZXN0cywgaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgdGhleSBhcmUg aW50ZW5kZWQgdG8NCj4gYmUgc2VudCB0byBBUzEgb3IgQVMyLg0KPiA+DQo+ID4gPT0+IEl0IHNl ZW1zIHRoYXQgdGhlc2UgdXNlIGNhc2VzIGNvdWxkIGJlIHNvbHZlZCBieSBhcHBseWluZyB0aGUN Cj4gZmlsdGVycyB0byBvdXRnb2luZyByZXF1ZXN0cyAobm90IGluY29taW5nIHJlcXVlc3RzKSB0 aGF0IGFyZSB0byBiZQ0KPiByb3V0ZWQgdG8gdGhlIEFTIHRoYXQgc2VudCB0aGVzZSBmaWx0ZXJz LiBUaGlzIG1lYW5zIHRoYXQgdGhlIFNQIGhhcyB0bw0KPiBzdG9yZSB0aGUgQVMgYWRkcmVzcyB0 b2dldGhlciB3aXRoIHRoZSByZWNlaXZlZCBmaWx0ZXJzIG9yIHRoaXMgYWRkcmVzcw0KPiBoYXMg dG8gYmUgaW5jbHVkZWQgZXhwbGljaXRseSBhcyBhIG5ldyBmaWx0ZXIgY3JpdGVyaWEuDQo+ID4N Cj4gPj4NCj4gPj4NCj4gPj4gPiA1KSBTZWN0aW9uIDYuMy4xLCBsb2NhbCBudW1iZXIgZ3JvdXBp bmc6DQo+ID4+ID4NCj4gPj4gPiBUaGUgcHJvcG9zZWQgc29sdXRpb24gZm9yIGxvY2FsIG51bWJl cnMgaXMgbm90IHN1aXRhYmxlLiBGb3INCj4gZXhhbXBsZSwNCj4gPj4gaWYgdGhlIHBob25lLWNv bnRleHQgZm9yIHNob3J0IHNlcnZpY2UgbnVtYmVycyBpbiBhIGNvdW50cnkgaXMgdGhlDQo+ID4+ IGNvdW50cnkgY29kZSwgdGhlIHNvbHV0aW9uIGRvZXMgbm90IHBlcm1pdCB0byBkZWZpbmUgYSBm aWx0ZXIgdGhhdA0KPiA+PiBleGNsdWRlcyBhbGwgRS4xNjQgbnVtYmVycyBpbiB0aGF0IGNvdW50 cnkgYnV0IHJldGFpbiBhbGwgc2hvcnQNCj4gc2VydmljZQ0KPiA+PiBudW1iZXJzLiBJIHRoaW5r IHdlIHNob3VsZCBlaXRoZXIgZGVmaW5lIGFub3RoZXIgc29sdXRpb24gb3Igc3RhdGUNCj4gdGhh dA0KPiA+PiBncm91cGluZyBvZiBsb2NhbCBudW1iZXJzIGlzIG5vdCBzdXBwb3J0ZWQgb3Igc3Rh dGUgdGhhdCBncm91cGluZyBvZg0KPiA+PiBsb2NhbCBudW1iZXJzIG9ubHkgd29ya3MgdW5kZXIg c3BlY2lmaWMgYXNzdW1wdGlvbnMgb24gdGhlIHVzZSBvZg0KPiBwaG9uZS0NCj4gPj4gY29udGV4 dCB2YWx1ZXMuDQo+ID4+ID4NCj4gPj4NCj4gPj4gSG93IGFib3V0IGFkZGluZyB0aGUgZm9sbG93 aW5nIHRleHQ/DQo+ID4+DQo+ID4+IEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoZSBtZXRob2Qg b2YgZ3JvdXBpbmcgbG9jYWwgbnVtYmVycyBhcw0KPiA+PiBkZWZpbmVkIGluIHRoaXMgZG9jdW1l bnQgZG9lcyBub3Qgc3VwcG9ydCBhbGwgY2FzZXMuIEZvciBleGFtcGxlLCBpZg0KPiA+PiB0aGUg cGhvbmUtY29udGV4dCBmb3Igc2hvcnQgc2VydmljZSBudW1iZXJzIGluIGEgY291bnRyeSBpcyB0 aGUNCj4gPj4gY291bnRyeSBjb2RlLCB0aGlzIHNvbHV0aW9uIGRvZXMgbm90IHBlcm1pdCB0byBk ZWZpbmUgYSBmaWx0ZXIgdGhhdA0KPiA+PiBleGNsdWRlcyBhbGwgRS4xNjQgbnVtYmVycyBpbiB0 aGF0IGNvdW50cnkgYnV0IHJldGFpbiBhbGwgc2hvcnQNCj4gPj4gc2VydmljZSBudW1iZXJzLiBB IGNvbXBsZXRlIHNvbHV0aW9uIGZvciBsb2NhbCBudW1iZXIgZ3JvdXBpbmcNCj4gPj4gcmVxdWly ZXMgYSBzZXBhcmF0ZSBtZXRob2Qgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4N Cj4gPiBbQkNdDQo+ID4NCj4gPiBMb29rcyBPSyBmb3IgbWUuDQo+ID4NCj4gPg0KPiA+Pg0KPiA+ Pg0KPiA+PiBUaGFua3MhDQo+ID4+DQo+ID4+IENoYXJsZXMNCj4gPj4NCj4gPj4NCj4gPj4gT24g V2VkLCBKdWwgMTEsIDIwMTIgYXQgMzozMyBBTSwgIDxicnVuby5jaGF0cmFzQG9yYW5nZS5jb20+ IHdyb3RlOg0KPiA+PiA+IEhpIQ0KPiA+PiA+DQo+ID4+ID4gSGVyZSBhcmUgbXkgY29tbWVudHMg YWJvdXQgdGhpcyBJLUQuDQo+ID4+ID4NCj4gPj4gPiAxKSBTZWN0aW9uIDQuMywgbW92ZSBwYXJh Z3JhcGggNyAobGluZSAzNzYgLSAzODYpIGFmdGVyIHBhcmFncmFwaCA1DQo+ID4+IChpLmUuIGFm dGVyIGxpbmUgMzYwKSBhbmQgbW9kaWZpZXMgdGhlIGZpcnN0IHR3byBzZW50ZW5jZXMgYXMgZm9s bG93czoNCj4gPj4gPg0KPiA+PiA+ICJJbiB0aGUgYWJvdmUgY2FzZSwgdGhlIG5ldHdvcmsgZW50 aXR5IHdoZXJlIGxvYWQgZmlsdGVyaW5nIHBvbGljeQ0KPiBpcw0KPiA+PiBmaXJzdCBpbnRyb2R1 Y2VkIGlzIHRoZSBTSVAgc2VydmVyIHByb3ZpZGluZyBhY2Nlc3MgdG8gdGhlIHJlc291cmNlDQo+ IHRoYXQNCj4gPj4gY3JlYXRlcyB0aGUgb3ZlcmxvYWQgY29uZGl0aW9uLiBJbiBvdGhlciBjYXNl cywgdGhlIG5ldHdvcmsgZW50cnkNCj4gcG9pbnQNCj4gPj4gb2YgbG9hZCBmaWx0ZXJpbmcgcG9s aWN5IGNvdWxkIGFsc28gYmUgYW4gZW50aXR5IHRoYXQgaG9zdHMgdGhpcw0KPiA+PiByZXNvdXJj ZS4gIg0KPiA+PiA+DQo+ID4+ID4gMikgU2VjdGlvbiA1LjgsIGxpbmUgNTI1LTUyOA0KPiA+PiA+ DQo+ID4+ID4gVGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0cyB0aGF0IGluY29taW5nIHJlcXVlc3Rz IGFyZSBmaWx0ZXJlZA0KPiA+PiBpcnJlc3BlY3RpdmUgb2YgdGhlaXIgYWN0dWFsIGRlc3RpbmF0 aW9uLiBUaGUgc3Vic2NyaWJlciBzaG91bGQNCj4gcmF0aGVyDQo+ID4+IGFwcGx5IGZpbHRlcnMg b24gcmVxdWVzdHMgdGhhdCBhcmUgb3V0Z29pbmcgdG8gdGhlIHByZS1vdmVybG9hZGVkDQo+ID4+ IGRlc3RpbmF0aW9uLiBPbmUgc29sdXRpb24gd291bGQgYmUgdG8gcmVwaHJhc2UgdGhlIGZvbGxv d2luZyB0ZXh0Og0KPiA+PiA+DQo+ID4+ID4gIkEgc3Vic2NyaWJlciByZWNlaXZpbmcgdGhlIG5v dGlmaWNhdGlvbiBmaXJzdCBpbnN0YWxscyB0aGVzZSBydWxlcw0KPiA+PiBhbmQgdGhlbiBmaWx0 ZXIgaW5jb21pbmcgcmVxdWVzdHMgdG8gZW5mb3JjZSBhY3Rpb25zIG9uIGFwcHJvcHJpYXRlDQo+ ID4+IHJlcXVlc3RzLCBmb3IgZXhhbXBsZSwgbGltaXRpbmcgdGhlIHNlbmRpbmcgcmF0ZSBvZiBj YWxsIHJlcXVlc3RzDQo+ID4+IGRlc3RpbmVkIGZvciBhIHNwZWNpZmljIFNJUCBlbnRpdHkuIg0K PiA+PiA+DQo+ID4+ID4gV2l0aA0KPiA+PiA+DQo+ID4+ID4gIkEgc3Vic2NyaWJlciByZWNlaXZp bmcgdGhlIG5vdGlmaWNhdGlvbiBmaXJzdCBpbnN0YWxscyB0aGVzZSBydWxlcw0KPiA+PiBhbmQg dGhlbiBmaWx0ZXIgb3V0Z29pbmcgcmVxdWVzdHMgdG93YXJkcyB0aGUgbm90aWZpZXIgdG8gZW5m b3JjZQ0KPiA+PiBhY3Rpb25zIG9uIGFwcHJvcHJpYXRlIHJlcXVlc3RzLCBmb3IgZXhhbXBsZSwg bGltaXRpbmcgdGhlIHNlbmRpbmcNCj4gcmF0ZQ0KPiA+PiBvZiBjYWxsIHJlcXVlc3RzIGRlc3Rp bmVkIGZvciBhIHNwZWNpZmljIFNJUCBlbnRpdHkuIg0KPiA+PiA+DQo+ID4+ID4gVGhpcyB3b3Vs ZCBob3dldmVyIG5vdCBwZXJtaXQgdGhlIHVzZSBvZiBleHRlcm5hbCBzdGF0ZSBhZ2VudHMgYXMN Cj4gPj4gZGVzY3JpYmVkIGluIHNlY3Rpb24gNS4xMi4gVGhlcmVmb3JlIGl0IHNlZW1zIHRoYXQg YSAidGFyZ2V0IHNpcA0KPiBlbnRpdHkiDQo+ID4+IHBhcmFtZXRlciBzaG91bGQgYmUgYWRkZWQg dG8gb3ZlcmxvYWQgY29udHJvbCBkb2N1bWVudHMuDQo+ID4+ID4NCj4gPj4gPiAzKSBTZWN0aW9u IDUuOCwgYWRkIHRoZSBmb2xsb3dpbmcgdGV4dCAoYWRhcHRlZCBmcm9tIGRyYWZ0LWlldGYtDQo+ IHNvYy0NCj4gPj4gb3ZlcmxvYWQtY29udHJvbCkgYWZ0ZXIgbGluZSA1Mzc6DQo+ID4+ID4NCj4g Pj4gPiAiV2hlbiBlbmZvcmNpbmcgYWN0aW9ucyBvbiByZXF1ZXN0cyBtYXRjaGluZyB0aGUgZmls dGVycywNCj4gc3Vic2NyaWJlcnMNCj4gPj4gU0hPVUxEIGhvbm9yIHRoZSBsb2NhbCBwb2xpY3kg Zm9yIHByaW9yaXRpemluZyBTSVAgcmVxdWVzdHMgc3VjaCBhcw0KPiA+PiBwb2xpY2llcyBiYXNl ZCBvbiB0aGUgY29udGVudCBvZiB0aGUgUmVzb3VyY2UtUHJpb3JpdHkgaGVhZGVyIChSUEgsDQo+ ID4+IFJGQzQ0MTIgW1JGQzQ0MTJdKS4gIFNwZWNpZmljIChuYW1lc3BhY2UudmFsdWUpIFJQSCBj b250ZW50cyBtYXkNCj4gPj4gaW5kaWNhdGUgaGlnaCBwcmlvcml0eSByZXF1ZXN0cyB0aGF0IHNo b3VsZCBiZSAgcHJlc2VydmVkIGFzIG11Y2ggYXMNCj4gPj4gcG9zc2libGUgZHVyaW5nIG92ZXJs b2FkLiAgVGhlIFJQSCBjb250ZW50cyBjYW4gYWxzbyBpbmRpY2F0ZSBhIGxvdy0NCj4gPj4gcHJp b3JpdHkgcmVxdWVzdCB0aGF0IGlzIGVsaWdpYmxlIHRvIGJlIGRyb3BwZWQgZHVyaW5nIHRpbWVz IG9mDQo+IG92ZXJsb2FkLg0KPiA+PiBPdGhlciBpbmRpY2F0b3JzLCBzdWNoIGFzIHRoZSBTT1Mg VVJOIFtSRkM1MDMxXSBpbmRpY2F0aW5nIGFuDQo+IGVtZXJnZW5jeQ0KPiA+PiByZXF1ZXN0LCBt YXkgYWxzbyBiZSB1c2VkIGZvciBwcmlvcml0aXphdGlvbi4iDQo+ID4+ID4NCj4gPj4gPiA0KSBT ZWN0aW9uIDYuMy4xLCBtYXRjaGluZyBpZGVudGl0aWVzOiBBZnRlciBsaW5lIDY5OSwgYWRkIHRo ZQ0KPiA+PiBmb2xsb3dpbmcgdGV4dDoNCj4gPj4gPg0KPiA+PiA+ICJCZWZvcmUgZXZhbHVhdGlu ZyBjYWxsLWlkZW50aXR5IGNvbmRpdGlvbnMsIHRoZSBzdWJzY3JpYmVyIHNoYWxsDQo+ID4+IGNv bnZlcnQgVVJJcyByZWNlaXZlZCBpbiBTSVAgaGVhZGVyIGZpZWxkcyBpbiBjYW5vbmljYWwgZm9y bSBhcyBwZXINCj4gUkZDDQo+ID4+IDMyNjEsIGV4Y2VwdCB0aGF0IHRoZSBwaG9uZS1jb250ZXh0 IHBhcmFtZXRlciBzaGFsbCBub3QgYmUgcmVtb3ZlZCwNCj4gaWYNCj4gPj4gcHJlc2VudC4iDQo+ ID4+ID4NCj4gPj4gPiA1KSBTZWN0aW9uIDYuMy4xLCBsb2NhbCBudW1iZXIgZ3JvdXBpbmc6DQo+ ID4+ID4NCj4gPj4gPiBUaGUgcHJvcG9zZWQgc29sdXRpb24gZm9yIGxvY2FsIG51bWJlcnMgaXMg bm90IHN1aXRhYmxlLiBGb3INCj4gZXhhbXBsZSwNCj4gPj4gaWYgdGhlIHBob25lLWNvbnRleHQg Zm9yIHNob3J0IHNlcnZpY2UgbnVtYmVycyBpbiBhIGNvdW50cnkgaXMgdGhlDQo+ID4+IGNvdW50 cnkgY29kZSwgdGhlIHNvbHV0aW9uIGRvZXMgbm90IHBlcm1pdCB0byBkZWZpbmUgYSBmaWx0ZXIg dGhhdA0KPiA+PiBleGNsdWRlcyBhbGwgRS4xNjQgbnVtYmVycyBpbiB0aGF0IGNvdW50cnkgYnV0 IHJldGFpbiBhbGwgc2hvcnQNCj4gc2VydmljZQ0KPiA+PiBudW1iZXJzLiBJIHRoaW5rIHdlIHNo b3VsZCBlaXRoZXIgZGVmaW5lIGFub3RoZXIgc29sdXRpb24gb3Igc3RhdGUNCj4gdGhhdA0KPiA+ PiBncm91cGluZyBvZiBsb2NhbCBudW1iZXJzIGlzIG5vdCBzdXBwb3J0ZWQgb3Igc3RhdGUgdGhh dCBncm91cGluZyBvZg0KPiA+PiBsb2NhbCBudW1iZXJzIG9ubHkgd29ya3MgdW5kZXIgc3BlY2lm aWMgYXNzdW1wdGlvbnMgb24gdGhlIHVzZSBvZg0KPiBwaG9uZS0NCj4gPj4gY29udGV4dCB2YWx1 ZXMuDQo+ID4+ID4NCj4gPj4gPiA2KSBTZWN0aW9uIDYuMy4xLCBsaW5lIDc0NiAtIDc1MywgcmVt b3ZlIHRoZSBsYXN0IGJ1dCBvbmUgc2VudGVuY2UNCj4gYW5kDQo+ID4+IHJld29yZCB0aGUgcmVz dCBvZiB0aGUgdGV4dCBhY2NvcmRpbmdseS4gUmVhc29uOiBUaGUgdXNlIG9mIGxvY2FsDQo+IG51 bWJlcg0KPiA+PiAndGVsJyBVUkkgaW4gdGhlIFItVVJJIGFuZCBUbyBoZWFkZXIgZmllbGQgaXMg bm90IHJhcmUuIEluIHNldmVyYWwNCj4gPj4gY291bnRyaWVzLCBzaG9ydCBudW1iZXJzIGFyZSB1 c2VkIHF1aXRlIGV4dGVuc2l2ZWx5IHRvIGFjY2VzcyBzcGVjaWFsDQo+ID4+IHNlcnZpY2VzLg0K PiA+PiA+DQo+ID4+ID4gIlNlY29uZCwgdXNlIG9mIHRoZSBsb2NhbCBudW1iZXIgJ3RlbCcgVVJJ IGluIHByYWN0aWNlIGlzIGV4cGVjdGVkDQo+IHRvDQo+ID4+IGJlIHJhcmUuIg0KPiA+PiA+DQo+ ID4+ID4gNykgQ2xhdXNlIDYuMy4zLCBhZnRlciBsaW5lIDgwMCwgYWRkOg0KPiA+PiA+DQo+ID4+ ID4gIlNVQlNDUklCRSByZXF1ZXN0cyBhcmUgbm90IGZpbHRlcmVkIGlmIHRoZSBldmVudC10eXBl IGhlYWRlciBmaWVsZA0KPiA+PiBpbmRpY2F0ZXMgdGhlIGV2ZW50IHBhY2thZ2UgZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50LiINCj4gPj4gPg0KPiA+PiA+IDgpIFNlY3Rpb24gNywgbGluZSA5ODUg LSA5OTA6IHJlcGxhY2UgImNhbGwgdHlwZSIgd2l0aCAiY2FsbA0KPiBpZGVudGl0eQ0KPiA+PiB0 eXBlIiAoMyB0aW1lcykNCj4gPj4gPg0KPiA+PiA+IDkpIFNlY3Rpb24gOC4xDQo+ID4+ID4NCj4g Pj4gPiBMaW5lIDEwNDgsIGFkZCAiZXhjZXB0IGluIHNwZWNpZmljIGNhc2VzIHdoZW4gdGhlIElu dGVsbGlnZW50DQo+IE5ldHdvcmsNCj4gPj4gYXJjaGl0ZWN0dXJlIGlzIHVzZWQgW0FJTkdSXS4N Cj4gPj4gPg0KPiA+PiA+IExpbmUgMTA2MCwgcmVtb3ZlIHRoZSBsYXN0IHBhcnQgb2YgdGhlIGZp cnN0IHNlbnRlbmNlIHN0YXJ0aW5nIHdpdGgNCj4gPj4gImFuZCB0aGUgbnVtYmVyIG9mIHByZWZp eCB0byBiZSBtYXRjaGVkLiI6IElUVSBJTiBzcGVjaWZpY2F0aW9ucw0KPiBhbGxvdw0KPiA+PiBm b3IgZHluYW1pYyBzZXRzLg0KPiA+PiA+DQo+ID4+ID4gTGluZSAxMDY4LCByZW1vdmUgdGhlIGxh c3QgcGFydCBvZiB0aGUgZmlyc3Qgc2VudGVuY2Ugc3RhcmluZyB3aXRoDQo+ID4+ICJ3aXRoIGEg Zml4ZWQgc2V0LiI6IFJlYXNvbjogSVRVIElOIHNwZWNpZmljYXRpb25zIGFsbG93IGZvciBkeW5h bWljDQo+ID4+IHNldHMuDQo+ID4+ID4NCj4gPj4gPiAxMCkgICAgICAgICAgTWlzY2VsbGFuZW91 cyBwb2ludHMNCj4gPj4gPiBTZWN0aW9uIDEsIGxpbmUgMTA2LCByZXBsYWNlIFJGQzMyNjUgd2l0 aCBSRkMzMjYxDQo+ID4+ID4gU2VjdGlvbiA0LjEsIGxpbmUgMjMxLCByZXBsYWNlICJwcm94eSIg d2l0aCAibm9kZSIgKHRoaXMgdGV4dA0KPiBzaG91bGQNCj4gPj4gYXBwbHkgdG8gYW55IHR5cGUg b2YgU0lQIGVudGl0eSkNCj4gPj4gPiBTZWN0aW9uIDQuMywgbGluZSAyNjUsIHJlcGxhY2UgInBy b3h5IiB3aXRoICJub2RlIiAodGhpcyB0ZXh0DQo+IHNob3VsZA0KPiA+PiBhcHBseSB0byBhbnkg dHlwZSBvZiBTSVAgZW50aXR5KQ0KPiA+PiA+IFNlY3Rpb24gNC4zLCBMaW5lIDM0MSwgcmVwbGFj ZSAic2luZ2xpbmciIHdpdGggInNpZ25hbGluZyINCj4gPj4gPiBTZWN0aW9uIDQuMywgTGluZSAz NDIsIHJlcGxhY2UgImFsbCBzaWduYWxpbmcgcmVsYXRpb25zaGlwIGluDQo+IEZpZ3VyZSAxDQo+ ID4+IGlzIiB3aXRoICJhbGwgc2lnbmFsaW5nIHJlbGF0aW9uc2hpcHMgaW4gRmlndXJlIDEgYXJl Ig0KPiA+PiA+IFNlY3Rpb24gNS42LCBMaW5lIDUwMywgYWRkICJyZXF1ZXN0IiBhZnRlciAiU1VC U0NSSUJFIg0KPiA+PiA+IFNlY3Rpb24gNS4xMSwgTGluZSA1ODUsIHJlbW92ZSAiaXMiDQo+ID4+ ID4gU2VjdGlvbiA2LjUsIExpbmUgODUxLCByZXBsYWNlICJ2bGlhZCIgd2l0aCAidmFsaWQiDQo+ ID4+ID4NCj4gPj4gPiBCcnVubw0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPj4gLS0tLS1NZXNzYWdl IGQnb3JpZ2luZS0tLS0tDQo+ID4+ID4+IERlIDogc2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpzaXAtb3ZlcmxvYWQtDQo+ID4+IGJvdW5jZXNAaWV0Zi5vcmddDQo+ID4+ID4+ IERlIGxhIHBhcnQgZGUgU2FsdmF0b3JlIExvcmV0bw0KPiA+PiA+PiBFbnZvecOpIDogbHVuZGkg MiBqdWlsbGV0IDIwMTIgMjE6MDkNCj4gPj4gPj4gw4AgOiBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcN Cj4gPj4gPj4gQ2MgOiBWb2xrZXIgSGlsdA0KPiA+PiA+PiBPYmpldCA6IFtzaXAtb3ZlcmxvYWRd IFdHTEM6IGRyYWZ0LWlldGYtc29jLW9sb2FkLWNvbnRyb2wtZXZlbnQtDQo+ID4+IHBhY2thZ2UN Cj4gPj4gPj4NCj4gPj4gPj4gW2FzIGNoYWlyXQ0KPiA+PiA+Pg0KPiA+PiA+PiBiYXNlZCBvbiB0 aGUgbWFpbGluZyBsaXN0IGRpc2N1c3Npb24gYW5kIHRoZSBvbmUgd2UgaGFkIGR1cmluZyB0aGUN Cj4gPj4gbGFzdA0KPiA+PiA+PiBTb0MgZjJmIG1lZXRpbmcgaW4gUGFyaXMsDQo+ID4+ID4+IHRo ZSBjaGFpcnMgdGhpbmsgdGhlIGRyYWZ0LWlldGYtc29jLW9sb2FkLWNvbnRyb2wtZXZlbnQtcGFj a2FnZSBpcw0KPiA+PiByZWFkeQ0KPiA+PiA+PiBmb3IgdGhlIFdHTEMuDQo+ID4+ID4+DQo+ID4+ ID4+IFRvZGF5IHdlIGFyZSBzdGFydGluZyBhIHR3by13ZWVrIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsLg0KPiA+PiA+PiBUaGlzIGNhbGwgZW5kcyBvbiBXZWRuZXNkYXksIEp1bHkgMTZ0aC4NCj4g Pj4gPj4NCj4gPj4gPj4gdGhlIGxhc3QgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQgY2FuIGJlIHJl dHJpZXZlZCBoZXJlOg0KPiA+PiA+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXNvYy1sb2FkLWNvbnRyb2wtZXZlbnQtDQo+IHBhY2thZ2UtDQo+ID4+IDAzDQo+ID4+ID4+ DQo+ID4+ID4+DQo+ID4+ID4+IHJldmlld3MgYW5kIGNvbW1lbnRzIGFyZSByZWFsbHkgYXBwcmVj aWF0ZSBhbmQgcmVxdWVzdGVkIGZyb20gYWxsDQo+IHRoZQ0KPiA+PiA+PiBwYXJ0aWNpcGFudHMN Cj4gPj4gPj4NCj4gPj4gPj4NCj4gPj4gPj4gY2hlZXJzDQo+ID4+ID4+IC9TYWwNCj4gPj4gPj4N Cj4gPj4gPj4gLS0NCj4gPj4gPj4gU2FsdmF0b3JlIExvcmV0bywgUGhEDQo+ID4+ID4+IHd3dy5z bG9yZXRvLmNvbQ0KPiA+PiA+Pg0KPiA+PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+PiA+PiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0DQo+ ID4+ID4+IHNpcC1vdmVybG9hZEBpZXRmLm9yZw0KPiA+PiA+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZA0KPiA+PiA+DQo+ID4+ID4NCj4gPj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPj4gPg0KPiA+PiA+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiA+PiBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KPiA+PiA+IHBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz DQo+IGF2ZXoNCj4gPj4gcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQo+ID4+ID4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzDQo+ID4+IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gPj4gPiBGcmFuY2UgVGVsZWNvbSAtIE9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UNCj4gYQ0KPiA+PiBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gPj4gPg0KPiA+PiA+IFRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv cg0KPiA+PiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7DQo+ID4+ID4gdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0DQo+IGF1dGhvcmlzYXRpb24uDQo+ID4+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+IGFuZA0KPiA+ PiBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4+ID4gQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvcg0KPiA+PiBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuDQo+ID4+ID4gVGhhbmsgeW91Lg0KPiA+PiA+DQo+ID4+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gPiBzaXAtb3ZlcmxvYWQg bWFpbGluZyBsaXN0DQo+ID4+ID4gc2lwLW92ZXJsb2FkQGlldGYub3JnDQo+ID4+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQNCj4gPg0KPiA+DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4NCj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCj4gPiBwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6DQo+IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KPiA+IGEgbCdleHBl ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcw0K PiBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s DQo+ID4gRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGENCj4gZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVy Y2kuDQo+ID4NCj4gPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3INCj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Ow0KPiA+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4g ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+IEFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IN Cj4gbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KPiA+IFRoYW5rIHlvdS4NCj4gPg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywg ZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1 ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2Fn ZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2Ug VGVsZWNvbSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBm YWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From jgunn6@csc.com Thu Aug 2 10:02:18 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B9E21E80CD for ; Thu, 2 Aug 2012 10:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.986 X-Spam-Level: X-Spam-Status: No, score=-2.986 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_43=0.6, MIME_BAD_LINEBREAK=0.5, MIME_HTML_ONLY=1.457, OBFUSCATING_COMMENT=0.973, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lISDtt3MDrjE for ; Thu, 2 Aug 2012 10:02:17 -0700 (PDT) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D621E8084 for ; Thu, 2 Aug 2012 10:02:17 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-6.tower-87.messagelabs.com!1343926935!14185704!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2976 invoked from network); 2 Aug 2012 17:02:16 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-6.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Aug 2012 17:02:16 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q72H2Egt017545 for ; Thu, 2 Aug 2012 13:02:14 -0400 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , , , <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> From: Janet P Gunn To: keith.drage@alcatel-lucent.com Message-ID: Date: Thu, 2 Aug 2012 13:02:11 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.2FP3 July 10, 2011 X-MIMETrack: Serialize by Notes Server on AMER-ML22/SRV/CSC(Release 8.5.2FP3|July 10, 2011) at 08/02/2012 13:02:11, Serialize complete at 08/02/2012 13:02:11, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 08/02/2012 12:58:18 PM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload@ietf.org Subject: Re: [sip-overload] Eveny package was Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 17:02:18 -0000
In that case, the Event package draft should use the ITU t= erms.
=0D
 
=0D
What are the equivalent ITU terms?=0D
 
=0D
Janet 

--= ---"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote: ---= --
=0D
=0D
To: Janet P Gunn/USA/CSC@CSC
From: "DRAGE, Keith (Keith)" <keith.= drage@alcatel-lucent.com>
Date: 08/01/2012 11:25AM
Subject: RE: [s= ip-overload] Alignment of priority and emergency call handling

<= /o:SmartTagType>=0D
=0DRecorder tone is not.

=0D

 

=0D

Neither is reorder tone in the quick skin I did.

=0D

Keith

=0D

=  

=0D
=0D
=0D
=0D
=0D
=0D

From: Janet P Gunn [mailto:jgunn6@csc.com]
Sent: 01 August 2012 10:06
= To: DRAGE, Keith (Keith)
Cc: charles@cs.columbia.edu; = shen@att.com; sip-overload@ietf.org
Subject: RE: [sip-overload] Alignment of priority and emergency= call handling

= =0D

 

=0D
=0D

Sounds good to me. Is "Recorder tone" defined there?<= o:p>

=0D
=0D

=  

=0D
=0D

Janet

--= ---"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote: ---= --

=0D
=0D
To: Janet P Gunn/USA/CSC@CSC, "charles@cs.columbia.edu" <charles@cs.columbia.edu>
Fr= om: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
Date: = 07/30/2012 06:19PM
Cc: "s= ip-overload@ietf.org" <sip-overload@ietf.org>, "shen@att.com" <she= n@att.com>
Subject: RE: [sip-overload] Alignment of priority and emer= gency call handling


=0D
=0D

Can I suggest th= at we stick to the terminology available in ITU-T Rec= ommendation E.182 (and E.180) as this U.S.U.S.= and other terms are used elsewhere in world.

= =0D

 =

=0D

Keith

=0D

 =

=0D
=0D
= =0D
=0D
=0D=
=0D

From: sip-overload-bounces@ietf.org [mailto:= sip-overload-bounces@ietf.org] On Beha= lf Of Janet P Gunn
Sent:= 30 July 2012 23:03
To:<= /SPAN> charles@cs.columbia.edu
= Cc: sip-overload@ietf.org; shen@att.com
Subject: Re: [sip-overload] Alignment of priorit= y and emergency call handling

=0D

 

=0D
=0D

Thanks

=0D
=0D

 

=0D
=0D

WRT the last comment - "Reorder tone" is also known (at least in the= -->US-->) as "fast busy".=

=0D
=0D

I agree that there might be "announ= cements"

=0D
=0D

b= ut I do not know what you mean by "Recorder tone". Do you mean the tone tha= t sometimes comes on just BEFORE an announcement?<= /P>

=0D
=0D

 

<= /DIV>=0D
=0D

Janet

= =0D
=0D


-----charles.newyork@gmail.com wrote: ----- =

=0D
=0D
=0D

T= o: Janet P Gunn/USA/CSC@CSC<= !--Notes ACF=0D-->From: Charles Shen
Sent b= y: charles.newyork@gmail.com
Date: 07/29/2012 11:35PM
Cc: vkg@bell-la= bs.com, sip-overload@ietf.org, shen@att.com
Subject: Re: [sip-overload] = Alignment of priority and emergency call handling

Hi Janet, thank you very much for your detailed comments! = I've
incorporated them in the new revision. Also please see response
= inline.

On Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn <jgunn6@csc= .com> wrote:
> I agree with Keith's comments about priority and em= ergency calls.
>

done

> I also have a number of othe= r comments, mostly editorial (I apologize for my
> lateness in respon= ding).
>
>
> Introduction should stress that this approac= h is for situations where you
> can predict, in advance, a likely tra= ffic surge,
> and its source/destination distribution.  For inst= ance, it is appropriate
> for a mass-phone-voting event, Mother's Day= , New
> Years, and even a hurricane (there is usually some advance no= tice).
> However, it is less likely to be effective for the initial p= hase of
> unpredicted/unpredictable mass calling events, such as
&= gt; earthquakes or terrorist attacks.  In these latter cases, the loca= l traffic
> load may peak by more than an order of magnitude
> = in minutes, if not seconds.  This does not allow time to either
>= ; effectively identify the filters needed, nor distribute then to the
&g= t; appropriate servers, soon enough to prevent congestion
> attack. &= nbsp;Once other, more immediate, techniques (such as the loss-based or
&= gt; rate-based  methods) have prevented the initial
> congestion= collapse, the event package can be used to effectively control
> the= continuing overload.
> --

agree.

> This sentence>  Load filtering works best if it prevents calls as close to
&= gt;  the user agent clients as possible.
> could be clarified by= including the word "originating"
>  Load filtering works best i= f it prevents calls as close to
>  the originating user agent cl= ients as possible.
> --

right

> There appears to be = a cut and past error here
> Secondly, since we are describing a speci= fic control
>    mechanism based on filtering, the term "lo= ad control" in this
>    specification is used inter-change= ably with the term "load filtering"
>    unless when associ= ated with other explicit context.
> I suspect it is supposed to be> Secondly, since we are describing a specific control
>   &= nbsp;mechanism based on filtering, the term "load control" in this
> =    specification is used inter-changeably with the term "load fil= tering"
>    unless associated with other explicit context.=
> --
>

right

> I am not sure I understand thi= s statement
> This
>    specification, however, does = not preclude the load control document
>    defined here (S= ection 6) to be extended in the future for other forms
>    = ;of control as appropriate.
> What sorts of "other forms of control" = are you referring to?  Presumably not
> service level and QoS co= ntrol, as you have
> already defined them (or at least referred to th= em) as "load control" but
> not "overload control".
> --
Yes, it could be confusing, so I removed this sentence.

>  = Section 3
> I think that
> For destination-specific overload si= tuations, the load filter
>       needs to be able to = describe the callee.
> should be
> For destination-specific ove= rload situations, the load filter
>       should be ab= le to specify the callee.
> --

agree.

> This bullet<= BR>>  To address accidental and intentional high-volume call genera= tors,
>       the load filter should allow to specify = the caller.
> does not use correct grammar.
> I suspect you mea= n
>  To address accidental and intentional high-volume call gene= rators,
>       the load filter should be able to &nbs= p;specify the caller.
> --

agree

> With regard to th= is bullet,
>    o  For telephone numbers, it should be= possible to specify prefixes
>       which allow cont= rol over limited regionally-focused overloads.
> This is really an as= sumption rather than a requirement.
> Furthermore, I do not believe i= t is true.  In these days of number
> portability, and people re= taining their original mobile
> phone number, as their primary number= , when they move across the country,
> the correlation between "telep= hone number prefix"
> (aka area code) and "physical location" is rapi= dly decreasing.
> I agree that,for regional calling events, you need = a way of identifying the
> geographical location (originating and/or<= BR>> terminating) to determine which calls to filter.  But I do not= think that
> area codes will continue to be the most effective
&g= t; way of doing this.
> Perhaps an alternate wording would be
>=    o  It should be possible to specify particular informati= on in the SIP
> headers (e.g., prefixes in telephone numbers)
>=       which allow control over limited regionally-focused o= verloads
> ---

agree

> sec 4.2
>  in this= statement
>  and that loads are allocated in a way which
>= ;    both prevents overload and minimizes the likelihood of netwo= rk
>    resource under-utilization.
> would it be bet= ter to say "maximizes effective throughput(aka goodput)"
> instead of= "minimizes the likelihood of network
>    resource under-u= tilization."?
> ---

agree

> sec 4.3
>
> = Should this
> In order for load filters to be properly distributed, e= ach SIP proxy
>    server in the network is required to sub= scribe to the load control
>    event package from all its = outgoing signaling neighbors, known as
>    notifiers (Sect= ion 5.6).
> be
> In order for load filters to be properly distr= ibuted, each SIP proxy
>    server in the network SHOULD su= bscribe to the load control
>    event package from all its= outgoing signaling neighbors, known as
>    notifiers (Sec= tion 5.6).
> ? (not sure myself)
>
> ---

agree.
> For case II, perhaps "hurricane" (which has a more predictable, a= nd more
> gradual, increase in traffic) would be a better
> exa= mple than "earthquake", due to the issues mentioned above.
> --
&g= t; Sec 5.3
> In sec 4.4 you say
> Another important aspect that= affects the applicability of SIP load
>    filtering is th= at all possible signaling source neighbors need to
>    par= ticipate and enforce the designated filter.  Otherwise, a single
&g= t;    non-conforming neighbor could make the whole control effort= s useless
>    by pumping in excessive traffic to overload = the server.
> But in section 5.3 you say
> a subscriber may be = interested in some
>    specific types of load control poli= cy only.
> Maybe I am misunderstanding what you mean by "types of loa= d control policy",
> but the statement in 5.3 ("only interested in> some") seem inconsistent with the statement in 4.3 ("all must partici= pate").
> Perhaps you could add a clarifying statement.
> ---
Since the details of the subscription filter specification are notdefined anyway, I removed this "For example" sentence to avoid the
conf= usion.


> 5.8
> Modifications of existing load
> &= nbsp;  control policies at the subscriber is performed after directly<= BR>>    receiving notifications containing updated load contro= l policies.
> Grammar
> either
> ... modifications ... ar= e ...
> or
> ...modification ...is ...
> but NOT
> = ... modifications ... is ...
> ---

right

> 5.11
&= gt; This sentence
> "Another factor usually not known precisely or is=
>    computed automatically is the validity duration of th= e load control
>    event."
> Seems to be a cut and p= aste error of some sort.
> ...

Changed to "  Another fact= or that is usually not known precisely or
needs to be computed automatic= ally is the validity duration of the
load control event.  "

= > 8.1
> Should this
> "... administrative option for routing= failed
>    call attempts to either Recorder Tone or a spe= cial announcement...."
> be "Reorder Tone" instead of "Recorder Tone"= ?
>
>

I think this is something like a recording machine= playing something
message, am I correct?

thanks

Charles

> Janet
>
>
>
> -----sip-overload-boun= ces@ietf.org wrote: -----
>
> To: sip-overload@ietf.org
>= From: "Vijay K. Gurbani"
> Sent by: sip-overload-bounces@ietf.org> Date: 07/26/2012 12:03PM
> Cc: shen@att.com
>
> Sub= ject: Re: [sip-overload] Alignment of priority and emergency call
> h= andling
>
> On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote:=
>> I do not believe you need to include other artifacts.
>&= gt;
>> Rather overload-control lists both RPH and sos URN, and the= event
>> package lists only RPH.
>
> So it is a simpl= e matter of ensuring that the text in
> draft-ietf-soc-load-control-e= vent-package is consistent with the
> text in draft-ietf-soc-overload= -control?
>
> If so, Charles --- can you please take care of th= is in
> draft-ietf-soc-load-control-event-package?
>
> Th= anks,
>
> - vijay
> --
> Vijay K. Gurbani, = Bell Laboratories= , Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville<= !--Notes ACF=0D-->, = Illinois 60563 (-->USA)
> Email: vkg= @{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web: &n= bsp; http://ect.bell-labs.com= /who/vkg/
>
>
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> sip-overload mailing list
> si= p-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
&= gt;
>
>
> This is a PRIVATE message. If you are not the i= ntended recipient, please
> delete without copying and kindly advise = us by e-mail of the mistake in
> delivery. NOTE: Regardless of conten= t, this e-mail shall not operate to bind
> CSC--> to= any order or other contract unless pursuant to explicit written
> ag= reement or government initiative expressly permitting the use of e-mail
= > for such purpose.
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F
> sip-overload mailing list
> sip-over= load@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>

=0D



This is a PRIVATE message. If = you are not the intended recipient, please delete without copying and kindl= y advise us by e-mail of the mistake in delivery. NOTE: Regardless of conte= nt, this e-mail shall not operate to bind CSC to any or= der or other contract unless pursuant to explicit written agreement or gove= rnment initiative expressly permitting the use of e-mail for such purpose.<= /SPAN>

=0D



This is a PRIVATE message.= If you are not the intended recipient, please delete without copying and k= indly advise us by e-mail of the mistake in delivery. NOTE: Regardless of c= ontent, 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.=



This is a PRIVATE message. If you are not the inten= ded 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 th= e use of e-mail for such purpose.= = From bruno.chatras@orange.com Fri Aug 3 02:08:50 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08A521F8D22 for ; Fri, 3 Aug 2012 02:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRSBWRGayWHn for ; Fri, 3 Aug 2012 02:08:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id A0C2E21F8D1D for ; Fri, 3 Aug 2012 02:08:47 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 637D526445E; Fri, 3 Aug 2012 11:08:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 337764C060; Fri, 3 Aug 2012 11:08:46 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 11:08:45 +0200 From: To: Janet P Gunn , "keith.drage@alcatel-lucent.com" Thread-Topic: [sip-overload] Eveny package was Alignment of priority and emergency call handling Thread-Index: AQHNcNCVzLTG24Y8WUijFVEe+dLOs5dHylqA Date: Fri, 3 Aug 2012 09:08:45 +0000 Message-ID: <27278_1343984926_501B951E_27278_2308_1_88CAD1D4E8773F42858B58CAA28272A0069343@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: , , , <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A0069343PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.3.71527 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] Eveny package was Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 09:08:51 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A0069343PEXCVZYM12corpora_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayByZWNvcmRlciB0b25lIGlzIGEgdG9uZSB0byBpbmRpY2F0ZSB0byB0aGUgY2FsbGVk IHBhcnR5IHRoYXQgdGhlIGNhbGxpbmcgcGFydHkgaXMgcmVjb3JkaW5nIHRoZSBjb252ZXJzYXRp b24uIFNvIEkgZG9u4oCZdCB0aGluayB0aGlzIHRvbmUgd291bGQgYmUgYXBwcm9wcmlhdGUgaW4g dGhlIGNhc2Ugb2YgY2FsbCBmYWlsdXJlIGR1ZSB0byBvdmVybG9hZCBjb250cm9sLiBBbiBJVFUg RS4xODIgc3BlY2lhbCBpbmZvcm1hdGlvbiB0b25lIHdvdWxkIHJhdGhlciBiZSB1c2VkIGluIHRo aXMgY2FzZS4NCi9CQw0KDQoNCg0KRGUgOiBzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIEphbmV0 IFAgR3Vubg0KRW52b3nDqSA6IGpldWRpIDIgYW/Du3QgMjAxMiAxOTowMg0Kw4AgOiBrZWl0aC5k cmFnZUBhbGNhdGVsLWx1Y2VudC5jb20NCkNjIDogc2lwLW92ZXJsb2FkQGlldGYub3JnDQpPYmpl dCA6IFJlOiBbc2lwLW92ZXJsb2FkXSBFdmVueSBwYWNrYWdlIHdhcyBBbGlnbm1lbnQgb2YgcHJp b3JpdHkgYW5kIGVtZXJnZW5jeSBjYWxsIGhhbmRsaW5nDQoNCkluIHRoYXQgY2FzZSwgdGhlIEV2 ZW50IHBhY2thZ2UgZHJhZnQgc2hvdWxkIHVzZSB0aGUgSVRVIHRlcm1zLg0KDQpXaGF0IGFyZSB0 aGUgZXF1aXZhbGVudCBJVFUgdGVybXM/DQoNCkphbmV0DQoNCi0tLS0tIkRSQUdFLCBLZWl0aCAo S2VpdGgpIiA8a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZTogLS0tLS0NClRv OiBKYW5ldCBQIEd1bm4vVVNBL0NTQ0BDU0MNCkZyb206ICJEUkFHRSwgS2VpdGggKEtlaXRoKSIg PGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4NCkRhdGU6IDA4LzAxLzIwMTIgMTE6MjVB TQ0KU3ViamVjdDogUkU6IFtzaXAtb3ZlcmxvYWRdIEFsaWdubWVudCBvZiBwcmlvcml0eSBhbmQg ZW1lcmdlbmN5IGNhbGwgaGFuZGxpbmcNClJlY29yZGVyIHRvbmUgaXMgbm90Lg0KDQpOZWl0aGVy IGlzIHJlb3JkZXIgdG9uZSBpbiB0aGUgcXVpY2sgc2tpbiBJIGRpZC4NCg0KS2VpdGgNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEphbmV0IFAgR3VubiBbbWFpbHRv OmpndW5uNkBjc2MuY29tXQ0KU2VudDogMDEgQXVndXN0IDIwMTIgMTA6MDYNClRvOiBEUkFHRSwg S2VpdGggKEtlaXRoKQ0KQ2M6IGNoYXJsZXNAY3MuY29sdW1iaWEuZWR1OyBzaGVuQGF0dC5jb207 IHNpcC1vdmVybG9hZEBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtzaXAtb3ZlcmxvYWRdIEFsaWdu bWVudCBvZiBwcmlvcml0eSBhbmQgZW1lcmdlbmN5IGNhbGwgaGFuZGxpbmcNCg0KU291bmRzIGdv b2QgdG8gbWUuIElzICJSZWNvcmRlciB0b25lIiBkZWZpbmVkIHRoZXJlPw0KDQpKYW5ldA0KDQot LS0tLSJEUkFHRSwgS2VpdGggKEtlaXRoKSIgPGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNv bT4gd3JvdGU6IC0tLS0tDQpUbzogSmFuZXQgUCBHdW5uL1VTQS9DU0NAQ1NDLCAiY2hhcmxlc0Bj cy5jb2x1bWJpYS5lZHUiIDxjaGFybGVzQGNzLmNvbHVtYmlhLmVkdT4NCkZyb206ICJEUkFHRSwg S2VpdGggKEtlaXRoKSIgPGtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVjZW50LmNvbT4NCkRhdGU6IDA3 LzMwLzIwMTIgMDY6MTlQTQ0KQ2M6ICJzaXAtb3ZlcmxvYWRAaWV0Zi5vcmciIDxzaXAtb3Zlcmxv YWRAaWV0Zi5vcmc+LCAic2hlbkBhdHQuY29tIiA8c2hlbkBhdHQuY29tPg0KU3ViamVjdDogUkU6 IFtzaXAtb3ZlcmxvYWRdIEFsaWdubWVudCBvZiBwcmlvcml0eSBhbmQgZW1lcmdlbmN5IGNhbGwg aGFuZGxpbmcNCg0KQ2FuIEkgc3VnZ2VzdCB0aGF0IHdlIHN0aWNrIHRvIHRoZSB0ZXJtaW5vbG9n eSBhdmFpbGFibGUgaW4gSVRVLVQgUmVjb21tZW5kYXRpb24gRS4xODIgKGFuZCBFLjE4MCkgYXMg dGhpcyBVLlMuIHRlcm1pbm9sb2d5IGlzIHZlcnkgc3BlY2lmaWMgdG8gdGhlIFUuUy4gYW5kIG90 aGVyIHRlcm1zIGFyZSB1c2VkIGVsc2V3aGVyZSBpbiB3b3JsZC4NCg0KS2VpdGgNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IHNpcC1vdmVybG9hZC1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86c2lwLW92ZXJsb2FkLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBKYW5ldCBQIEd1bm4NClNlbnQ6IDMwIEp1bHkgMjAxMiAyMzowMw0KVG86IGNoYXJsZXNAY3Mu Y29sdW1iaWEuZWR1DQpDYzogc2lwLW92ZXJsb2FkQGlldGYub3JnOyBzaGVuQGF0dC5jb20NClN1 YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBBbGlnbm1lbnQgb2YgcHJpb3JpdHkgYW5kIGVtZXJn ZW5jeSBjYWxsIGhhbmRsaW5nDQoNClRoYW5rcw0KDQpXUlQgdGhlIGxhc3QgY29tbWVudCAtICJS ZW9yZGVyIHRvbmUiIGlzIGFsc28ga25vd24gKGF0IGxlYXN0IGluIHRoZSBVUykgYXMgImZhc3Qg YnVzeSIuDQpJIGFncmVlIHRoYXQgdGhlcmUgbWlnaHQgYmUgImFubm91bmNlbWVudHMiDQpidXQg SSBkbyBub3Qga25vdyB3aGF0IHlvdSBtZWFuIGJ5ICJSZWNvcmRlciB0b25lIi4gRG8geW91IG1l YW4gdGhlIHRvbmUgdGhhdCBzb21ldGltZXMgY29tZXMgb24ganVzdCBCRUZPUkUgYW4gYW5ub3Vu Y2VtZW50Pw0KDQpKYW5ldA0KDQotLS0tLWNoYXJsZXMubmV3eW9ya0BnbWFpbC5jb20gd3JvdGU6 IC0tLS0tDQpUbzogSmFuZXQgUCBHdW5uL1VTQS9DU0NAQ1NDDQpGcm9tOiBDaGFybGVzIFNoZW4N ClNlbnQgYnk6IGNoYXJsZXMubmV3eW9ya0BnbWFpbC5jb20NCkRhdGU6IDA3LzI5LzIwMTIgMTE6 MzVQTQ0KQ2M6IHZrZ0BiZWxsLWxhYnMuY29tLCBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmcsIHNoZW5A YXR0LmNvbQ0KU3ViamVjdDogUmU6IFtzaXAtb3ZlcmxvYWRdIEFsaWdubWVudCBvZiBwcmlvcml0 eSBhbmQgZW1lcmdlbmN5IGNhbGwgaGFuZGxpbmcNCg0KSGkgSmFuZXQsIHRoYW5rIHlvdSB2ZXJ5 IG11Y2ggZm9yIHlvdXIgZGV0YWlsZWQgY29tbWVudHMhIEkndmUNCmluY29ycG9yYXRlZCB0aGVt IGluIHRoZSBuZXcgcmV2aXNpb24uIEFsc28gcGxlYXNlIHNlZSByZXNwb25zZQ0KaW5saW5lLg0K DQpPbiBTdW4sIEp1bCAyOSwgMjAxMiBhdCA1OjQ5IFBNLCBKYW5ldCBQIEd1bm4gPGpndW5uNkBj c2MuY29tPiB3cm90ZToNCj4gSSBhZ3JlZSB3aXRoIEtlaXRoJ3MgY29tbWVudHMgYWJvdXQgcHJp b3JpdHkgYW5kIGVtZXJnZW5jeSBjYWxscy4NCj4NCg0KZG9uZQ0KDQo+IEkgYWxzbyBoYXZlIGEg bnVtYmVyIG9mIG90aGVyIGNvbW1lbnRzLCBtb3N0bHkgZWRpdG9yaWFsIChJIGFwb2xvZ2l6ZSBm b3IgbXkNCj4gbGF0ZW5lc3MgaW4gcmVzcG9uZGluZykuDQo+DQo+DQo+IEludHJvZHVjdGlvbiBz aG91bGQgc3RyZXNzIHRoYXQgdGhpcyBhcHByb2FjaCBpcyBmb3Igc2l0dWF0aW9ucyB3aGVyZSB5 b3UNCj4gY2FuIHByZWRpY3QsIGluIGFkdmFuY2UsIGEgbGlrZWx5IHRyYWZmaWMgc3VyZ2UsDQo+ IGFuZCBpdHMgc291cmNlL2Rlc3RpbmF0aW9uIGRpc3RyaWJ1dGlvbi4gIEZvciBpbnN0YW5jZSwg aXQgaXMgYXBwcm9wcmlhdGUNCj4gZm9yIGEgbWFzcy1waG9uZS12b3RpbmcgZXZlbnQsIE1vdGhl cidzIERheSwgTmV3DQo+IFllYXJzLCBhbmQgZXZlbiBhIGh1cnJpY2FuZSAodGhlcmUgaXMgdXN1 YWxseSBzb21lIGFkdmFuY2Ugbm90aWNlKS4NCj4gSG93ZXZlciwgaXQgaXMgbGVzcyBsaWtlbHkg dG8gYmUgZWZmZWN0aXZlIGZvciB0aGUgaW5pdGlhbCBwaGFzZSBvZg0KPiB1bnByZWRpY3RlZC91 bnByZWRpY3RhYmxlIG1hc3MgY2FsbGluZyBldmVudHMsIHN1Y2ggYXMNCj4gZWFydGhxdWFrZXMg b3IgdGVycm9yaXN0IGF0dGFja3MuICBJbiB0aGVzZSBsYXR0ZXIgY2FzZXMsIHRoZSBsb2NhbCB0 cmFmZmljDQo+IGxvYWQgbWF5IHBlYWsgYnkgbW9yZSB0aGFuIGFuIG9yZGVyIG9mIG1hZ25pdHVk ZQ0KPiBpbiBtaW51dGVzLCBpZiBub3Qgc2Vjb25kcy4gIFRoaXMgZG9lcyBub3QgYWxsb3cgdGlt ZSB0byBlaXRoZXINCj4gZWZmZWN0aXZlbHkgaWRlbnRpZnkgdGhlIGZpbHRlcnMgbmVlZGVkLCBu b3IgZGlzdHJpYnV0ZSB0aGVuIHRvIHRoZQ0KPiBhcHByb3ByaWF0ZSBzZXJ2ZXJzLCBzb29uIGVu b3VnaCB0byBwcmV2ZW50IGNvbmdlc3Rpb24NCj4gYXR0YWNrLiAgT25jZSBvdGhlciwgbW9yZSBp bW1lZGlhdGUsIHRlY2huaXF1ZXMgKHN1Y2ggYXMgdGhlIGxvc3MtYmFzZWQgb3INCj4gcmF0ZS1i YXNlZCAgbWV0aG9kcykgaGF2ZSBwcmV2ZW50ZWQgdGhlIGluaXRpYWwNCj4gY29uZ2VzdGlvbiBj b2xsYXBzZSwgdGhlIGV2ZW50IHBhY2thZ2UgY2FuIGJlIHVzZWQgdG8gZWZmZWN0aXZlbHkgY29u dHJvbA0KPiB0aGUgY29udGludWluZyBvdmVybG9hZC4NCj4gLS0NCg0KYWdyZWUuDQoNCj4gVGhp cyBzZW50ZW5jZQ0KPiAgTG9hZCBmaWx0ZXJpbmcgd29ya3MgYmVzdCBpZiBpdCBwcmV2ZW50cyBj YWxscyBhcyBjbG9zZSB0bw0KPiAgdGhlIHVzZXIgYWdlbnQgY2xpZW50cyBhcyBwb3NzaWJsZS4N Cj4gY291bGQgYmUgY2xhcmlmaWVkIGJ5IGluY2x1ZGluZyB0aGUgd29yZCAib3JpZ2luYXRpbmci DQo+ICBMb2FkIGZpbHRlcmluZyB3b3JrcyBiZXN0IGlmIGl0IHByZXZlbnRzIGNhbGxzIGFzIGNs b3NlIHRvDQo+ICB0aGUgb3JpZ2luYXRpbmcgdXNlciBhZ2VudCBjbGllbnRzIGFzIHBvc3NpYmxl Lg0KPiAtLQ0KDQpyaWdodA0KDQo+IFRoZXJlIGFwcGVhcnMgdG8gYmUgYSBjdXQgYW5kIHBhc3Qg ZXJyb3IgaGVyZQ0KPiBTZWNvbmRseSwgc2luY2Ugd2UgYXJlIGRlc2NyaWJpbmcgYSBzcGVjaWZp YyBjb250cm9sDQo+ICAgIG1lY2hhbmlzbSBiYXNlZCBvbiBmaWx0ZXJpbmcsIHRoZSB0ZXJtICJs b2FkIGNvbnRyb2wiIGluIHRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbiBpcyB1c2VkIGludGVyLWNo YW5nZWFibHkgd2l0aCB0aGUgdGVybSAibG9hZCBmaWx0ZXJpbmciDQo+ICAgIHVubGVzcyB3aGVu IGFzc29jaWF0ZWQgd2l0aCBvdGhlciBleHBsaWNpdCBjb250ZXh0Lg0KPiBJIHN1c3BlY3QgaXQg aXMgc3VwcG9zZWQgdG8gYmUNCj4gU2Vjb25kbHksIHNpbmNlIHdlIGFyZSBkZXNjcmliaW5nIGEg c3BlY2lmaWMgY29udHJvbA0KPiAgICBtZWNoYW5pc20gYmFzZWQgb24gZmlsdGVyaW5nLCB0aGUg dGVybSAibG9hZCBjb250cm9sIiBpbiB0aGlzDQo+ICAgIHNwZWNpZmljYXRpb24gaXMgdXNlZCBp bnRlci1jaGFuZ2VhYmx5IHdpdGggdGhlIHRlcm0gImxvYWQgZmlsdGVyaW5nIg0KPiAgICB1bmxl c3MgYXNzb2NpYXRlZCB3aXRoIG90aGVyIGV4cGxpY2l0IGNvbnRleHQuDQo+IC0tDQo+DQoNCnJp Z2h0DQoNCj4gSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgdGhpcyBzdGF0ZW1lbnQNCj4gVGhp cw0KPiAgICBzcGVjaWZpY2F0aW9uLCBob3dldmVyLCBkb2VzIG5vdCBwcmVjbHVkZSB0aGUgbG9h ZCBjb250cm9sIGRvY3VtZW50DQo+ICAgIGRlZmluZWQgaGVyZSAoU2VjdGlvbiA2KSB0byBiZSBl eHRlbmRlZCBpbiB0aGUgZnV0dXJlIGZvciBvdGhlciBmb3Jtcw0KPiAgICBvZiBjb250cm9sIGFz IGFwcHJvcHJpYXRlLg0KPiBXaGF0IHNvcnRzIG9mICJvdGhlciBmb3JtcyBvZiBjb250cm9sIiBh cmUgeW91IHJlZmVycmluZyB0bz8gIFByZXN1bWFibHkgbm90DQo+IHNlcnZpY2UgbGV2ZWwgYW5k IFFvUyBjb250cm9sLCBhcyB5b3UgaGF2ZQ0KPiBhbHJlYWR5IGRlZmluZWQgdGhlbSAob3IgYXQg bGVhc3QgcmVmZXJyZWQgdG8gdGhlbSkgYXMgImxvYWQgY29udHJvbCIgYnV0DQo+IG5vdCAib3Zl cmxvYWQgY29udHJvbCIuDQo+IC0tDQoNClllcywgaXQgY291bGQgYmUgY29uZnVzaW5nLCBzbyBJ IHJlbW92ZWQgdGhpcyBzZW50ZW5jZS4NCg0KPiAgU2VjdGlvbiAzDQo+IEkgdGhpbmsgdGhhdA0K PiBGb3IgZGVzdGluYXRpb24tc3BlY2lmaWMgb3ZlcmxvYWQgc2l0dWF0aW9ucywgdGhlIGxvYWQg ZmlsdGVyDQo+ICAgICAgIG5lZWRzIHRvIGJlIGFibGUgdG8gZGVzY3JpYmUgdGhlIGNhbGxlZS4N Cj4gc2hvdWxkIGJlDQo+IEZvciBkZXN0aW5hdGlvbi1zcGVjaWZpYyBvdmVybG9hZCBzaXR1YXRp b25zLCB0aGUgbG9hZCBmaWx0ZXINCj4gICAgICAgc2hvdWxkIGJlIGFibGUgdG8gc3BlY2lmeSB0 aGUgY2FsbGVlLg0KPiAtLQ0KDQphZ3JlZS4NCg0KPiBUaGlzIGJ1bGxldA0KPiAgVG8gYWRkcmVz cyBhY2NpZGVudGFsIGFuZCBpbnRlbnRpb25hbCBoaWdoLXZvbHVtZSBjYWxsIGdlbmVyYXRvcnMs DQo+ICAgICAgIHRoZSBsb2FkIGZpbHRlciBzaG91bGQgYWxsb3cgdG8gc3BlY2lmeSB0aGUgY2Fs bGVyLg0KPiBkb2VzIG5vdCB1c2UgY29ycmVjdCBncmFtbWFyLg0KPiBJIHN1c3BlY3QgeW91IG1l YW4NCj4gIFRvIGFkZHJlc3MgYWNjaWRlbnRhbCBhbmQgaW50ZW50aW9uYWwgaGlnaC12b2x1bWUg Y2FsbCBnZW5lcmF0b3JzLA0KPiAgICAgICB0aGUgbG9hZCBmaWx0ZXIgc2hvdWxkIGJlIGFibGUg dG8gIHNwZWNpZnkgdGhlIGNhbGxlci4NCj4gLS0NCg0KYWdyZWUNCg0KPiBXaXRoIHJlZ2FyZCB0 byB0aGlzIGJ1bGxldCwNCj4gICAgbyAgRm9yIHRlbGVwaG9uZSBudW1iZXJzLCBpdCBzaG91bGQg YmUgcG9zc2libGUgdG8gc3BlY2lmeSBwcmVmaXhlcw0KPiAgICAgICB3aGljaCBhbGxvdyBjb250 cm9sIG92ZXIgbGltaXRlZCByZWdpb25hbGx5LWZvY3VzZWQgb3ZlcmxvYWRzLg0KPiBUaGlzIGlz IHJlYWxseSBhbiBhc3N1bXB0aW9uIHJhdGhlciB0aGFuIGEgcmVxdWlyZW1lbnQuDQo+IEZ1cnRo ZXJtb3JlLCBJIGRvIG5vdCBiZWxpZXZlIGl0IGlzIHRydWUuICBJbiB0aGVzZSBkYXlzIG9mIG51 bWJlcg0KPiBwb3J0YWJpbGl0eSwgYW5kIHBlb3BsZSByZXRhaW5pbmcgdGhlaXIgb3JpZ2luYWwg bW9iaWxlDQo+IHBob25lIG51bWJlciwgYXMgdGhlaXIgcHJpbWFyeSBudW1iZXIsIHdoZW4gdGhl eSBtb3ZlIGFjcm9zcyB0aGUgY291bnRyeSwNCj4gdGhlIGNvcnJlbGF0aW9uIGJldHdlZW4gInRl bGVwaG9uZSBudW1iZXIgcHJlZml4Ig0KPiAoYWthIGFyZWEgY29kZSkgYW5kICJwaHlzaWNhbCBs b2NhdGlvbiIgaXMgcmFwaWRseSBkZWNyZWFzaW5nLg0KPiBJIGFncmVlIHRoYXQsZm9yIHJlZ2lv bmFsIGNhbGxpbmcgZXZlbnRzLCB5b3UgbmVlZCBhIHdheSBvZiBpZGVudGlmeWluZyB0aGUNCj4g Z2VvZ3JhcGhpY2FsIGxvY2F0aW9uIChvcmlnaW5hdGluZyBhbmQvb3INCj4gdGVybWluYXRpbmcp IHRvIGRldGVybWluZSB3aGljaCBjYWxscyB0byBmaWx0ZXIuICBCdXQgSSBkbyBub3QgdGhpbmsg dGhhdA0KPiBhcmVhIGNvZGVzIHdpbGwgY29udGludWUgdG8gYmUgdGhlIG1vc3QgZWZmZWN0aXZl DQo+IHdheSBvZiBkb2luZyB0aGlzLg0KPiBQZXJoYXBzIGFuIGFsdGVybmF0ZSB3b3JkaW5nIHdv dWxkIGJlDQo+ICAgIG8gIEl0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBzcGVjaWZ5IHBhcnRpY3Vs YXIgaW5mb3JtYXRpb24gaW4gdGhlIFNJUA0KPiBoZWFkZXJzIChlLmcuLCBwcmVmaXhlcyBpbiB0 ZWxlcGhvbmUgbnVtYmVycykNCj4gICAgICAgd2hpY2ggYWxsb3cgY29udHJvbCBvdmVyIGxpbWl0 ZWQgcmVnaW9uYWxseS1mb2N1c2VkIG92ZXJsb2Fkcw0KPiAtLS0NCg0KYWdyZWUNCg0KPiBzZWMg NC4yDQo+ICBpbiB0aGlzIHN0YXRlbWVudA0KPiAgYW5kIHRoYXQgbG9hZHMgYXJlIGFsbG9jYXRl ZCBpbiBhIHdheSB3aGljaA0KPiAgICBib3RoIHByZXZlbnRzIG92ZXJsb2FkIGFuZCBtaW5pbWl6 ZXMgdGhlIGxpa2VsaWhvb2Qgb2YgbmV0d29yaw0KPiAgICByZXNvdXJjZSB1bmRlci11dGlsaXph dGlvbi4NCj4gd291bGQgaXQgYmUgYmV0dGVyIHRvIHNheSAibWF4aW1pemVzIGVmZmVjdGl2ZSB0 aHJvdWdocHV0KGFrYSBnb29kcHV0KSINCj4gaW5zdGVhZCBvZiAibWluaW1pemVzIHRoZSBsaWtl bGlob29kIG9mIG5ldHdvcmsNCj4gICAgcmVzb3VyY2UgdW5kZXItdXRpbGl6YXRpb24uIj8NCj4g LS0tDQoNCmFncmVlDQoNCj4gc2VjIDQuMw0KPg0KPiBTaG91bGQgdGhpcw0KPiBJbiBvcmRlciBm b3IgbG9hZCBmaWx0ZXJzIHRvIGJlIHByb3Blcmx5IGRpc3RyaWJ1dGVkLCBlYWNoIFNJUCBwcm94 eQ0KPiAgICBzZXJ2ZXIgaW4gdGhlIG5ldHdvcmsgaXMgcmVxdWlyZWQgdG8gc3Vic2NyaWJlIHRv IHRoZSBsb2FkIGNvbnRyb2wNCj4gICAgZXZlbnQgcGFja2FnZSBmcm9tIGFsbCBpdHMgb3V0Z29p bmcgc2lnbmFsaW5nIG5laWdoYm9ycywga25vd24gYXMNCj4gICAgbm90aWZpZXJzIChTZWN0aW9u IDUuNikuDQo+IGJlDQo+IEluIG9yZGVyIGZvciBsb2FkIGZpbHRlcnMgdG8gYmUgcHJvcGVybHkg ZGlzdHJpYnV0ZWQsIGVhY2ggU0lQIHByb3h5DQo+ICAgIHNlcnZlciBpbiB0aGUgbmV0d29yayBT SE9VTEQgc3Vic2NyaWJlIHRvIHRoZSBsb2FkIGNvbnRyb2wNCj4gICAgZXZlbnQgcGFja2FnZSBm cm9tIGFsbCBpdHMgb3V0Z29pbmcgc2lnbmFsaW5nIG5laWdoYm9ycywga25vd24gYXMNCj4gICAg bm90aWZpZXJzIChTZWN0aW9uIDUuNikuDQo+ID8gKG5vdCBzdXJlIG15c2VsZikNCj4NCj4gLS0t DQoNCmFncmVlLg0KDQo+IEZvciBjYXNlIElJLCBwZXJoYXBzICJodXJyaWNhbmUiICh3aGljaCBo YXMgYSBtb3JlIHByZWRpY3RhYmxlLCBhbmQgbW9yZQ0KPiBncmFkdWFsLCBpbmNyZWFzZSBpbiB0 cmFmZmljKSB3b3VsZCBiZSBhIGJldHRlcg0KPiBleGFtcGxlIHRoYW4gImVhcnRocXVha2UiLCBk dWUgdG8gdGhlIGlzc3VlcyBtZW50aW9uZWQgYWJvdmUuDQo+IC0tDQo+IFNlYyA1LjMNCj4gSW4g c2VjIDQuNCB5b3Ugc2F5DQo+IEFub3RoZXIgaW1wb3J0YW50IGFzcGVjdCB0aGF0IGFmZmVjdHMg dGhlIGFwcGxpY2FiaWxpdHkgb2YgU0lQIGxvYWQNCj4gICAgZmlsdGVyaW5nIGlzIHRoYXQgYWxs IHBvc3NpYmxlIHNpZ25hbGluZyBzb3VyY2UgbmVpZ2hib3JzIG5lZWQgdG8NCj4gICAgcGFydGlj aXBhdGUgYW5kIGVuZm9yY2UgdGhlIGRlc2lnbmF0ZWQgZmlsdGVyLiAgT3RoZXJ3aXNlLCBhIHNp bmdsZQ0KPiAgICBub24tY29uZm9ybWluZyBuZWlnaGJvciBjb3VsZCBtYWtlIHRoZSB3aG9sZSBj b250cm9sIGVmZm9ydHMgdXNlbGVzcw0KPiAgICBieSBwdW1waW5nIGluIGV4Y2Vzc2l2ZSB0cmFm ZmljIHRvIG92ZXJsb2FkIHRoZSBzZXJ2ZXIuDQo+IEJ1dCBpbiBzZWN0aW9uIDUuMyB5b3Ugc2F5 DQo+IGEgc3Vic2NyaWJlciBtYXkgYmUgaW50ZXJlc3RlZCBpbiBzb21lDQo+ICAgIHNwZWNpZmlj IHR5cGVzIG9mIGxvYWQgY29udHJvbCBwb2xpY3kgb25seS4NCj4gTWF5YmUgSSBhbSBtaXN1bmRl cnN0YW5kaW5nIHdoYXQgeW91IG1lYW4gYnkgInR5cGVzIG9mIGxvYWQgY29udHJvbCBwb2xpY3ki LA0KPiBidXQgdGhlIHN0YXRlbWVudCBpbiA1LjMgKCJvbmx5IGludGVyZXN0ZWQgaW4NCj4gc29t ZSIpIHNlZW0gaW5jb25zaXN0ZW50IHdpdGggdGhlIHN0YXRlbWVudCBpbiA0LjMgKCJhbGwgbXVz dCBwYXJ0aWNpcGF0ZSIpLg0KPiBQZXJoYXBzIHlvdSBjb3VsZCBhZGQgYSBjbGFyaWZ5aW5nIHN0 YXRlbWVudC4NCj4gLS0tDQoNClNpbmNlIHRoZSBkZXRhaWxzIG9mIHRoZSBzdWJzY3JpcHRpb24g ZmlsdGVyIHNwZWNpZmljYXRpb24gYXJlIG5vdA0KZGVmaW5lZCBhbnl3YXksIEkgcmVtb3ZlZCB0 aGlzICJGb3IgZXhhbXBsZSIgc2VudGVuY2UgdG8gYXZvaWQgdGhlDQpjb25mdXNpb24uDQoNCg0K PiA1LjgNCj4gTW9kaWZpY2F0aW9ucyBvZiBleGlzdGluZyBsb2FkDQo+ICAgIGNvbnRyb2wgcG9s aWNpZXMgYXQgdGhlIHN1YnNjcmliZXIgaXMgcGVyZm9ybWVkIGFmdGVyIGRpcmVjdGx5DQo+ICAg IHJlY2VpdmluZyBub3RpZmljYXRpb25zIGNvbnRhaW5pbmcgdXBkYXRlZCBsb2FkIGNvbnRyb2wg cG9saWNpZXMuDQo+IEdyYW1tYXINCj4gZWl0aGVyDQo+IC4uLiBtb2RpZmljYXRpb25zIC4uLiBh cmUgLi4uDQo+IG9yDQo+IC4uLm1vZGlmaWNhdGlvbiAuLi5pcyAuLi4NCj4gYnV0IE5PVA0KPiAu Li4gbW9kaWZpY2F0aW9ucyAuLi4gaXMgLi4uDQo+IC0tLQ0KDQpyaWdodA0KDQo+IDUuMTENCj4g VGhpcyBzZW50ZW5jZQ0KPiAiQW5vdGhlciBmYWN0b3IgdXN1YWxseSBub3Qga25vd24gcHJlY2lz ZWx5IG9yIGlzDQo+ICAgIGNvbXB1dGVkIGF1dG9tYXRpY2FsbHkgaXMgdGhlIHZhbGlkaXR5IGR1 cmF0aW9uIG9mIHRoZSBsb2FkIGNvbnRyb2wNCj4gICAgZXZlbnQuIg0KPiBTZWVtcyB0byBiZSBh IGN1dCBhbmQgcGFzdGUgZXJyb3Igb2Ygc29tZSBzb3J0Lg0KPiAuLi4NCg0KQ2hhbmdlZCB0byAi ICBBbm90aGVyIGZhY3RvciB0aGF0IGlzIHVzdWFsbHkgbm90IGtub3duIHByZWNpc2VseSBvcg0K bmVlZHMgdG8gYmUgY29tcHV0ZWQgYXV0b21hdGljYWxseSBpcyB0aGUgdmFsaWRpdHkgZHVyYXRp b24gb2YgdGhlDQpsb2FkIGNvbnRyb2wgZXZlbnQuICAiDQoNCj4gOC4xDQo+IFNob3VsZCB0aGlz DQo+ICIuLi4gYWRtaW5pc3RyYXRpdmUgb3B0aW9uIGZvciByb3V0aW5nIGZhaWxlZA0KPiAgICBj YWxsIGF0dGVtcHRzIHRvIGVpdGhlciBSZWNvcmRlciBUb25lIG9yIGEgc3BlY2lhbCBhbm5vdW5j ZW1lbnQuLi4uIg0KPiBiZSAiUmVvcmRlciBUb25lIiBpbnN0ZWFkIG9mICJSZWNvcmRlciBUb25l Ij8NCj4NCj4NCg0KSSB0aGluayB0aGlzIGlzIHNvbWV0aGluZyBsaWtlIGEgcmVjb3JkaW5nIG1h Y2hpbmUgcGxheWluZyBzb21ldGhpbmcNCm1lc3NhZ2UsIGFtIEkgY29ycmVjdD8NCg0KdGhhbmtz DQoNCkNoYXJsZXMNCg0KDQo+IEphbmV0DQo+DQo+DQo+DQo+IC0tLS0tc2lwLW92ZXJsb2FkLWJv dW5jZXNAaWV0Zi5vcmcgd3JvdGU6IC0tLS0tDQo+DQo+IFRvOiBzaXAtb3ZlcmxvYWRAaWV0Zi5v cmcNCj4gRnJvbTogIlZpamF5IEsuIEd1cmJhbmkiDQo+IFNlbnQgYnk6IHNpcC1vdmVybG9hZC1i b3VuY2VzQGlldGYub3JnDQo+IERhdGU6IDA3LzI2LzIwMTIgMTI6MDNQTQ0KPiBDYzogc2hlbkBh dHQuY29tDQo+DQo+IFN1YmplY3Q6IFJlOiBbc2lwLW92ZXJsb2FkXSBBbGlnbm1lbnQgb2YgcHJp b3JpdHkgYW5kIGVtZXJnZW5jeSBjYWxsDQo+IGhhbmRsaW5nDQo+DQo+IE9uIDA3LzI2LzIwMTIg MTA6MjMgQU0sIERSQUdFLCBLZWl0aCAoS2VpdGgpIHdyb3RlOg0KPj4gSSBkbyBub3QgYmVsaWV2 ZSB5b3UgbmVlZCB0byBpbmNsdWRlIG90aGVyIGFydGlmYWN0cy4NCj4+DQo+PiBSYXRoZXIgb3Zl cmxvYWQtY29udHJvbCBsaXN0cyBib3RoIFJQSCBhbmQgc29zIFVSTiwgYW5kIHRoZSBldmVudA0K Pj4gcGFja2FnZSBsaXN0cyBvbmx5IFJQSC4NCj4NCj4gU28gaXQgaXMgYSBzaW1wbGUgbWF0dGVy IG9mIGVuc3VyaW5nIHRoYXQgdGhlIHRleHQgaW4NCj4gZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250 cm9sLWV2ZW50LXBhY2thZ2UgaXMgY29uc2lzdGVudCB3aXRoIHRoZQ0KPiB0ZXh0IGluIGRyYWZ0 LWlldGYtc29jLW92ZXJsb2FkLWNvbnRyb2w/DQo+DQo+IElmIHNvLCBDaGFybGVzIC0tLSBjYW4g eW91IHBsZWFzZSB0YWtlIGNhcmUgb2YgdGhpcyBpbg0KPiBkcmFmdC1pZXRmLXNvYy1sb2FkLWNv bnRyb2wtZXZlbnQtcGFja2FnZT8NCj4NCj4gVGhhbmtzLA0KPg0KPiAtIHZpamF5DQo+IC0tDQo+ IFZpamF5IEsuIEd1cmJhbmksIEJlbGwgTGFib3JhdG9yaWVzLCBBbGNhdGVsLUx1Y2VudA0KPiAx OTYwIEx1Y2VudCBMYW5lLCBSbS4gOUMtNTMzLCBOYXBlcnZpbGxlLCBJbGxpbm9pcyA2MDU2MyAo VVNBKQ0KPiBFbWFpbDogdmtnQHtiZWxsLWxhYnMuY29tLGFjbS5vcmd9IC8gdmlqYXkuZ3VyYmFu aUBhbGNhdGVsLWx1Y2VudC5jb20NCj4gV2ViOiAgIGh0dHA6Ly9lY3QuYmVsbC1sYWJzLmNvbS93 aG8vdmtnLw0KPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0DQo+IHNpcC1vdmVybG9hZEBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9h ZA0KPg0KPg0KPg0KPiBUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UNCj4gZGVsZXRlIHdpdGhvdXQgY29weWluZyBh bmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4NCj4gZGVsaXZl cnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9w ZXJhdGUgdG8gYmluZA0KPiBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVz cyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuDQo+IGFncmVlbWVudCBvciBnb3Zlcm5tZW50 IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwNCj4gZm9y IHN1Y2ggcHVycG9zZS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdA0KPiBzaXAtb3ZlcmxvYWRAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAtb3Zlcmxv YWQNCj4NCg0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2lu ZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6 IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8g YmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0 byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhw cmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCg0K DQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlz ZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxl c3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0Mg dG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNp dCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBl cm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCg0KDQpUaGlzIGlz IGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBl LW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29u dGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9y ZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVu IGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcg dGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0 ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku CgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_88CAD1D4E8773F42858B58CAA28272A0069343PEXCVZYM12corpora_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9c Oioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVm YXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHls ZT4NCjwhW2VuZGlmXS0tPjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQog QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3 MC44NXB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SSB0aGluayByZWNvcmRlciB0 b25lIGlzIGEgdG9uZSB0byBpbmRpY2F0ZSB0byB0aGUgY2FsbGVkIHBhcnR5IHRoYXQgdGhlIGNh bGxpbmcgcGFydHkgaXMgcmVjb3JkaW5nIHRoZSBjb252ZXJzYXRpb24uIFNvIEkgZG9u4oCZdCB0 aGluayB0aGlzIHRvbmUNCiB3b3VsZCBiZSBhcHByb3ByaWF0ZSBpbiB0aGUgY2FzZSBvZiBjYWxs IGZhaWx1cmUgZHVlIHRvIG92ZXJsb2FkIGNvbnRyb2wuIEFuIElUVSBFLjE4MiBzcGVjaWFsIGlu Zm9ybWF0aW9uIHRvbmUgd291bGQgcmF0aGVyIGJlIHVzZWQgaW4gdGhpcyBjYXNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj4vQkM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNt IDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gc2lwLW92ZXJsb2FkLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZ10NCjxiPkRl IGxhIHBhcnQgZGU8L2I+IEphbmV0IFAgR3Vubjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBq ZXVkaSAyIGFvw7t0IDIwMTIgMTk6MDI8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IGtlaXRoLmRyYWdl QGFsY2F0ZWwtbHVjZW50LmNvbTxicj4NCjxiPkNjJm5ic3A7OjwvYj4gc2lwLW92ZXJsb2FkQGll dGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogW3NpcC1vdmVybG9hZF0gRXZlbnkg cGFja2FnZSB3YXMgQWxpZ25tZW50IG9mIHByaW9yaXR5IGFuZCBlbWVyZ2VuY3kgY2FsbCBoYW5k bGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkluIHRoYXQgY2FzZSwgdGhlJm5ic3A7RXZl bnQgcGFja2FnZSBkcmFmdCBzaG91bGQgdXNlIHRoZSBJVFUgdGVybXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldo YXQgYXJlIHRoZSBlcXVpdmFsZW50IElUVSB0ZXJtcz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFuZXQmbmJzcDs8 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izk5MDA5OSI+LS0tLS0mcXVvdDtEUkFHRSwg S2VpdGggKEtlaXRoKSZxdW90OyAmbHQ7a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tJmd0 OyB3cm90ZTogLS0tLS08L3NwYW4+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmxh Y2sgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDsNCm1hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UbzogSmFuZXQgUCBHdW5uL1VTQS9DU0NAQ1NDPGJyPg0K RnJvbTogJnF1b3Q7RFJBR0UsIEtlaXRoIChLZWl0aCkmcXVvdDsgJmx0O2tlaXRoLmRyYWdlQGFs Y2F0ZWwtbHVjZW50LmNvbSZndDs8YnI+DQpEYXRlOiAwOC8wMS8yMDEyIDExOjI1QU08YnI+DQpT dWJqZWN0OiBSRTogW3NpcC1vdmVybG9hZF0gQWxpZ25tZW50IG9mIHByaW9yaXR5IGFuZCBlbWVy Z2VuY3kgY2FsbCBoYW5kbGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+UmVj b3JkZXIgdG9uZSBpcyBub3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5OZWl0aGVyIGlzIHJlb3JkZXIgdG9uZSBpbiB0aGUgcXVp Y2sgc2tpbiBJIGRpZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOm5hdnkiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpj ZW50ZXIiPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIgYWxp Z249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEphbmV0DQogUCBHdW5uIFtt YWlsdG86amd1bm42QGNzYy5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiAwMSBBdWd1c3QgMjAxMiAx MDowNjxicj4NCjxiPlRvOjwvYj4gRFJBR0UsIEtlaXRoIChLZWl0aCk8YnI+DQo8Yj5DYzo8L2I+ IGNoYXJsZXNAY3MuY29sdW1iaWEuZWR1OyBzaGVuQGF0dC5jb207IHNpcC1vdmVybG9hZEBpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NpcC1vdmVybG9hZF0gQWxpZ25tZW50IG9m IHByaW9yaXR5IGFuZCBlbWVyZ2VuY3kgY2FsbCBoYW5kbGluZzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Tb3VuZHMgZ29vZCB0byBtZS4gSXMgJnF1b3Q7 UmVjb3JkZXIgdG9uZSZxdW90OyBkZWZpbmVkIHRoZXJlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SmFuZXQ8 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izk5MDA5OSI+LS0tLS0mcXVvdDtEUkFHRSwg S2VpdGggKEtlaXRoKSZxdW90OyAmbHQ7a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tJmd0 OyB3cm90ZTogLS0tLS08L3NwYW4+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmxh Y2sgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdDsNCm1hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VG86IEphbmV0IFAg R3Vubi9VU0EvQ1NDQENTQywgJnF1b3Q7Y2hhcmxlc0Bjcy5jb2x1bWJpYS5lZHUmcXVvdDsgJmx0 O2NoYXJsZXNAY3MuY29sdW1iaWEuZWR1Jmd0Ozxicj4NCkZyb206ICZxdW90O0RSQUdFLCBLZWl0 aCAoS2VpdGgpJnF1b3Q7ICZsdDtrZWl0aC5kcmFnZUBhbGNhdGVsLWx1Y2VudC5jb20mZ3Q7PGJy Pg0KRGF0ZTogMDcvMzAvMjAxMiAwNjoxOVBNPGJyPg0KQ2M6ICZxdW90O3NpcC1vdmVybG9hZEBp ZXRmLm9yZyZxdW90OyAmbHQ7c2lwLW92ZXJsb2FkQGlldGYub3JnJmd0OywgJnF1b3Q7c2hlbkBh dHQuY29tJnF1b3Q7ICZsdDtzaGVuQGF0dC5jb20mZ3Q7PGJyPg0KU3ViamVjdDogUkU6IFtzaXAt b3ZlcmxvYWRdIEFsaWdubWVudCBvZiBwcmlvcml0eSBhbmQgZW1lcmdlbmN5IGNhbGwgaGFuZGxp bmc8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPkNhbiBJIHN1 Z2dlc3QgdGhhdCB3ZSBzdGljayB0byB0aGUgdGVybWlub2xvZ3kgYXZhaWxhYmxlIGluIElUVS1U IFJlY29tbWVuZGF0aW9uIEUuMTgyIChhbmQgRS4xODApIGFzDQogdGhpcyBVLlMuIHRlcm1pbm9s b2d5IGlzIHZlcnkgc3BlY2lmaWMgdG8gdGhlIFUuUy4gYW5kIG90aGVyIHRlcm1zIGFyZSB1c2Vk IGVsc2V3aGVyZSBpbiB3b3JsZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPktlaXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnki PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXIiPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAw JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNpcC1vdmVybG9h ZC1ib3VuY2VzQGlldGYub3JnDQogW21haWx0bzpzaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9y Z10gPGI+T24gQmVoYWxmIE9mIDwvYj5KYW5ldCBQIEd1bm48YnI+DQo8Yj5TZW50OjwvYj4gMzAg SnVseSAyMDEyIDIzOjAzPGJyPg0KPGI+VG86PC9iPiBjaGFybGVzQGNzLmNvbHVtYmlhLmVkdTxi cj4NCjxiPkNjOjwvYj4gc2lwLW92ZXJsb2FkQGlldGYub3JnOyBzaGVuQGF0dC5jb208YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXAtb3ZlcmxvYWRdIEFsaWdubWVudCBvZiBwcmlvcml0eSBh bmQgZW1lcmdlbmN5IGNhbGwgaGFuZGxpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XUlQgdGhlIGxhc3QgY29t bWVudCAtICZxdW90O1Jlb3JkZXIgdG9uZSZxdW90OyBpcyBhbHNvIGtub3duIChhdCBsZWFzdCBp biB0aGUgVVMpIGFzICZxdW90O2Zhc3QgYnVzeSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+SSBhZ3JlZSB0aGF0IHRoZXJlIG1pZ2h0IGJlICZxdW90O2Fubm91bmNlbWVu dHMmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+YnV0IEkgZG8gbm90IGtu b3cgd2hhdCB5b3UgbWVhbiBieSAmcXVvdDtSZWNvcmRlciB0b25lJnF1b3Q7LiBEbyB5b3UgbWVh biB0aGUgdG9uZSB0aGF0IHNvbWV0aW1lcyBjb21lcyBvbiBqdXN0IEJFRk9SRSBhbg0KIGFubm91 bmNlbWVudD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkphbmV0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojOTkwMDk5Ij4tLS0tLWNoYXJsZXMubmV3 eW9ya0BnbWFpbC5jb20gd3JvdGU6IC0tLS0tPC9zcGFuPiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibGFjayAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDMuMHB0Ow0KbWFyZ2lu LWxlZnQ6Mi45cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPlRvOiBKYW5ldCBQIEd1bm4vVVNBL0NTQ0BDU0M8YnI+DQpGcm9tOiBDaGFybGVzIFNo ZW4gPGJyPg0KU2VudCBieTogY2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbTxicj4NCkRhdGU6IDA3 LzI5LzIwMTIgMTE6MzVQTTxicj4NCkNjOiB2a2dAYmVsbC1sYWJzLmNvbSwgc2lwLW92ZXJsb2Fk QGlldGYub3JnLCBzaGVuQGF0dC5jb208YnI+DQpTdWJqZWN0OiBSZTogW3NpcC1vdmVybG9hZF0g QWxpZ25tZW50IG9mIHByaW9yaXR5IGFuZCBlbWVyZ2VuY3kgY2FsbCBoYW5kbGluZzxicj4NCjxi cj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+SGkgSmFuZXQsIHRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlv dXIgZGV0YWlsZWQgY29tbWVudHMhIEkndmU8YnI+DQppbmNvcnBvcmF0ZWQgdGhlbSBpbiB0aGUg bmV3IHJldmlzaW9uLiBBbHNvIHBsZWFzZSBzZWUgcmVzcG9uc2U8YnI+DQppbmxpbmUuPGJyPg0K PGJyPg0KT24gU3VuLCBKdWwgMjksIDIwMTIgYXQgNTo0OSBQTSwgSmFuZXQgUCBHdW5uICZsdDtq Z3VubjZAY3NjLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyBJIGFncmVlIHdpdGggS2VpdGgncyBj b21tZW50cyBhYm91dCBwcmlvcml0eSBhbmQgZW1lcmdlbmN5IGNhbGxzLjxicj4NCiZndDs8YnI+ DQo8YnI+DQpkb25lPGJyPg0KPGJyPg0KJmd0OyBJIGFsc28gaGF2ZSBhIG51bWJlciBvZiBvdGhl ciBjb21tZW50cywgbW9zdGx5IGVkaXRvcmlhbCAoSSBhcG9sb2dpemUgZm9yIG15PGJyPg0KJmd0 OyBsYXRlbmVzcyBpbiByZXNwb25kaW5nKS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg SW50cm9kdWN0aW9uIHNob3VsZCBzdHJlc3MgdGhhdCB0aGlzIGFwcHJvYWNoIGlzIGZvciBzaXR1 YXRpb25zIHdoZXJlIHlvdTxicj4NCiZndDsgY2FuIHByZWRpY3QsIGluIGFkdmFuY2UsIGEgbGlr ZWx5IHRyYWZmaWMgc3VyZ2UsPGJyPg0KJmd0OyBhbmQgaXRzIHNvdXJjZS9kZXN0aW5hdGlvbiBk aXN0cmlidXRpb24uICZuYnNwO0ZvciBpbnN0YW5jZSwgaXQgaXMgYXBwcm9wcmlhdGU8YnI+DQom Z3Q7IGZvciBhIG1hc3MtcGhvbmUtdm90aW5nIGV2ZW50LCBNb3RoZXIncyBEYXksIE5ldzxicj4N CiZndDsgWWVhcnMsIGFuZCBldmVuIGEgaHVycmljYW5lICh0aGVyZSBpcyB1c3VhbGx5IHNvbWUg YWR2YW5jZSBub3RpY2UpLjxicj4NCiZndDsgSG93ZXZlciwgaXQgaXMgbGVzcyBsaWtlbHkgdG8g YmUgZWZmZWN0aXZlIGZvciB0aGUgaW5pdGlhbCBwaGFzZSBvZjxicj4NCiZndDsgdW5wcmVkaWN0 ZWQvdW5wcmVkaWN0YWJsZSBtYXNzIGNhbGxpbmcgZXZlbnRzLCBzdWNoIGFzPGJyPg0KJmd0OyBl YXJ0aHF1YWtlcyBvciB0ZXJyb3Jpc3QgYXR0YWNrcy4gJm5ic3A7SW4gdGhlc2UgbGF0dGVyIGNh c2VzLCB0aGUgbG9jYWwgdHJhZmZpYzxicj4NCiZndDsgbG9hZCBtYXkgcGVhayBieSBtb3JlIHRo YW4gYW4gb3JkZXIgb2YgbWFnbml0dWRlPGJyPg0KJmd0OyBpbiBtaW51dGVzLCBpZiBub3Qgc2Vj b25kcy4gJm5ic3A7VGhpcyBkb2VzIG5vdCBhbGxvdyB0aW1lIHRvIGVpdGhlcjxicj4NCiZndDsg ZWZmZWN0aXZlbHkgaWRlbnRpZnkgdGhlIGZpbHRlcnMgbmVlZGVkLCBub3IgZGlzdHJpYnV0ZSB0 aGVuIHRvIHRoZTxicj4NCiZndDsgYXBwcm9wcmlhdGUgc2VydmVycywgc29vbiBlbm91Z2ggdG8g cHJldmVudCBjb25nZXN0aW9uPGJyPg0KJmd0OyBhdHRhY2suICZuYnNwO09uY2Ugb3RoZXIsIG1v cmUgaW1tZWRpYXRlLCB0ZWNobmlxdWVzIChzdWNoIGFzIHRoZSBsb3NzLWJhc2VkIG9yPGJyPg0K Jmd0OyByYXRlLWJhc2VkICZuYnNwO21ldGhvZHMpIGhhdmUgcHJldmVudGVkIHRoZSBpbml0aWFs PGJyPg0KJmd0OyBjb25nZXN0aW9uIGNvbGxhcHNlLCB0aGUgZXZlbnQgcGFja2FnZSBjYW4gYmUg dXNlZCB0byBlZmZlY3RpdmVseSBjb250cm9sPGJyPg0KJmd0OyB0aGUgY29udGludWluZyBvdmVy bG9hZC48YnI+DQomZ3Q7IC0tPGJyPg0KPGJyPg0KYWdyZWUuPGJyPg0KPGJyPg0KJmd0OyBUaGlz IHNlbnRlbmNlPGJyPg0KJmd0OyAmbmJzcDtMb2FkIGZpbHRlcmluZyB3b3JrcyBiZXN0IGlmIGl0 IHByZXZlbnRzIGNhbGxzIGFzIGNsb3NlIHRvPGJyPg0KJmd0OyAmbmJzcDt0aGUgdXNlciBhZ2Vu dCBjbGllbnRzIGFzIHBvc3NpYmxlLjxicj4NCiZndDsgY291bGQgYmUgY2xhcmlmaWVkIGJ5IGlu Y2x1ZGluZyB0aGUgd29yZCAmcXVvdDtvcmlnaW5hdGluZyZxdW90Ozxicj4NCiZndDsgJm5ic3A7 TG9hZCBmaWx0ZXJpbmcgd29ya3MgYmVzdCBpZiBpdCBwcmV2ZW50cyBjYWxscyBhcyBjbG9zZSB0 bzxicj4NCiZndDsgJm5ic3A7dGhlIG9yaWdpbmF0aW5nIHVzZXIgYWdlbnQgY2xpZW50cyBhcyBw b3NzaWJsZS48YnI+DQomZ3Q7IC0tPGJyPg0KPGJyPg0KcmlnaHQ8YnI+DQo8YnI+DQomZ3Q7IFRo ZXJlIGFwcGVhcnMgdG8gYmUgYSBjdXQgYW5kIHBhc3QgZXJyb3IgaGVyZTxicj4NCiZndDsgU2Vj b25kbHksIHNpbmNlIHdlIGFyZSBkZXNjcmliaW5nIGEgc3BlY2lmaWMgY29udHJvbDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO21lY2hhbmlzbSBiYXNlZCBvbiBmaWx0ZXJpbmcsIHRoZSB0ZXJtICZx dW90O2xvYWQgY29udHJvbCZxdW90OyBpbiB0aGlzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c3Bl Y2lmaWNhdGlvbiBpcyB1c2VkIGludGVyLWNoYW5nZWFibHkgd2l0aCB0aGUgdGVybSAmcXVvdDts b2FkIGZpbHRlcmluZyZxdW90Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3VubGVzcyB3aGVuIGFz c29jaWF0ZWQgd2l0aCBvdGhlciBleHBsaWNpdCBjb250ZXh0Ljxicj4NCiZndDsgSSBzdXNwZWN0 IGl0IGlzIHN1cHBvc2VkIHRvIGJlPGJyPg0KJmd0OyBTZWNvbmRseSwgc2luY2Ugd2UgYXJlIGRl c2NyaWJpbmcgYSBzcGVjaWZpYyBjb250cm9sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7bWVjaGFu aXNtIGJhc2VkIG9uIGZpbHRlcmluZywgdGhlIHRlcm0gJnF1b3Q7bG9hZCBjb250cm9sJnF1b3Q7 IGluIHRoaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtzcGVjaWZpY2F0aW9uIGlzIHVzZWQgaW50 ZXItY2hhbmdlYWJseSB3aXRoIHRoZSB0ZXJtICZxdW90O2xvYWQgZmlsdGVyaW5nJnF1b3Q7PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7dW5sZXNzIGFzc29jaWF0ZWQgd2l0aCBvdGhlciBleHBsaWNp dCBjb250ZXh0Ljxicj4NCiZndDsgLS08YnI+DQomZ3Q7PGJyPg0KPGJyPg0KcmlnaHQ8YnI+DQo8 YnI+DQomZ3Q7IEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoaXMgc3RhdGVtZW50PGJyPg0K Jmd0OyBUaGlzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c3BlY2lmaWNhdGlvbiwgaG93ZXZlciwg ZG9lcyBub3QgcHJlY2x1ZGUgdGhlIGxvYWQgY29udHJvbCBkb2N1bWVudDxicj4NCiZndDsgJm5i c3A7ICZuYnNwO2RlZmluZWQgaGVyZSAoU2VjdGlvbiA2KSB0byBiZSBleHRlbmRlZCBpbiB0aGUg ZnV0dXJlIGZvciBvdGhlciBmb3Jtczxicj4NCiZndDsgJm5ic3A7ICZuYnNwO29mIGNvbnRyb2wg YXMgYXBwcm9wcmlhdGUuPGJyPg0KJmd0OyBXaGF0IHNvcnRzIG9mICZxdW90O290aGVyIGZvcm1z IG9mIGNvbnRyb2wmcXVvdDsgYXJlIHlvdSByZWZlcnJpbmcgdG8/ICZuYnNwO1ByZXN1bWFibHkg bm90PGJyPg0KJmd0OyBzZXJ2aWNlIGxldmVsIGFuZCBRb1MgY29udHJvbCwgYXMgeW91IGhhdmU8 YnI+DQomZ3Q7IGFscmVhZHkgZGVmaW5lZCB0aGVtIChvciBhdCBsZWFzdCByZWZlcnJlZCB0byB0 aGVtKSBhcyAmcXVvdDtsb2FkIGNvbnRyb2wmcXVvdDsgYnV0PGJyPg0KJmd0OyBub3QgJnF1b3Q7 b3ZlcmxvYWQgY29udHJvbCZxdW90Oy48YnI+DQomZ3Q7IC0tPGJyPg0KPGJyPg0KWWVzLCBpdCBj b3VsZCBiZSBjb25mdXNpbmcsIHNvIEkgcmVtb3ZlZCB0aGlzIHNlbnRlbmNlLjxicj4NCjxicj4N CiZndDsgJm5ic3A7U2VjdGlvbiAzPGJyPg0KJmd0OyBJIHRoaW5rIHRoYXQ8YnI+DQomZ3Q7IEZv ciBkZXN0aW5hdGlvbi1zcGVjaWZpYyBvdmVybG9hZCBzaXR1YXRpb25zLCB0aGUgbG9hZCBmaWx0 ZXI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5lZWRzIHRvIGJlIGFibGUgdG8gZGVz Y3JpYmUgdGhlIGNhbGxlZS48YnI+DQomZ3Q7IHNob3VsZCBiZTxicj4NCiZndDsgRm9yIGRlc3Rp bmF0aW9uLXNwZWNpZmljIG92ZXJsb2FkIHNpdHVhdGlvbnMsIHRoZSBsb2FkIGZpbHRlcjxicj4N CiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2hvdWxkIGJlIGFibGUgdG8gc3BlY2lmeSB0aGUg Y2FsbGVlLjxicj4NCiZndDsgLS08YnI+DQo8YnI+DQphZ3JlZS48YnI+DQo8YnI+DQomZ3Q7IFRo aXMgYnVsbGV0PGJyPg0KJmd0OyAmbmJzcDtUbyBhZGRyZXNzIGFjY2lkZW50YWwgYW5kIGludGVu dGlvbmFsIGhpZ2gtdm9sdW1lIGNhbGwgZ2VuZXJhdG9ycyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHRoZSBsb2FkIGZpbHRlciBzaG91bGQgYWxsb3cgdG8gc3BlY2lmeSB0aGUgY2Fs bGVyLjxicj4NCiZndDsgZG9lcyBub3QgdXNlIGNvcnJlY3QgZ3JhbW1hci48YnI+DQomZ3Q7IEkg c3VzcGVjdCB5b3UgbWVhbjxicj4NCiZndDsgJm5ic3A7VG8gYWRkcmVzcyBhY2NpZGVudGFsIGFu ZCBpbnRlbnRpb25hbCBoaWdoLXZvbHVtZSBjYWxsIGdlbmVyYXRvcnMsPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB0aGUgbG9hZCBmaWx0ZXIgc2hvdWxkIGJlIGFibGUgdG8gJm5ic3A7 c3BlY2lmeSB0aGUgY2FsbGVyLjxicj4NCiZndDsgLS08YnI+DQo8YnI+DQphZ3JlZTxicj4NCjxi cj4NCiZndDsgV2l0aCByZWdhcmQgdG8gdGhpcyBidWxsZXQsPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7byAmbmJzcDtGb3IgdGVsZXBob25lIG51bWJlcnMsIGl0IHNob3VsZCBiZSBwb3NzaWJsZSB0 byBzcGVjaWZ5IHByZWZpeGVzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3aGljaCBh bGxvdyBjb250cm9sIG92ZXIgbGltaXRlZCByZWdpb25hbGx5LWZvY3VzZWQgb3ZlcmxvYWRzLjxi cj4NCiZndDsgVGhpcyBpcyByZWFsbHkgYW4gYXNzdW1wdGlvbiByYXRoZXIgdGhhbiBhIHJlcXVp cmVtZW50Ljxicj4NCiZndDsgRnVydGhlcm1vcmUsIEkgZG8gbm90IGJlbGlldmUgaXQgaXMgdHJ1 ZS4gJm5ic3A7SW4gdGhlc2UgZGF5cyBvZiBudW1iZXI8YnI+DQomZ3Q7IHBvcnRhYmlsaXR5LCBh bmQgcGVvcGxlIHJldGFpbmluZyB0aGVpciBvcmlnaW5hbCBtb2JpbGU8YnI+DQomZ3Q7IHBob25l IG51bWJlciwgYXMgdGhlaXIgcHJpbWFyeSBudW1iZXIsIHdoZW4gdGhleSBtb3ZlIGFjcm9zcyB0 aGUgY291bnRyeSw8YnI+DQomZ3Q7IHRoZSBjb3JyZWxhdGlvbiBiZXR3ZWVuICZxdW90O3RlbGVw aG9uZSBudW1iZXIgcHJlZml4JnF1b3Q7PGJyPg0KJmd0OyAoYWthIGFyZWEgY29kZSkgYW5kICZx dW90O3BoeXNpY2FsIGxvY2F0aW9uJnF1b3Q7IGlzIHJhcGlkbHkgZGVjcmVhc2luZy48YnI+DQom Z3Q7IEkgYWdyZWUgdGhhdCxmb3IgcmVnaW9uYWwgY2FsbGluZyBldmVudHMsIHlvdSBuZWVkIGEg d2F5IG9mIGlkZW50aWZ5aW5nIHRoZTxicj4NCiZndDsgZ2VvZ3JhcGhpY2FsIGxvY2F0aW9uIChv cmlnaW5hdGluZyBhbmQvb3I8YnI+DQomZ3Q7IHRlcm1pbmF0aW5nKSB0byBkZXRlcm1pbmUgd2hp Y2ggY2FsbHMgdG8gZmlsdGVyLiAmbmJzcDtCdXQgSSBkbyBub3QgdGhpbmsgdGhhdDxicj4NCiZn dDsgYXJlYSBjb2RlcyB3aWxsIGNvbnRpbnVlIHRvIGJlIHRoZSBtb3N0IGVmZmVjdGl2ZTxicj4N CiZndDsgd2F5IG9mIGRvaW5nIHRoaXMuPGJyPg0KJmd0OyBQZXJoYXBzIGFuIGFsdGVybmF0ZSB3 b3JkaW5nIHdvdWxkIGJlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7byAmbmJzcDtJdCBzaG91bGQg YmUgcG9zc2libGUgdG8gc3BlY2lmeSBwYXJ0aWN1bGFyIGluZm9ybWF0aW9uIGluIHRoZSBTSVA8 YnI+DQomZ3Q7IGhlYWRlcnMgKGUuZy4sIHByZWZpeGVzIGluIHRlbGVwaG9uZSBudW1iZXJzKTxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgd2hpY2ggYWxsb3cgY29udHJvbCBvdmVyIGxp bWl0ZWQgcmVnaW9uYWxseS1mb2N1c2VkIG92ZXJsb2Fkczxicj4NCiZndDsgLS0tPGJyPg0KPGJy Pg0KYWdyZWU8YnI+DQo8YnI+DQomZ3Q7IHNlYyA0LjI8YnI+DQomZ3Q7ICZuYnNwO2luIHRoaXMg c3RhdGVtZW50PGJyPg0KJmd0OyAmbmJzcDthbmQgdGhhdCBsb2FkcyBhcmUgYWxsb2NhdGVkIGlu IGEgd2F5IHdoaWNoPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Ym90aCBwcmV2ZW50cyBvdmVybG9h ZCBhbmQgbWluaW1pemVzIHRoZSBsaWtlbGlob29kIG9mIG5ldHdvcms8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDtyZXNvdXJjZSB1bmRlci11dGlsaXphdGlvbi48YnI+DQomZ3Q7IHdvdWxkIGl0IGJl IGJldHRlciB0byBzYXkgJnF1b3Q7bWF4aW1pemVzIGVmZmVjdGl2ZSB0aHJvdWdocHV0KGFrYSBn b29kcHV0KSZxdW90Ozxicj4NCiZndDsgaW5zdGVhZCBvZiAmcXVvdDttaW5pbWl6ZXMgdGhlIGxp a2VsaWhvb2Qgb2YgbmV0d29yazxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3Jlc291cmNlIHVuZGVy LXV0aWxpemF0aW9uLiZxdW90Oz88YnI+DQomZ3Q7IC0tLTxicj4NCjxicj4NCmFncmVlPGJyPg0K PGJyPg0KJmd0OyBzZWMgNC4zPGJyPg0KJmd0Ozxicj4NCiZndDsgU2hvdWxkIHRoaXM8YnI+DQom Z3Q7IEluIG9yZGVyIGZvciBsb2FkIGZpbHRlcnMgdG8gYmUgcHJvcGVybHkgZGlzdHJpYnV0ZWQs IGVhY2ggU0lQIHByb3h5PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7c2VydmVyIGluIHRoZSBuZXR3 b3JrIGlzIHJlcXVpcmVkIHRvIHN1YnNjcmliZSB0byB0aGUgbG9hZCBjb250cm9sPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ZXZlbnQgcGFja2FnZSBmcm9tIGFsbCBpdHMgb3V0Z29pbmcgc2lnbmFs aW5nIG5laWdoYm9ycywga25vd24gYXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtub3RpZmllcnMg KFNlY3Rpb24gNS42KS48YnI+DQomZ3Q7IGJlPGJyPg0KJmd0OyBJbiBvcmRlciBmb3IgbG9hZCBm aWx0ZXJzIHRvIGJlIHByb3Blcmx5IGRpc3RyaWJ1dGVkLCBlYWNoIFNJUCBwcm94eTxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO3NlcnZlciBpbiB0aGUgbmV0d29yayBTSE9VTEQgc3Vic2NyaWJlIHRv IHRoZSBsb2FkIGNvbnRyb2w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtldmVudCBwYWNrYWdlIGZy b20gYWxsIGl0cyBvdXRnb2luZyBzaWduYWxpbmcgbmVpZ2hib3JzLCBrbm93biBhczxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO25vdGlmaWVycyAoU2VjdGlvbiA1LjYpLjxicj4NCiZndDsgPyAobm90 IHN1cmUgbXlzZWxmKTxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLTxicj4NCjxicj4NCmFncmVlLjxi cj4NCjxicj4NCiZndDsgRm9yIGNhc2UgSUksIHBlcmhhcHMgJnF1b3Q7aHVycmljYW5lJnF1b3Q7 ICh3aGljaCBoYXMgYSBtb3JlIHByZWRpY3RhYmxlLCBhbmQgbW9yZTxicj4NCiZndDsgZ3JhZHVh bCwgaW5jcmVhc2UgaW4gdHJhZmZpYykgd291bGQgYmUgYSBiZXR0ZXI8YnI+DQomZ3Q7IGV4YW1w bGUgdGhhbiAmcXVvdDtlYXJ0aHF1YWtlJnF1b3Q7LCBkdWUgdG8gdGhlIGlzc3VlcyBtZW50aW9u ZWQgYWJvdmUuPGJyPg0KJmd0OyAtLTxicj4NCiZndDsgU2VjIDUuMzxicj4NCiZndDsgSW4gc2Vj IDQuNCB5b3Ugc2F5PGJyPg0KJmd0OyBBbm90aGVyIGltcG9ydGFudCBhc3BlY3QgdGhhdCBhZmZl Y3RzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIFNJUCBsb2FkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ZmlsdGVyaW5nIGlzIHRoYXQgYWxsIHBvc3NpYmxlIHNpZ25hbGluZyBzb3VyY2UgbmVpZ2hib3Jz IG5lZWQgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtwYXJ0aWNpcGF0ZSBhbmQgZW5mb3JjZSB0 aGUgZGVzaWduYXRlZCBmaWx0ZXIuICZuYnNwO090aGVyd2lzZSwgYSBzaW5nbGU8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDtub24tY29uZm9ybWluZyBuZWlnaGJvciBjb3VsZCBtYWtlIHRoZSB3aG9s ZSBjb250cm9sIGVmZm9ydHMgdXNlbGVzczxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2J5IHB1bXBp bmcgaW4gZXhjZXNzaXZlIHRyYWZmaWMgdG8gb3ZlcmxvYWQgdGhlIHNlcnZlci48YnI+DQomZ3Q7 IEJ1dCBpbiBzZWN0aW9uIDUuMyB5b3Ugc2F5PGJyPg0KJmd0OyBhIHN1YnNjcmliZXIgbWF5IGJl IGludGVyZXN0ZWQgaW4gc29tZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljIHR5cGVz IG9mIGxvYWQgY29udHJvbCBwb2xpY3kgb25seS48YnI+DQomZ3Q7IE1heWJlIEkgYW0gbWlzdW5k ZXJzdGFuZGluZyB3aGF0IHlvdSBtZWFuIGJ5ICZxdW90O3R5cGVzIG9mIGxvYWQgY29udHJvbCBw b2xpY3kmcXVvdDssPGJyPg0KJmd0OyBidXQgdGhlIHN0YXRlbWVudCBpbiA1LjMgKCZxdW90O29u bHkgaW50ZXJlc3RlZCBpbjxicj4NCiZndDsgc29tZSZxdW90Oykgc2VlbSBpbmNvbnNpc3RlbnQg d2l0aCB0aGUgc3RhdGVtZW50IGluIDQuMyAoJnF1b3Q7YWxsIG11c3QgcGFydGljaXBhdGUmcXVv dDspLjxicj4NCiZndDsgUGVyaGFwcyB5b3UgY291bGQgYWRkIGEgY2xhcmlmeWluZyBzdGF0ZW1l bnQuPGJyPg0KJmd0OyAtLS08YnI+DQo8YnI+DQpTaW5jZSB0aGUgZGV0YWlscyBvZiB0aGUgc3Vi c2NyaXB0aW9uIGZpbHRlciBzcGVjaWZpY2F0aW9uIGFyZSBub3Q8YnI+DQpkZWZpbmVkIGFueXdh eSwgSSByZW1vdmVkIHRoaXMgJnF1b3Q7Rm9yIGV4YW1wbGUmcXVvdDsgc2VudGVuY2UgdG8gYXZv aWQgdGhlPGJyPg0KY29uZnVzaW9uLjxicj4NCjxicj4NCjxicj4NCiZndDsgNS44PGJyPg0KJmd0 OyBNb2RpZmljYXRpb25zIG9mIGV4aXN0aW5nIGxvYWQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtj b250cm9sIHBvbGljaWVzIGF0IHRoZSBzdWJzY3JpYmVyIGlzIHBlcmZvcm1lZCBhZnRlciBkaXJl Y3RseTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3JlY2VpdmluZyBub3RpZmljYXRpb25zIGNvbnRh aW5pbmcgdXBkYXRlZCBsb2FkIGNvbnRyb2wgcG9saWNpZXMuPGJyPg0KJmd0OyBHcmFtbWFyPGJy Pg0KJmd0OyBlaXRoZXI8YnI+DQomZ3Q7IC4uLiBtb2RpZmljYXRpb25zIC4uLiBhcmUgLi4uPGJy Pg0KJmd0OyBvcjxicj4NCiZndDsgLi4ubW9kaWZpY2F0aW9uIC4uLmlzIC4uLjxicj4NCiZndDsg YnV0IE5PVDxicj4NCiZndDsgLi4uIG1vZGlmaWNhdGlvbnMgLi4uIGlzIC4uLjxicj4NCiZndDsg LS0tPGJyPg0KPGJyPg0KcmlnaHQ8YnI+DQo8YnI+DQomZ3Q7IDUuMTE8YnI+DQomZ3Q7IFRoaXMg c2VudGVuY2U8YnI+DQomZ3Q7ICZxdW90O0Fub3RoZXIgZmFjdG9yIHVzdWFsbHkgbm90IGtub3du IHByZWNpc2VseSBvciBpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2NvbXB1dGVkIGF1dG9tYXRp Y2FsbHkgaXMgdGhlIHZhbGlkaXR5IGR1cmF0aW9uIG9mIHRoZSBsb2FkIGNvbnRyb2w8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtldmVudC4mcXVvdDs8YnI+DQomZ3Q7IFNlZW1zIHRvIGJlIGEgY3V0 IGFuZCBwYXN0ZSBlcnJvciBvZiBzb21lIHNvcnQuPGJyPg0KJmd0OyAuLi48YnI+DQo8YnI+DQpD aGFuZ2VkIHRvICZxdW90OyAmbmJzcDtBbm90aGVyIGZhY3RvciB0aGF0IGlzIHVzdWFsbHkgbm90 IGtub3duIHByZWNpc2VseSBvcjxicj4NCm5lZWRzIHRvIGJlIGNvbXB1dGVkIGF1dG9tYXRpY2Fs bHkgaXMgdGhlIHZhbGlkaXR5IGR1cmF0aW9uIG9mIHRoZTxicj4NCmxvYWQgY29udHJvbCBldmVu dC4gJm5ic3A7JnF1b3Q7PGJyPg0KPGJyPg0KJmd0OyA4LjE8YnI+DQomZ3Q7IFNob3VsZCB0aGlz PGJyPg0KJmd0OyAmcXVvdDsuLi4gYWRtaW5pc3RyYXRpdmUgb3B0aW9uIGZvciByb3V0aW5nIGZh aWxlZDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2NhbGwgYXR0ZW1wdHMgdG8gZWl0aGVyIFJlY29y ZGVyIFRvbmUgb3IgYSBzcGVjaWFsIGFubm91bmNlbWVudC4uLi4mcXVvdDs8YnI+DQomZ3Q7IGJl ICZxdW90O1Jlb3JkZXIgVG9uZSZxdW90OyBpbnN0ZWFkIG9mICZxdW90O1JlY29yZGVyIFRvbmUm cXVvdDs/PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQo8YnI+DQpJIHRoaW5rIHRoaXMgaXMgc29t ZXRoaW5nIGxpa2UgYSByZWNvcmRpbmcgbWFjaGluZSBwbGF5aW5nIHNvbWV0aGluZzxicj4NCm1l c3NhZ2UsIGFtIEkgY29ycmVjdD88YnI+DQo8YnI+DQp0aGFua3M8YnI+DQo8YnI+DQpDaGFybGVz PGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBKYW5ldDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDsgLS0tLS1zaXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZyB3cm90ZTogLS0t LS08YnI+DQomZ3Q7PGJyPg0KJmd0OyBUbzogc2lwLW92ZXJsb2FkQGlldGYub3JnPGJyPg0KJmd0 OyBGcm9tOiAmcXVvdDtWaWpheSBLLiBHdXJiYW5pJnF1b3Q7PGJyPg0KJmd0OyBTZW50IGJ5OiBz aXAtb3ZlcmxvYWQtYm91bmNlc0BpZXRmLm9yZzxicj4NCiZndDsgRGF0ZTogMDcvMjYvMjAxMiAx MjowM1BNPGJyPg0KJmd0OyBDYzogc2hlbkBhdHQuY29tPGJyPg0KJmd0Ozxicj4NCiZndDsgU3Vi amVjdDogUmU6IFtzaXAtb3ZlcmxvYWRdIEFsaWdubWVudCBvZiBwcmlvcml0eSBhbmQgZW1lcmdl bmN5IGNhbGw8YnI+DQomZ3Q7IGhhbmRsaW5nPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMDcvMjYv MjAxMiAxMDoyMyBBTSwgRFJBR0UsIEtlaXRoIChLZWl0aCkgd3JvdGU6PGJyPg0KJmd0OyZndDsg SSBkbyBub3QgYmVsaWV2ZSB5b3UgbmVlZCB0byBpbmNsdWRlIG90aGVyIGFydGlmYWN0cy48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFJhdGhlciBvdmVybG9hZC1jb250cm9sIGxpc3RzIGJv dGggUlBIIGFuZCBzb3MgVVJOLCBhbmQgdGhlIGV2ZW50PGJyPg0KJmd0OyZndDsgcGFja2FnZSBs aXN0cyBvbmx5IFJQSC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTbyBpdCBpcyBhIHNpbXBsZSBtYXR0 ZXIgb2YgZW5zdXJpbmcgdGhhdCB0aGUgdGV4dCBpbjxicj4NCiZndDsgZHJhZnQtaWV0Zi1zb2Mt bG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UgaXMgY29uc2lzdGVudCB3aXRoIHRoZTxicj4NCiZn dDsgdGV4dCBpbiBkcmFmdC1pZXRmLXNvYy1vdmVybG9hZC1jb250cm9sPzxicj4NCiZndDs8YnI+ DQomZ3Q7IElmIHNvLCBDaGFybGVzIC0tLSBjYW4geW91IHBsZWFzZSB0YWtlIGNhcmUgb2YgdGhp cyBpbjxicj4NCiZndDsgZHJhZnQtaWV0Zi1zb2MtbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2U/ PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDs8YnI+DQomZ3Q7IC0gdmlqYXk8 YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBWaWpheSBLLiBHdXJiYW5pLCBCZWxsIExhYm9yYXRvcmll cywgQWxjYXRlbC1MdWNlbnQ8YnI+DQomZ3Q7IDE5NjAgTHVjZW50IExhbmUsIFJtLiA5Qy01MzMs IE5hcGVydmlsbGUsIElsbGlub2lzIDYwNTYzIChVU0EpPGJyPg0KJmd0OyBFbWFpbDogdmtnQHti ZWxsLWxhYnMuY29tLGFjbS5vcmd9IC8gdmlqYXkuZ3VyYmFuaUBhbGNhdGVsLWx1Y2VudC5jb208 YnI+DQomZ3Q7IFdlYjogJm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9lY3QuYmVsbC1sYWJzLmNvbS93 aG8vdmtnLyI+aHR0cDovL2VjdC5iZWxsLWxhYnMuY29tL3doby92a2cvPC9hPjxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCiZndDsgc2lwLW92ZXJsb2FkIG1haWxpbmcgbGlzdDxicj4NCiZndDsg c2lwLW92ZXJsb2FkQGlldGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcC1vdmVybG9hZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQ8L2E+PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2U8YnI+DQomZ3Q7IGRlbGV0ZSB3aXRob3V0 IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGlu PGJyPg0KJmd0OyBkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUt bWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kPGJyPg0KJmd0OyBDU0MgdG8gYW55IG9yZGVy IG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuPGJy Pg0KJmd0OyBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJt aXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsPGJyPg0KJmd0OyBmb3Igc3VjaCBwdXJwb3NlLjxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7IHNpcC1vdmVybG9hZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHNpcC1vdmVybG9hZEBp ZXRmLm9yZzxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXAtb3ZlcmxvYWQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwLW92ZXJsb2FkPC9hPjxicj4NCiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8 YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo2LjBwdDtmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgaXMgYSBQUklWQVRF IG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBk ZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0 aGUgbWlzdGFrZSBpbiBkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlz DQogZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBv dGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1l bnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ug b2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcg YW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5 LiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMNCiBlLW1haWwgc2hhbGwgbm90IG9w ZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBw dXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRp YXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVy cG9zZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhpcyBp cyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkg ZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5LiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNv bnRlbnQsIHRoaXMNCiBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55 IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0 dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRp bmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNl IFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm eSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu CkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_88CAD1D4E8773F42858B58CAA28272A0069343PEXCVZYM12corpora_-- From keith.drage@alcatel-lucent.com Sun Aug 5 00:33:37 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3C621F8442 for ; Sun, 5 Aug 2012 00:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.783 X-Spam-Level: X-Spam-Status: No, score=-106.783 tagged_above=-999 required=5 tests=[AWL=-2.624, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4tG-kNnLJWI for ; Sun, 5 Aug 2012 00:33:27 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id A793921F8441 for ; Sun, 5 Aug 2012 00:33:26 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q757XJXq009634 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 5 Aug 2012 09:33:19 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 5 Aug 2012 09:33:19 +0200 From: "DRAGE, Keith (Keith)" To: "bruno.chatras@orange.com" , Janet P Gunn Date: Sun, 5 Aug 2012 09:33:18 +0200 Thread-Topic: [sip-overload] Eveny package was Alignment of priority and emergency call handling Thread-Index: AQHNcNCVzLTG24Y8WUijFVEe+dLOs5dHylqAgALpysA= Message-ID: References: , , , <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> <27278_1343984926_501B951E_27278_2308_1_88CAD1D4E8773F42858B58CAA28272A0069343@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <27278_1343984926_501B951E_27278_2308_1_88CAD1D4E8773F42858B58CAA28272A0069343@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE240B5521AFRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] Eveny package was Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 07:33:38 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE240B5521AFRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My proposal (terminology wise) would be "special information tone as define= d in ITU-T Recommendation E.182 to indicate .... or a specific recorded ann= ouncement". Keith ________________________________ From: bruno.chatras@orange.com [mailto:bruno.chatras@orange.com] Sent: 03 August 2012 10:09 To: Janet P Gunn; DRAGE, Keith (Keith) Cc: sip-overload@ietf.org Subject: RE: [sip-overload] Eveny package was Alignment of priority and eme= rgency call handling I think recorder tone is a tone to indicate to the called party that the ca= lling party is recording the conversation. So I don't think this tone would= be appropriate in the case of call failure due to overload control. An ITU= E.182 special information tone would rather be used in this case. /BC De : sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] D= e la part de Janet P Gunn Envoy=E9 : jeudi 2 ao=FBt 2012 19:02 =C0 : keith.drage@alcatel-lucent.com Cc : sip-overload@ietf.org Objet : Re: [sip-overload] Eveny package was Alignment of priority and emer= gency call handling In that case, the Event package draft should use the ITU terms. What are the equivalent ITU terms? Janet -----"DRAGE, Keith (Keith)" wrote: ----- To: Janet P Gunn/USA/CSC@CSC From: "DRAGE, Keith (Keith)" Date: 08/01/2012 11:25AM Subject: RE: [sip-overload] Alignment of priority and emergency call handli= ng Recorder tone is not. Neither is reorder tone in the quick skin I did. Keith ________________________________ From: Janet P Gunn [mailto:jgunn6@csc.com] Sent: 01 August 2012 10:06 To: DRAGE, Keith (Keith) Cc: charles@cs.columbia.edu; shen@att.com; sip-overload@ietf.org Subject: RE: [sip-overload] Alignment of priority and emergency call handli= ng Sounds good to me. Is "Recorder tone" defined there? Janet -----"DRAGE, Keith (Keith)" wrote: ----- To: Janet P Gunn/USA/CSC@CSC, "charles@cs.columbia.edu" From: "DRAGE, Keith (Keith)" Date: 07/30/2012 06:19PM Cc: "sip-overload@ietf.org" , "shen@att.com" Subject: RE: [sip-overload] Alignment of priority and emergency call handli= ng Can I suggest that we stick to the terminology available in ITU-T Recommend= ation E.182 (and E.180) as this U.S. terminology is very specific to the U.= S. and other terms are used elsewhere in world. Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Janet P Gunn Sent: 30 July 2012 23:03 To: charles@cs.columbia.edu Cc: sip-overload@ietf.org; shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handli= ng Thanks WRT the last comment - "Reorder tone" is also known (at least in the US) as= "fast busy". I agree that there might be "announcements" but I do not know what you mean by "Recorder tone". Do you mean the tone th= at sometimes comes on just BEFORE an announcement? Janet -----charles.newyork@gmail.com wrote: ----- To: Janet P Gunn/USA/CSC@CSC From: Charles Shen Sent by: charles.newyork@gmail.com Date: 07/29/2012 11:35PM Cc: vkg@bell-labs.com, sip-overload@ietf.org, shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handli= ng Hi Janet, thank you very much for your detailed comments! I've incorporated them in the new revision. Also please see response inline. On Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn wrote: > I agree with Keith's comments about priority and emergency calls. > done > I also have a number of other comments, mostly editorial (I apologize for= my > lateness in responding). > > > Introduction should stress that this approach is for situations where you > can predict, in advance, a likely traffic surge, > and its source/destination distribution. For instance, it is appropriate > for a mass-phone-voting event, Mother's Day, New > Years, and even a hurricane (there is usually some advance notice). > However, it is less likely to be effective for the initial phase of > unpredicted/unpredictable mass calling events, such as > earthquakes or terrorist attacks. In these latter cases, the local traff= ic > load may peak by more than an order of magnitude > in minutes, if not seconds. This does not allow time to either > effectively identify the filters needed, nor distribute then to the > appropriate servers, soon enough to prevent congestion > attack. Once other, more immediate, techniques (such as the loss-based o= r > rate-based methods) have prevented the initial > congestion collapse, the event package can be used to effectively control > the continuing overload. > -- agree. > This sentence > Load filtering works best if it prevents calls as close to > the user agent clients as possible. > could be clarified by including the word "originating" > Load filtering works best if it prevents calls as close to > the originating user agent clients as possible. > -- right > There appears to be a cut and past error here > Secondly, since we are describing a specific control > mechanism based on filtering, the term "load control" in this > specification is used inter-changeably with the term "load filtering" > unless when associated with other explicit context. > I suspect it is supposed to be > Secondly, since we are describing a specific control > mechanism based on filtering, the term "load control" in this > specification is used inter-changeably with the term "load filtering" > unless associated with other explicit context. > -- > right > I am not sure I understand this statement > This > specification, however, does not preclude the load control document > defined here (Section 6) to be extended in the future for other forms > of control as appropriate. > What sorts of "other forms of control" are you referring to? Presumably = not > service level and QoS control, as you have > already defined them (or at least referred to them) as "load control" but > not "overload control". > -- Yes, it could be confusing, so I removed this sentence. > Section 3 > I think that > For destination-specific overload situations, the load filter > needs to be able to describe the callee. > should be > For destination-specific overload situations, the load filter > should be able to specify the callee. > -- agree. > This bullet > To address accidental and intentional high-volume call generators, > the load filter should allow to specify the caller. > does not use correct grammar. > I suspect you mean > To address accidental and intentional high-volume call generators, > the load filter should be able to specify the caller. > -- agree > With regard to this bullet, > o For telephone numbers, it should be possible to specify prefixes > which allow control over limited regionally-focused overloads. > This is really an assumption rather than a requirement. > Furthermore, I do not believe it is true. In these days of number > portability, and people retaining their original mobile > phone number, as their primary number, when they move across the country, > the correlation between "telephone number prefix" > (aka area code) and "physical location" is rapidly decreasing. > I agree that,for regional calling events, you need a way of identifying t= he > geographical location (originating and/or > terminating) to determine which calls to filter. But I do not think that > area codes will continue to be the most effective > way of doing this. > Perhaps an alternate wording would be > o It should be possible to specify particular information in the SIP > headers (e.g., prefixes in telephone numbers) > which allow control over limited regionally-focused overloads > --- agree > sec 4.2 > in this statement > and that loads are allocated in a way which > both prevents overload and minimizes the likelihood of network > resource under-utilization. > would it be better to say "maximizes effective throughput(aka goodput)" > instead of "minimizes the likelihood of network > resource under-utilization."? > --- agree > sec 4.3 > > Should this > In order for load filters to be properly distributed, each SIP proxy > server in the network is required to subscribe to the load control > event package from all its outgoing signaling neighbors, known as > notifiers (Section 5.6). > be > In order for load filters to be properly distributed, each SIP proxy > server in the network SHOULD subscribe to the load control > event package from all its outgoing signaling neighbors, known as > notifiers (Section 5.6). > ? (not sure myself) > > --- agree. > For case II, perhaps "hurricane" (which has a more predictable, and more > gradual, increase in traffic) would be a better > example than "earthquake", due to the issues mentioned above. > -- > Sec 5.3 > In sec 4.4 you say > Another important aspect that affects the applicability of SIP load > filtering is that all possible signaling source neighbors need to > participate and enforce the designated filter. Otherwise, a single > non-conforming neighbor could make the whole control efforts useless > by pumping in excessive traffic to overload the server. > But in section 5.3 you say > a subscriber may be interested in some > specific types of load control policy only. > Maybe I am misunderstanding what you mean by "types of load control polic= y", > but the statement in 5.3 ("only interested in > some") seem inconsistent with the statement in 4.3 ("all must participate= "). > Perhaps you could add a clarifying statement. > --- Since the details of the subscription filter specification are not defined anyway, I removed this "For example" sentence to avoid the confusion. > 5.8 > Modifications of existing load > control policies at the subscriber is performed after directly > receiving notifications containing updated load control policies. > Grammar > either > ... modifications ... are ... > or > ...modification ...is ... > but NOT > ... modifications ... is ... > --- right > 5.11 > This sentence > "Another factor usually not known precisely or is > computed automatically is the validity duration of the load control > event." > Seems to be a cut and paste error of some sort. > ... Changed to " Another factor that is usually not known precisely or needs to be computed automatically is the validity duration of the load control event. " > 8.1 > Should this > "... administrative option for routing failed > call attempts to either Recorder Tone or a special announcement...." > be "Reorder Tone" instead of "Recorder Tone"? > > I think this is something like a recording machine playing something message, am I correct? thanks Charles > Janet > > > > -----sip-overload-bounces@ietf.org wrote: ----- > > To: sip-overload@ietf.org > From: "Vijay K. Gurbani" > Sent by: sip-overload-bounces@ietf.org > Date: 07/26/2012 12:03PM > Cc: shen@att.com > > Subject: Re: [sip-overload] Alignment of priority and emergency call > handling > > On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote: >> I do not believe you need to include other artifacts. >> >> Rather overload-control lists both RPH and sos URN, and the event >> package lists only RPH. > > So it is a simple matter of ensuring that the text in > draft-ietf-soc-load-control-event-package is consistent with the > text in draft-ietf-soc-overload-control? > > If so, Charles --- can you please take care of this in > draft-ietf-soc-load-control-event-package? > > 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} / 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 > > > > 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 b= ind > 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. > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_EDC0A1AE77C57744B664A310A0B23AE240B5521AFRMRSSXCHMBSC3d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

My proposal (terminology wise) would b= e “special information tone as defined in ITU-T Recommendation E.182 to indicate …. or a specific recorded announceme= nt”.

 

Keith

 

From:= bruno.chatras@orange.com [mailto:bruno.chatras@orange.com]
Sent: 03 August 2012 10:09 To: Janet P Gunn; DRAGE, Kei= th (Keith)
Cc: sip-overload@ietf.org Subject: RE: [sip-overload] = Eveny package was Alignment of priority and emergency call handling=

 

I think record= er tone is a tone to indicate to the called party that the calling party is recording the conversation. So I don’t think this tone would be appro= priate in the case of call failure due to overload control. An ITU E.182 special information tone would rather be used in this case.

/BC=

 

 

 

De : sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : jeudi 2 ao= =FBt 2012 19:02
=C0 : keith.drage@alcat= el-lucent.com
Cc : sip-overload@ietf.= org
Objet : Re: [sip-overlo= ad] Eveny package was Alignment of priority and emergency call handling

 

In that case, the Event package draft shou= ld use the ITU terms.

 

What are the equivalent ITU terms?

 

Janet 

-----"DRAGE, Kei= th (Keith)" <keith.drage@alcatel-lucent.com> wrote: -----

To: Janet P Gunn/U= SA/CSC@CSC
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com&g= t;
Date: 08/01/2012 11:25AM
Subject: RE: [sip-overload] Alignment of priority and emergency call handli= ng

Recorder tone is not.

 

Neither is reorder tone in the quick skin I did.

 

Keith

 

From: Janet P Gunn [mailto:jgunn6@csc.com]
Sent: 01 August 2012 10:06 To: DRAGE, Keith (Keith)
Cc: charles@cs.columbia.edu; shen@att.com; sip-overload@ietf.org
Subject: RE: [sip-overload] Alignment of priority and emergency call handling

 

Sounds good to me. Is "Recorder tone" defined there?

 

Janet

-----"DRAGE, Kei= th (Keith)" <keith.drage@alcatel-lucent.com> wrote: -----

To: Janet P Gunn/USA/CSC@CSC, "charles@cs.columbia.edu" <charles@cs.columbia.edu>
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com&g= t;
Date: 07/30/2012 06:19PM
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>, "shen@att.com" <shen@att.com>
Subject: RE: [sip-overload] Alignment of priority and emergency call handli= ng

Can I suggest that we stick to the terminology available = in ITU-T Recommendation E.182 (and E.180) as thi= s U.S. terminology is very specific to the U.S. and other terms are used elsewhere= in world.

 

Keith

 

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: 30 July 2012 23:03
To: charles@cs.columbia.edu<= br> Cc: sip-overload@ietf.org; shen@att.com
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

 

Thanks

 

WRT the last comment - "Reorder tone" is also known (at least in the = US) as "fast busy".

I agree that there might be "announcements"

but I do not know what you mean by "Recorder tone". Do you mean the t= one that sometimes comes on just BEFORE an announcement?

 

Janet


-----charles.newyork@= gmail.com wrote: -----

To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: charles.newyork@gmail.com
Date: 07/29/2012 11:35PM
Cc: vkg@bell-labs.com, sip-overload@ietf.org, shen@att.com
Subject: Re: [sip-overload] Alignment of priority and emergency call handli= ng

Hi Janet, thank you very much for your detailed comments! I've
incorporated them in the new revision. Also please see response
inline.

On Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn <jgunn6@csc.com> wrote:=
> I agree with Keith's comments about priority and emergency calls.
>

done

> I also have a number of other comments, mostly editorial (I apologize = for my
> lateness in responding).
>
>
> Introduction should stress that this approach is for situations where = you
> can predict, in advance, a likely traffic surge,
> and its source/destination distribution.  For instance, it is appropriate
> for a mass-phone-voting event, Mother's Day, New
> Years, and even a hurricane (there is usually some advance notice). > However, it is less likely to be effective for the initial phase of > unpredicted/unpredictable mass calling events, such as
> earthquakes or terrorist attacks.  In these latter cases, the loc= al traffic
> load may peak by more than an order of magnitude
> in minutes, if not seconds.  This does not allow time to either > effectively identify the filters needed, nor distribute then to the > appropriate servers, soon enough to prevent congestion
> attack.  Once other, more immediate, techniques (such as the loss-based or
> rate-based  methods) have prevented the initial
> congestion collapse, the event package can be used to effectively cont= rol
> the continuing overload.
> --

agree.

> This sentence
>  Load filtering works best if it prevents calls as close to
>  the user agent clients as possible.
> could be clarified by including the word "originating"
>  Load filtering works best if it prevents calls as close to
>  the originating user agent clients as possible.
> --

right

> There appears to be a cut and past error here
> Secondly, since we are describing a specific control
>    mechanism based on filtering, the term "load control" in this
>    specification is used inter-changeably with the term "load filtering"
>    unless when associated with other explicit context.
> I suspect it is supposed to be
> Secondly, since we are describing a specific control
>    mechanism based on filtering, the term "load control" in this
>    specification is used inter-changeably with the term "load filtering"
>    unless associated with other explicit context.
> --
>

right

> I am not sure I understand this statement
> This
>    specification, however, does not preclude the load contro= l document
>    defined here (Section 6) to be extended in the future for other forms
>    of control as appropriate.
> What sorts of "other forms of control" are you referring to?  Presumably not
> service level and QoS control, as you have
> already defined them (or at least referred to them) as "load control" but
> not "overload control".
> --

Yes, it could be confusing, so I removed this sentence.

>  Section 3
> I think that
> For destination-specific overload situations, the load filter
>       needs to be able to describe the callee.
> should be
> For destination-specific overload situations, the load filter
>       should be able to specify the callee.
> --

agree.

> This bullet
>  To address accidental and intentional high-volume call generator= s,
>       the load filter should allow to specify the calle= r.
> does not use correct grammar.
> I suspect you mean
>  To address accidental and intentional high-volume call generator= s,
>       the load filter should be able to  specify t= he caller.
> --

agree

> With regard to this bullet,
>    o  For telephone numbers, it should be possible to specify prefixes
>       which allow control over limited regionally-focus= ed overloads.
> This is really an assumption rather than a requirement.
> Furthermore, I do not believe it is true.  In these days of numbe= r
> portability, and people retaining their original mobile
> phone number, as their primary number, when they move across the count= ry,
> the correlation between "telephone number prefix"
> (aka area code) and "physical location" is rapidly decreasin= g.
> I agree that,for regional calling events, you need a way of identifyin= g the
> geographical location (originating and/or
> terminating) to determine which calls to filter.  But I do not th= ink that
> area codes will continue to be the most effective
> way of doing this.
> Perhaps an alternate wording would be
>    o  It should be possible to specify particular information in the SIP
> headers (e.g., prefixes in telephone numbers)
>       which allow control over limited regionally-focus= ed overloads
> ---

agree

> sec 4.2
>  in this statement
>  and that loads are allocated in a way which
>    both prevents overload and minimizes the likelihood of network
>    resource under-utilization.
> would it be better to say "maximizes effective throughput(aka goodput)"
> instead of "minimizes the likelihood of network
>    resource under-utilization."?
> ---

agree

> sec 4.3
>
> Should this
> In order for load filters to be properly distributed, each SIP proxy >    server in the network is required to subscribe to the loa= d control
>    event package from all its outgoing signaling neighbors, known as
>    notifiers (Section 5.6).
> be
> In order for load filters to be properly distributed, each SIP proxy >    server in the network SHOULD subscribe to the load contro= l
>    event package from all its outgoing signaling neighbors, known as
>    notifiers (Section 5.6).
> ? (not sure myself)
>
> ---

agree.

> For case II, perhaps "hurricane" (which has a more predictab= le, and more
> gradual, increase in traffic) would be a better
> example than "earthquake", due to the issues mentioned above= .
> --
> Sec 5.3
> In sec 4.4 you say
> Another important aspect that affects the applicability of SIP load >    filtering is that all possible signaling source neighbors need to
>    participate and enforce the designated filter.  Otherwise, a single
>    non-conforming neighbor could make the whole control effo= rts useless
>    by pumping in excessive traffic to overload the server. > But in section 5.3 you say
> a subscriber may be interested in some
>    specific types of load control policy only.
> Maybe I am misunderstanding what you mean by "types of load contr= ol policy",
> but the statement in 5.3 ("only interested in
> some") seem inconsistent with the statement in 4.3 ("all mus= t participate").
> Perhaps you could add a clarifying statement.
> ---

Since the details of the subscription filter specification are not
defined anyway, I removed this "For example" sentence to avoid th= e
confusion.


> 5.8
> Modifications of existing load
>    control policies at the subscriber is performed after directly
>    receiving notifications containing updated load control policies.
> Grammar
> either
> ... modifications ... are ...
> or
> ...modification ...is ...
> but NOT
> ... modifications ... is ...
> ---

right

> 5.11
> This sentence
> "Another factor usually not known precisely or is
>    computed automatically is the validity duration of the lo= ad control
>    event."
> Seems to be a cut and paste error of some sort.
> ...

Changed to "  Another factor that is usually not known precisely = or
needs to be computed automatically is the validity duration of the
load control event.  "

> 8.1
> Should this
> "... administrative option for routing failed
>    call attempts to either Recorder Tone or a special announcement...."
> be "Reorder Tone" instead of "Recorder Tone"?
>
>

I think this is something like a recording machine playing something
message, am I correct?

thanks

Charles


> Janet
>
>
>
> -----sip-overload-bounces@ietf.org wrote: -----
>
> To: sip-overload@ietf.org
> From: "Vijay K. Gurbani"
> Sent by: sip-overload-bounces@ietf.org
> Date: 07/26/2012 12:03PM
> Cc: shen@att.com
>
> Subject: Re: [sip-overload] Alignment of priority and emergency call > handling
>
> On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote:
>> I do not believe you need to include other artifacts.
>>
>> Rather overload-control lists both RPH and sos URN, and the event<= br> >> package lists only RPH.
>
> So it is a simple matter of ensuring that the text in
> draft-ietf-soc-load-control-event-package is consistent with the
> text in draft-ietf-soc-overload-control?
>
> If so, Charles --- can you please take care of this in
> draft-ietf-soc-load-control-event-package?
>
> 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} / vijay.gurbani@alcatel-lucent.com<= br> > Web:   http://ect.b= ell-labs.com/who/vkg/
>
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/sip-overload
>
>
>
> This is a PRIVATE message. If you are not the intended recipient, plea= se
> delete without copying and kindly advise us by e-mail of the mistake i= n
> delivery. NOTE: Regardless of content, this e-mail shall not operate t= o bind
> CSC to any order or oth= er contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of e-m= ail
> for such purpose.
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/sip-overload
>



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 ope= rate to bind CSC to any order or = other contract unless pursuant to explicit written agreement or government initia= tive expressly permitting the use of e-mail for such purpose.



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 ope= rate to bind CSC to any order or = other contract unless pursuant to explicit written agreement or government initia= tive expressly permitting the use of e-mail for such purpose.



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 ope= rate to bind CSC to any order or = other contract unless pursuant to explicit written agreement or government initia= tive expressly permitting the use of e-mail for such purpose.

__________________________________________________________________=
_______________________________________________________
 
Ce=
 message et ses pieces jointes peuvent contenir des informations confidenti=
elles ou privilegiees et ne doivent donc
pa= s etre diffuses, exploites ou copies sans autorisation. Si vous avez recu c= e message par erreur, veuillez le signalera = l'expediteur et le detruire ainsi que les pieces jointes. Les messages elec= troniques etant susceptibles d'alteration,Fr= ance Telecom - Orange decline toute responsabilite si ce message a ete alte= re, deforme ou falsifie. Merci.
 
Th=
is message and its attachments may contain confidential or privileged infor=
mation that may be protected by law;
th=
ey 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.
Th=
ank you.
--_000_EDC0A1AE77C57744B664A310A0B23AE240B5521AFRMRSSXCHMBSC3d_-- From adam@nostrum.com Sun Aug 5 10:39:29 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F6521F8510 for ; Sun, 5 Aug 2012 10:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nB9Q8dXRXqg for ; Sun, 5 Aug 2012 10:39:27 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 789F721F850D for ; Sun, 5 Aug 2012 10:39:27 -0700 (PDT) Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q75HdMan031960 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 5 Aug 2012 12:39:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <501EAFCA.2030705@nostrum.com> Date: Sun, 05 Aug 2012 12:39:22 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: bruno.chatras@orange.com References: , , , <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> <27278_1343984926_501B951E_27278_2308_1_88CAD1D4E8773F42858B58CAA28272A0069343@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <27278_1343984926_501B951E_27278_2308_1_88CAD1D4E8773F42858B58CAA28272A0069343@PEXCVZYM12.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------090705040709000900090701" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] Eveny package was Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Aug 2012 17:39:29 -0000 This is a multi-part message in MIME format. --------------090705040709000900090701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This whole conversation is as amusing as watching an American and a Briton argue about the meaning of the word "pants." Let me see if I can clear some things up. On 8/3/12 04:08, Aug 3, bruno.chatras@orange.com wrote: > > I think recorder tone is a tone to indicate to the called party that > the calling party is recording the conversation. So I don't think this > tone would be appropriate in the case of call failure due to overload > control. > Not "recorder" -- "reorder," which is what North American phone systems produce to indicate overload: http://en.wikipedia.org/wiki/Reorder_tone The reference you're looking for here is ITU-T E.300 Series Supplement 3. On 8/5/12 02:33, Aug 5, DRAGE, Keith (Keith) wrote: > > My proposal (terminology wise) would be "special information tone as > defined in ITU-T Recommendation E.182 to indicate .... or a specific > recorded announcement". > The issue with using a special information tone for overload is that North American systems use that signal to indicate conditions that cannot be rectified by re-trying later. They are widely understood by humans to mean "you dialed the wrong number," and used by some automated systems to remove numbers from directories. Using them for overload situations would have the wrong meaning for people and generate unwanted behavior in automated systems. I also find it curious that you chose to elide the rather important exceptions regarding Special Information Tones. The entire description in E.182 is: > A tone advising the caller that the called number cannot be reached > for reasons other than "subscriber busy" or "congestion". > > The tone may also be used in conjunction with recorded announcements > to signify that what the caller is about to hear is a recording. It > should always be used to precede all call failure announcements. It seems to me that this circumstance is most analogous to "congestion," and that a "Congestion Tone" would be far more appropriate. Nonetheless, we may need to take regional variations into account here -- as it is plausible that one or two implementors may actually be American -- and specify something like "a tone used in the callers' locale to indicate resource exhaustion, such as a Congestion Tone in Europe or a Reorder Tone in North America." /a --------------090705040709000900090701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
This whole conversation is as amusing as watching an American and a Briton argue about the meaning of the word "pants." Let me see if I can clear some things up.

On 8/3/12 04:08, Aug 3, bruno.chatras@orange.com wrote:

I think recorder tone is a tone to indicate to the called party that the calling party is recording the conversation. So I don’t think this tone would be appropriate in the case of call failure due to overload control.


Not "recorder" -- "reorder," which is what North American phone systems produce to indicate overload: http://en.wikipedia.org/wiki/Reorder_tone

The reference you're looking for here is ITU-T E.300 Series Supplement 3.


On 8/5/12 02:33, Aug 5, DRAGE, Keith (Keith) wrote:

My proposal (terminology wise) would be “special information tone as defined in ITU-T Recommendation E.182 to indicate …. or a specific recorded announcement”.


The issue with using a special information tone for overload is that North American systems use that signal to indicate conditions that cannot be rectified by re-trying later. They are widely understood by humans to mean "you dialed the wrong number," and used by some automated systems to remove numbers from directories. Using them for overload situations would have the wrong meaning for people and generate unwanted behavior in automated systems.

I also find it curious that you chose to elide the rather important exceptions regarding Special Information Tones. The entire description in E.182 is:

A tone advising the caller that the called number cannot be reached for reasons other than "subscriber busy" or "congestion".

The tone may also be used in conjunction with recorded announcements to signify that what the caller is about to hear is a recording. It should always be used to precede all call failure announcements.

It seems to me that this circumstance is most analogous to "congestion," and that a "Congestion Tone" would be far more appropriate.

Nonetheless, we may need to take regional variations into account here -- as it is plausible that one or two implementors may actually be American -- and specify something like "a tone used in the callers' locale to indicate resource exhaustion, such as a Congestion Tone in Europe or a Reorder Tone in North America."

/a
--------------090705040709000900090701-- From g.kiranreddy4u@gmail.com Sat Aug 18 06:14:36 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1381F21F8551 for ; Sat, 18 Aug 2012 06:14:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rkg5QeYePfR for ; Sat, 18 Aug 2012 06:14:35 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71A0221F8546 for ; Sat, 18 Aug 2012 06:14:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4789130vbb.31 for ; Sat, 18 Aug 2012 06:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=aABbksBeMG9lHh2q/wAmQ2bO2iHRoEkuazJ9Nt7yUXM=; b=CzGz/5iIwJN3Fz3FGgmPri4T990CDGKdf3NolB17P8YiG3za9IRSK+SupDL95BcuGe cjHv1dx+NGNvr15yumTUg5BJ/2tKLiGO+Gvwqehz3EvyCiJGjqfvnRcxrbcVI6+F6FFj uQBHY9d4c5uMvIhpIsDaKnz5nHescoM4p7VSvFLKhyhJZhWJa4C+SBGhMmnl1sME6jsV dA6Fq/GOBtrcygeDvJKbNF5Mkfr6MyuEuD7fTCQReZ1/7ksdGShEcH8xNJybgqk1uqWI zKybiEhtWNd6EGnHcPEy09GeECEQbQStfqmyR5aJRBVnbMEesZP1PT7tL+Mg+9pM3b1G z8yA== Received: by 10.221.0.138 with SMTP id nm10mr5389083vcb.38.1345295671967; Sat, 18 Aug 2012 06:14:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.91.131 with HTTP; Sat, 18 Aug 2012 06:14:11 -0700 (PDT) From: kiran kumar Date: Sat, 18 Aug 2012 18:44:11 +0530 Message-ID: To: sip-overload@ietf.org Content-Type: multipart/alternative; boundary=bcaec54a386aa5408704c78a0e50 Subject: [sip-overload] regarding prioritization of sip request/responses X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 13:14:36 -0000 --bcaec54a386aa5408704c78a0e50 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, I am new to this working group mail chain, the following are my comments/suggesionts. Apologizes if these are already have been discussed. 1) Why prioritization of sip messages are completely left to the local implementation, why can't we specify a standardized prioritization as similar to draft-ietf-soc-overload-control-09 section 5.10.1 as a Recommonded implementation. 2) This draft and the corresponding RFCs (RFC 6357, RFC 5390) are specifying "oc" for a timer based indication, how it will be if a number of requests based "oc" is also supportd in addition to the time based one by specifying with some parameter. (IMO). --bcaec54a386aa5408704c78a0e50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,
=A0
I am new to this working group mail chain, the following are my commen= ts/suggesionts.
Apologizes if these are already have been discussed.
=A0
1) Why prioritization of sip messages are completely left to the local= implementation, why can't we specify a standardized prioritization as = similar to=A0draft-ietf-soc-overload-control-09 section 5.10.1 as a Recommo= nded implementation.
=A0
2) This draft and the corresponding=A0RFCs (RFC 6357, RFC 5390)=A0are = specifying "oc" for a timer based indication, how it will be if a= number of requests based "oc" is also supportd in addition to th= e time based one by specifying with some parameter. (IMO).
--bcaec54a386aa5408704c78a0e50-- From g.kiranreddy4u@gmail.com Sat Aug 18 06:29:32 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51E721F8541; Sat, 18 Aug 2012 06:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.016 X-Spam-Level: X-Spam-Status: No, score=-3.016 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53nkKp2amrjX; Sat, 18 Aug 2012 06:29:32 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 12CC621F853C; Sat, 18 Aug 2012 06:29:28 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4353573vcb.31 for ; Sat, 18 Aug 2012 06:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=JqrRUxWstF8zpVKYXjjZxhYuN0d2NslVO/EchYJtKwQ=; b=VFZrZeSNIq5AxwiIVI4zwpIBEcwj6GuxrmB5YS5pgvJcFaIVFwz2CAnqPLA5mwwjVY L4VuiGywLcioXKy/PxU8eg/4ESHLHcWQ270WEqDdkWDVe/hct0M32dnnNIZjPvYZUwaI FvT3XYpH9pGKYnsXlD3GuI81+1rVcs3kLbm7miV2r2zE+Tn6IY9fVUALRkmqUsKAMb99 qYCXLBtllLJMgl00FJWbaJ6cCkglcxcx+H7swaB81Y4cz//Pikv9iq99rc1ZZaocKWeJ +xOiB9a+87zNB2GdyCiakY035hkhpUQxEUM+IQ9W08jZHfMZOhCYaa0uBZ+88nUNtbwc X35g== Received: by 10.52.97.8 with SMTP id dw8mr4568970vdb.31.1345296568365; Sat, 18 Aug 2012 06:29:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.91.131 with HTTP; Sat, 18 Aug 2012 06:29:08 -0700 (PDT) From: kiran kumar Date: Sat, 18 Aug 2012 18:59:08 +0530 Message-ID: To: sip-overload@ietf.org, sip-overload-request@ietf.org Content-Type: multipart/alternative; boundary=20cf307d01e413311904c78a44b9 Subject: [sip-overload] Regarding prioritization of sip requests/ responses. X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 13:29:32 -0000 --20cf307d01e413311904c78a44b9 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, I am new to this working group mailing chain. Apologizes if these are already discussed in this group. 1) Why prioritization, for processing of sip requests, is completely left to local implementation, why don't we specify a Recommonded priorityzation for this. ( only few suggestions were given in draft-ietf-soc-overload-control-09 section 5.10.1). 2) SOC WG is considering "oc"only for time based validity. Why don't we suggest an alternative like number of requests based validity for "oc" in addition to the time based approach with some identification parameter. (IMO timers uses system calls and so are more overhead (may be little but considerable in overloaded scenarios) than the local library counters). 3) I didn't read the draft-ietf-soc-overload-control-09 line by line but I can suggest a negligible correction (to modify in the next version) in section 5.3 "Note that this stipulation is required so that both the and server have an common view of which messages to include in the calculation of the feedback." In this the corrections I specify is "bothe the client and server have a common" -- client is missing there ... Thanks, Kiran. --20cf307d01e413311904c78a44b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Folks,
=A0
I am new to this working group mailing chain.
Apologizes if these are already discussed in this group.
=A0
1) Why prioritization, for processing=A0of sip requests, is completely= left to local implementation, why don't we specify a Recommonded prior= ityzation for this. ( only few suggestions were given in draft-ietf-soc-ove= rload-control-09 section 5.10.1).
=A0
2)=A0 SOC WG is considering "oc"only for time based validity= . Why don't we suggest an alternative like number of requests based val= idity for "oc" in addition to the time based approach with some i= dentification parameter. (IMO timers uses system calls and so are more over= head (may be little but considerable in overloaded scenarios) than the loca= l library counters).
=A0
3) I didn't read the draft-ietf-soc-overload-control-09 line by li= ne but I can suggest a negligible correction (to modify in the next version= ) in section 5.3
=A0=A0=A0=A0=A0=A0=A0=A0 "Note that this stipulation is required = so that both the and server
=A0=A0=A0=A0=A0=A0=A0=A0=A0 have an common view of which messages to i= nclude in the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 calculation of the feedback."
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In this the corrections I specify is= "bothe the client and server have a common" -- client is missing= there ...
=A0
Thanks,
Kiran.
--20cf307d01e413311904c78a44b9-- From g.kiranreddy4u@gmail.com Sat Aug 18 06:33:46 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401EC21F853C for ; Sat, 18 Aug 2012 06:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaImv1BhRS5n for ; Sat, 18 Aug 2012 06:33:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0821F8522 for ; Sat, 18 Aug 2012 06:33:45 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4799062vbb.31 for ; Sat, 18 Aug 2012 06:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=puY1iQkTyfNZDmO2CO0fIULLYpoqYc4SeFn6rkru71E=; b=xt2vGei9YUz2cSOhPygjMG9Xd+WtbJO57W8PfYz0CjZoBFHHOewwHm1UjFk1b3n+Ak SZkbH/BLlIYxCZOolmWz4sRUd2WOF2ytmk7xnWeJhDnp7KAGBsZDCuZ0n54BgjPDADMB 4+ha0djw4V8sLZcwoV1A4Sh4bQ2eYMlJIhScrWel3OE8C/o+CaHiFobIFkH8ITJb7AgG /JVF5g7AvdCxOVKyRDT1Hofnw9mwAbLE9waf/zAv2b80MnT2N8DQKTg3BCR7iLJ9I9wY g44U+zeI0qqye20eSPs3mGti+/ldwFf9MmRhU9AztAhfd2o06H9JzCQ6+xsjjpbszuDx wCcA== Received: by 10.52.25.73 with SMTP id a9mr512131vdg.95.1345296825109; Sat, 18 Aug 2012 06:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.58.91.131 with HTTP; Sat, 18 Aug 2012 06:33:24 -0700 (PDT) From: kiran kumar Date: Sat, 18 Aug 2012 19:03:24 +0530 Message-ID: To: sip-overload@ietf.org Content-Type: multipart/alternative; boundary=20cf3079bff060cda304c78a53e9 Subject: [sip-overload] Regarding prioritization of sip requests/ responses. X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Aug 2012 13:33:46 -0000 --20cf3079bff060cda304c78a53e9 Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, I am new to this working group mailing chain. Apologizes if these are already discussed in this group. 1) Why prioritization, for processing of sip requests, is completely left to local implementation, why don't we specify a Recommonded priorityzation for this. ( only few suggestions were given in draft-ietf-soc-overload-control-09 section 5.10.1). 2) SOC WG is considering "oc"only for time based validity. Why don't we suggest an alternative like number of requests based validity for "oc" in addition to the time based approach with some identification parameter. (IMO timers uses system calls and so are more overhead (may be little but considerable in overloaded scenarios) than the local library counters). 3) I didn't read the draft-ietf-soc-overload-control-09 line by line but I can suggest a negligible correction (to modify in the next version) in section 5.3 "Note that this stipulation is required so that both the and server have an common view of which messages to include in the calculation of the feedback." In this the corrections I specify is "bothe the client and server have a common" -- client is missing there ... Thanks, Kiran. --20cf3079bff060cda304c78a53e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Folks,
=A0
I am new to this working group mailing chain.
Apolog= izes if these are already discussed in this group.
=A0
1) Why priorit= ization, for processing of sip requests, is completely left to local implem= entation, why don't we specify a Recommonded priorityzation for this. (= only few suggestions were given in draft-ietf-soc-overload-control-09 sect= ion 5.10.1).
=A0
2)=A0 SOC WG is considering "oc"only for time based validi= ty. Why don't we suggest an alternative like number of requests based v= alidity for "oc" in addition to the time based approach with some= identification parameter. (IMO timers uses system calls and so are more ov= erhead (may be little but considerable in overloaded scenarios) than the lo= cal library counters).
=A0
3) I didn't read the draft-ietf-soc-overload-control-09 line by = line but I can suggest a negligible correction (to modify in the next versi= on) in section 5.3
=A0=A0=A0=A0=A0=A0=A0=A0 "Note that this stipul= ation is required so that both the and server
=A0=A0=A0=A0=A0=A0=A0=A0=A0 have an common view of which messages to includ= e in the
=A0=A0=A0=A0=A0=A0=A0=A0=A0 calculation of the feedback."<= br>=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 In this the corrections I speci= fy is "bothe the client and server have a common" -- client is mi= ssing there ...
=A0
Thanks,
Kiran. --20cf3079bff060cda304c78a53e9-- From volker.hilt@bell-labs.com Mon Aug 20 06:42:40 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA50921F85B1 for ; Mon, 20 Aug 2012 06:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rK8ef2dYipPy for ; Mon, 20 Aug 2012 06:42:40 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D458D21F8513 for ; Mon, 20 Aug 2012 06:42:39 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q7KDe70p014551 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 20 Aug 2012 15:42:36 +0200 Received: from [149.204.61.15] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 20 Aug 2012 15:42:11 +0200 Message-ID: <50323EA3.7020004@bell-labs.com> Date: Mon, 20 Aug 2012 15:41:55 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sip-overload] Regarding prioritization of sip requests/ responses. X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Aug 2012 13:42:40 -0000 Kiran, > > I am new to this working group mailing chain. > Apologizes if these are already discussed in this group. > > 1) Why prioritization, for processing of sip requests, is completely > left to local implementation, why don't we specify a Recommonded > priorityzation for this. ( only few suggestions were given in > draft-ietf-soc-overload-control-09 section 5.10.1). > There has been a lot of discussion on this topic on the list and the current proposal is what was concluded. If your interested, you can find more on this in the list archives. > 2) SOC WG is considering "oc"only for time based validity. Why don't we > suggest an alternative like number of requests based validity for "oc" > in addition to the time based approach with some identification > parameter. (IMO timers uses system calls and so are more overhead (may > be little but considerable in overloaded scenarios) than the local > library counters). > You don't need to run a system timer for a time based expiration. You can simply calculate the time passed before using a value and discard values that are past their expiration. In order to keep things simple it is better to stick to one method. > 3) I didn't read the draft-ietf-soc-overload-control-09 line by line but > I can suggest a negligible correction (to modify in the next version) in > section 5.3 > "Note that this stipulation is required so that both the and > server > have an common view of which messages to include in the > calculation of the feedback." > > In this the corrections I specify is "bothe the client and > server have a common" -- client is missing there ... > Thanks!! Volker > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > From bruno.chatras@orange.com Wed Aug 29 07:10:09 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C707B21F853E for ; Wed, 29 Aug 2012 07:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzUwqPcypykh for ; Wed, 29 Aug 2012 07:10:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id CA27821F8533 for ; Wed, 29 Aug 2012 07:10:03 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7C33C18C353; Wed, 29 Aug 2012 16:10:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 26A1D35C096; Wed, 29 Aug 2012 16:10:01 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 29 Aug 2012 16:10:00 +0200 From: To: Adam Roach , "draft-ietf-soc-load-control-event-package@tools.ietf.org" Thread-Topic: [sip-overload] Comments on SOC Event Package Thread-Index: AQHNbniVvS6tq17eJU+omQ7bHlymbpdw8ZJQ Date: Wed, 29 Aug 2012 14:10:00 +0000 Message-ID: <30136_1346249401_503E22B9_30136_2138_1_88CAD1D4E8773F42858B58CAA28272A00754BF@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <5016C3F1.4060709@nostrum.com> In-Reply-To: <5016C3F1.4060709@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A00754BFPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.8.29.135128 Cc: "SOC \(SIP Overload Control\) WG" Subject: Re: [sip-overload] Comments on SOC Event Package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2012 14:10:10 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A00754BFPEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Two comments/questions below. De : sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] D= e la part de Adam Roach Envoy=E9 : lundi 30 juillet 2012 19:27 =C0 : draft-ietf-soc-load-control-event-package@tools.ietf.org Cc : SOC (SIP Overload Control) WG Objet : [sip-overload] Comments on SOC Event Package I apologize for coming in so late after WGLC with these comments. The first, and most important comment is that this document is presently ba= sed on the obsolete RFC3265. That document has been replaced by RFC 6665. T= his has a number of impacts. The first, most obvious one is that the refere= nces to the SIP events document need to be replaced to cite RFC6665 instead= . This also necessitates that the section numbers cited in RFC3265 need to = be updated to match the corresponding sections in 6665. If you have trouble= figuring out where any specific bit of text went, I'll be happy to point y= ou in the right direction. One of the concepts that is now deprecated by 6665 is sharing multiple subs= criptions on the same dialog. This means that the final sentence of the sec= ond paragraph of section 4.3 (starting "The same subscription dialog can al= so be used...") needs to be removed. Section 5.12 can be removed. The concept of State Agents has been removed f= rom 6665. Related to SIP events, but not the 6665 changes: I looked very carefully fo= r an indication of which Request URI is supposed to be used in the SUBSCRIB= E messages sent for this event package, but saw no guidance. I suspect that= you want a URI of the form "sip:server.example.com" (i.e., without a user) where "server.example.com" represents the server w= hose overload state is being requested. Full example messages would help to= make this clearer. The second paragraph on page 13 effectively turns the soft state mechanism = of SUBSCRIBE/NOTIFY into a hard-state mechanism. This is problematic, as yo= u can end up with a situation in which a communication disruption (say, a c= hange in authentication) can lead to persistent throttling when it is not a= ppropriate to do so. This artificially limits throughput, which is somewhat= counter to what the overload control effort is supposed to do. What is the= justification for keeping state beyond the duration of a subscription? The third paragraph on page 13 says that a NOTIFY request that does not con= tain a body MUST be ignored. In contrast, section 4.3 says that a notificat= ion includes an empty body indicates that no overload rules are in effect. = These statements are in conflict with each other, unless you are intending = to distinguish between a message containing an *empty* (but present) body, = and a message that does not contain a body. If that's the distinction being= made, you need to be far more explicit that such is the intention. I would= strongly counsel against such a decision; even if the difference is made c= lear in the text, it is such a subtle distinction that it is unlikely to be= implemented correctly. Unrelated to the 6665 issues, I have some additional comments. At the top o= f page 9, there is a statement that the proxies to which proxies should sub= scribe can be learned from the signaling messages sent and received. I thin= k we need some guidance about when this learned information can be purged. = Presumably we don't want a single interaction between proxies to result in = a subscription that is kept in place for the rest of all time. Near the top of page 16, the document specifies that elements containing mu= ltiple , , and elements are ORed together. I don't thin= k this is quite what you intend. If you have a and an , you = don't really want to match everything that is in the OR everything e= xcluded by the . I can kind of figure out what you really meant, b= ut the language needs to be adjusted to actually say it. On page 19, one of the specified actions is "drop." There is passing implic= ation that doing this over an unreliable link will cause retransmissions. T= his needs more treatment in the text. In fact, as dropping requests over an= unreliable link will *always* make overload worse rather than better, I wo= uld strongly recommend that we add text that specifies that any "drop" rule= applied to an unreliable transport MUST be treated as if it were "reject." Similarly, we run into an issue in which an ACK response to a 200 is droppe= d, as doing so will cause the 200 to be retransmitted, which again exacerba= tes any overload condition that may arise. In other words, I think we need = to specify that "drop" cannot be applied to ACK (and reject clearly can't, = since ACK never sees a response) -- so ACKs must always go through regardle= ss of overload filters. For the same reason, proxies that receive an ACK re= sponse to a non-200 need to always process the ACK rather than dropping it. [BC] I don't think this can happen. The current text says that "Conditio= ns are evaluated on receipt of an initial SIP request for a dialog or standalone transaction". So my understanding is that conditions are not ev= aluated on receipt of an ACK. Moreover, the "ACK" is not a valid value for = the element and the current text says that when the eleme= nt is not included in a filter, the rule actions are applicable to all init= ial methods. A formal definition of initial method may be missing but I ass= ume ACK is not an initial method. On the other hand, I'm wondering whether this comment about ACK should not = be made against draft-ietf-soc-overload-control, section 5.10? On to topic of rejects, I note that the current draft simply gives an examp= le (500 Server Internal Error) rather than specifying how rejection is perf= ormed. This will make troubleshooting a system more difficult. I would sugg= est that we add a new 500-class error code that is used to indicate this sp= ecific situation. We also need to think about whether "Retry-After" handlin= g is appropriate in this case. I think it is, but we need to work through h= ow it is set (i.e., is it part of the overload rule, or is it set by the se= rver itself?) [BC] Is there any reason for rejecting calls with a different response code= depending on whether overload control information was obtained using the f= eedback-based or even-based solution? I guess the answer is no. Section 5.1= 0.2 of draft-ietf-soc-overload-control says that the SIP server must reject= requests with a 503 response. Finally, I note that we have a "forward" rule. I think we would be well ser= ved by a very similar "redirect" rule that sends a 300-class response rathe= r than forwarding the request to an alternate destination. Small editorial nit: while the use of the date "79 AD" in the example at th= e top of page 21 is both clever and amusing to those who have both received= an education on the topic of Vesuvius' destruction of Pompeii and recall i= ts details, the use of a two-digit year in an example is likely to lead to = confusion on the part of implementors. We really don't need examples from w= hich implementors might incorrectly infer that omitting the century portion= of the year in ISO-style dates is acceptable. Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly = we can cite an international specification for the discussion of call gappi= ng -- doesn't Q.1248 cover this?. It seems a bit provincial to use a Bellco= re spec to the exclusion of an ITU-T spec in the context of a document to b= e published by an international standards body such as the IETF. /a ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation 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 dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_88CAD1D4E8773F42858B58CAA28272A00754BFPEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Two comments/questions below.

 

De : sip-overload-b= ounces@ietf.org [mailto:sip-overload-bounces@ietf.org] De la part de Adam Roach
Envoy=E9 : lundi 30 juillet 2012 19:27
=C0 : draft-ietf-soc-load-control-event-package@tools.ietf.org<= br> Cc : SOC (SIP Overload Control) WG
Objet : [sip-overload] Comments on SOC Event Package=

 

I apologize for coming in so late after WGLC with th= ese comments.

The first, and most important comment is that this document is presently ba= sed on the obsolete RFC3265. That document has been replaced by RFC 6665. T= his has a number of impacts. The first, most obvious one is that the refere= nces to the SIP events document need to be replaced to cite RFC6665 instead. This also necessitates that t= he section numbers cited in RFC3265 need to be updated to match the corresp= onding sections in 6665. If you have trouble figuring out where any specifi= c bit of text went, I'll be happy to point you in the right direction.

One of the concepts that is now deprecated by 6665 is sharing multiple subs= criptions on the same dialog. This means that the final sentence of the sec= ond paragraph of section 4.3 (starting "The same subscription dialog c= an also be used...") needs to be removed.

Section 5.12 can be removed. The concept of State Agents has been removed f= rom 6665.

Related to SIP events, but not the 6665 changes: I looked very carefully fo= r an indication of which Request URI is supposed to be used in the SUBSCRIB= E messages sent for this event package, but saw no guidance. I suspect that= you want a URI of the form "sip:server.example.com" (= i.e., without a user) where "server.example.com" represents the s= erver whose overload state is being requested. Full example messages would = help to make this clearer.

The second paragraph on page 13 effectively turns the soft state mechanism = of SUBSCRIBE/NOTIFY into a hard-state mechanism. This is problematic, as yo= u can end up with a situation in which a communication disruption (say, a c= hange in authentication) can lead to persistent throttling when it is not appropriate to do so. This artific= ially limits throughput, which is somewhat counter to what the overload con= trol effort is supposed to do. What is the justification for keeping state = beyond the duration of a subscription?

The third paragraph on page 13 says that a NOTIFY request that does not con= tain a body MUST be ignored. In contrast, section 4.3 says that a notificat= ion includes an empty body indicates that no overload rules are in effect. = These statements are in conflict with each other, unless you are intending to distinguish between a message= containing an *empty* (but present) body, and a message that does not cont= ain a body. If that's the distinction being made, you need to be far more e= xplicit that such is the intention. I would strongly counsel against such a decision; even if the difference i= s made clear in the text, it is such a subtle distinction that it is unlike= ly to be implemented correctly.

Unrelated to the 6665 issues, I have some additional comments. At the top o= f page 9, there is a statement that the proxies to which proxies should sub= scribe can be learned from the signaling messages sent and received. I thin= k we need some guidance about when this learned information can be purged. Presumably we don't want a single = interaction between proxies to result in a subscription that is kept in pla= ce for the rest of all time.

Near the top of page 16, the document specifies that elements containing mu= ltiple <one>, <except>, and <many> elements are ORed toge= ther. I don't think this is quite what you intend. If you have a <many&g= t; and an <except>, you don't really want to match everything that is in the <many> OR everything excluded by the <exclude>.= I can kind of figure out what you really meant, but the language needs to = be adjusted to actually say it.

On page 19, one of the specified actions is "drop." There is pass= ing implication that doing this over an unreliable link will cause retransm= issions. This needs more treatment in the text. In fact, as dropping reques= ts over an unreliable link will *always* make overload worse rather than better, I would strongly recommend that we add = text that specifies that any "drop" rule applied to an unreliable= transport MUST be treated as if it were "reject."

Similarly, we run into an issue in which an ACK response to a 200 is droppe= d, as doing so will cause the 200 to be retransmitted, which again exacerba= tes any overload condition that may arise. In other words, I think we need = to specify that "drop" cannot be applied to ACK (and reject clearly can't, since ACK never sees a response)= -- so ACKs must always go through regardless of overload filters. For the = same reason, proxies that receive an ACK response to a non-200 need to alwa= ys process the ACK rather than dropping it.

 

   [BC]= I don’t think this can happen. The current text says that “Con= ditions are evaluated on receipt of an initial SIP request for a dialog or

 standalone transaction”. So my underst= anding is that conditions are not evaluated on receipt of an ACK. Moreover, the “ACK” is not a valid value for the <method> element = and the current text says that when the <method> element is not inclu= ded in a filter, the rule actions are applicable to all initial methods. A = formal definition of initial method may be missing but I assume ACK is not an initial method.

On the other hand, I’m wondering whether thi= s comment about ACK should not be made against draft-ietf-soc-overload-cont= rol, section 5.10?



On to topic of rejects, I note that the current draft simply gives an examp= le (500 Server Internal Error) rather than specifying how rejection is perf= ormed. This will make troubleshooting a system more difficult. I would sugg= est that we add a new 500-class error code that is used to indicate this sp= ecific situation. We also need to think about whether "Retry-After&quo= t; handling is appropriate in this case. I think it is, but we need to work through how it is set (i.e., is it part o= f the overload rule, or is it set by the server itself?)

 

[BC] Is there any reason for rejecting calls with = a different response code depending on whether overload control information was obtained using the feedback-based or even-based solution? = I guess the answer is no. Section 5.10.2 of draft-ietf-soc-overload-control= says that the SIP server must reject requests with a 503 response.



Finally, I note that we have a "forward" rule. I think we = would be well served by a very similar "redirect" rule that sends= a 300-class response rather than forwarding the request to an alternate de= stination.

Small editorial nit: while the use of the date "79 AD" in the exa= mple at the top of page 21 is both clever and amusing to those who have bot= h received an education on the topic of Vesuvius' destruction of Pompeii an= d recall its details, the use of a two-digit year in an example is likely to lead to confusion on the part of implement= ors. We really don't need examples from which implementors might incorrectl= y infer that omitting the century portion of the year in ISO-style dates is= acceptable.

Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly = we can cite an international specification for the discussion of call gappi= ng -- doesn't Q.1248 cover this?. It seems a bit provincial to = use a Bellcore spec to the exclusion of an ITU-T spec in the context of a d= ocument to be published by an international standards body such as the IETF= .

/a

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles 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 el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation 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 dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_88CAD1D4E8773F42858B58CAA28272A00754BFPEXCVZYM12corpora_--