From nobody Sat Mar 1 15:08:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C7B1A0AEF for ; Sat, 1 Mar 2014 15:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVwPjIEjl2OH for ; Sat, 1 Mar 2014 15:08:10 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDFD1A0AEA for ; Sat, 1 Mar 2014 15:08:10 -0800 (PST) Received: from ip-64-134-25-189.public.wayport.net ([64.134.25.189]:49643 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WJt0n-0004Yt-TW for dime@ietf.org; Sat, 01 Mar 2014 15:08:07 -0800 Message-ID: <53126856.5070302@usdonovans.com> Date: Sat, 01 Mar 2014 17:08:06 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dime@ietf.org References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <30695D73-312B-498D-A855-B1FA5A0FF27D@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4F3D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B4F3D@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------070100040000090807040403" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4a4O1mLjXfDW4B-z-PynJRN8PAU Subject: Re: [Dime] Issue#32 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 23:08:13 -0000 This is a multi-part message in MIME format. --------------070100040000090807040403 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit agreed On 2/28/14 9:37 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > I think so; not required, not desired. > > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Friday, February 28, 2014 4:30 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] Issue#32 status > > > Going back in history.. > > On Feb 19, 2014, at 5:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> #32: Sequence-Number Time-Stamp values within OC-OLR >> >> I understand that we agreed the following principles: >> >> Sequence-Number is of type Time, however the value need not correspond to the point in time of generation. >> >> When generated, a new sequence number must be greater than any sequence number previously generated by the same node (including over a reboot of that node) >> >> When received, a sequence number is used to detect outdates/replays/freshness. >> >> Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes. >> >> >> I did not understand the requirement for globally uniqueness as introduced by Jouni. >> Can Jouni please explain. > Originated from here: > http://www.ietf.org/mail-archive/web/dime/current/msg06600.html > > So requiring global uniqueness is not desired anymore? > > - Jouni > > > >> >> Ulrich >> >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------070100040000090807040403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit agreed

On 2/28/14 9:37 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
I think so; not required, not desired.

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Friday, February 28, 2014 4:30 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org
Subject: Re: [Dime] Issue#32 status


Going back in history..

On Feb 19, 2014, at 5:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

#32: Sequence-Number Time-Stamp values within OC-OLR
 
I understand that we agreed the following principles:
 
Sequence-Number is of type Time, however the value need not correspond to the point in time of generation.
 
When generated, a new sequence number must be  greater than any sequence number previously generated by the same node (including over a reboot of that node)
 
When received, a sequence number is used to detect outdates/replays/freshness.
 
Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.
 
 
I did not understand the requirement for globally uniqueness as introduced by Jouni.
Can Jouni please explain.
Originated from here:
http://www.ietf.org/mail-archive/web/dime/current/msg06600.html

So requiring global uniqueness is not desired anymore? 

- Jouni



 
Ulrich
 
 
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


--------------070100040000090807040403-- From nobody Sat Mar 1 15:22:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5BE1A0B12 for ; Sat, 1 Mar 2014 15:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00QcNuCG8il5 for ; Sat, 1 Mar 2014 15:22:13 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 3C29E1A0AF9 for ; Sat, 1 Mar 2014 15:22:13 -0800 (PST) Received: from ip-64-134-25-189.public.wayport.net ([64.134.25.189]:49670 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WJtEL-0001xj-V3 for dime@ietf.org; Sat, 01 Mar 2014 15:22:10 -0800 Message-ID: <53126B9E.7030004@usdonovans.com> Date: Sat, 01 Mar 2014 17:22:06 -0600 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dime@ietf.org References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <29459_1391615624_52F25E88_29459_734_1_6B7134B31289DC4FAF731D844122B36E4873CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <29FCFFE7-64BF-4928-A3DF-F2FC0D1EFBC6@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B23D7@DEMUMBX014.nsn-intra.net> <52F3AF0D.3050306@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B253C@DEMUMBX014.nsn-intra.net> <855AE46B-9E69-452E-A8C7-9AA26019A4B4@gmail.com> <14044_1392040069_52F8D885_14044_469_1_6B7134B31289DC4FAF731D844122B36E4975BB@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52F8DB0C.3000603@usd onovans.com> <087A34937E64E74E848732CFF8354B920977322F@ESESSMB101.ericsson.se> <0D5D9C6F-5233-4987-99C4-A257382917EC@gmail.com> <52FCB9D6.3070908@usdonovans.com> <2771A62F-E982-4A31-A827 -E2C4AC14132B@nostrum.com> <90D54457-ADE1-4A18-8F14-F8CA0D47EC56@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4F0F@DEMUMBX014.nsn-intra.net> <4EB283C1-1B81-400A-8617-A07A6FAAB034@gmail.com> In-Reply-To: <4EB283C1-1B81-400A-8617-A07A6FAAB034@gmail.com> Content-Type: multipart/alternative; boundary="------------020103070504090602010600" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8UA7K_jYUqHZjmZDnXjAEHKykCc Subject: [Dime] Closing issues (was Re: [dime] #32: Sequence-Number Time-Stamp values within OC-OLR) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 23:22:18 -0000 This is a multi-part message in MIME format. --------------020103070504090602010600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Jouni, The reason I suggested the wording on when to close an issue is that a number of the resolutions are still based on concepts and not on final wording. We can either put the suggested final wording in the ticket or in the -02 draft and let people review it for final agreement. We can change the practice if the group wants, this just seemed the most logical approach at the time. Steve On 2/28/14 9:43 AM, Jouni Korhonen wrote: > First.. sorry for missing the continuum of the thread. My _bad_ mistake. > > > On Feb 28, 2014, at 5:07 PM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> Dear Jouni, >> My understanding is that #32 is RESOLVED as follows: >> >> Agreed - Sequence-Number is of type Unsigned64. > This is/was ok, since time did not really fit anymore what was concluded even earlier. > >> Agreed - When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node). > Ok. > >> Note: this allows sequence numbers to start at 1 for the initial occurrence of an overload condition at a reporting node (where "initial occurrence means something like "moving from no overload to overload after a sufficiently long periode of no overload"). >> When received, a sequence number is used to detect outdates/replays/freshness. >> >> Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes. > Ok. > >> Can be CLOSED when the next version of the draft correctly reflects this agreement. > Different practises. In some groups we did close tickets once the proposed > change & conclusion was documented in the issue tracker. > > One should still update the ticket to contain the conclusion even before > closing it. There is a place for comments. Makes it much easier to track > down the conclusions. (as seen here how easily one misses even a thread > of mails..) > > - Jouni > >> Ulrich >> >> >> >> >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Friday, February 28, 2014 3:01 PM >> To: dime@ietf.org list; Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com Morand >> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >> >> >> >> >> It seems we reached a conclusion here. So summarizing: >> >> o Document that the sequence number is: >> - Globally/eternally unique. >> - increase monotonically over time, including over a reboot. >> o Write a non-normative recommendation/suggestion how to create >> sequence numbers fulfilling the above requirements (e.g. using >> NTP as one component). >> >> @Ulrich or Lionel could you update the above into the ticket >> and close it? >> >> >> >> - JOuni >> >> >> On Feb 14, 2014, at 11:28 PM, Ben Campbell wrote: >> >>> +1. It doesn't even have to be "suggested" in the since of a (non-normative) recommendation. It can merely be an example of an approach which meets the stated requirements. >>> >>> On Feb 13, 2014, at 6:25 AM, Steve Donovan wrote: >>> >>>> Jouni, >>>> >>>> The important thing is to define the properties. There should be no harm in giving one suggested implementation. >>>> >>>> Steve >>>> >>>> On 2/11/14 4:42 PM, Jouni Korhonen wrote: >>>>> If the NTP is only going to be guidance when building the globally >>>>> and eternally unique sequence number, IMHO better not mention NTP >>>>> then at all. Just include the required properties below. One less >>>>> mandatory reference.. >>>>> >>>>> - Jouni >>>>> >>>>> >>>>> On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome >>>>> >>>>> wrote: >>>>> >>>>> >>>>>> It sounds reasonable to me as well. >>>>>> /MCruz >>>>>> >>>>>> From: DiME [ >>>>>> mailto:dime-bounces@ietf.org >>>>>> ] On Behalf Of Steve Donovan >>>>>> Sent: lunes, 10 de febrero de 2014 14:59 >>>>>> To: >>>>>> dime@ietf.org >>>>>> >>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> +1 >>>>>> On 2/10/14 7:47 AM, >>>>>> lionel.morand@orange.com >>>>>> wrote: >>>>>> I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are: >>>>>> >>>>>> - Globally/eternally unique >>>>>> - increase monotonically over time, including over a reboot (as remind by Steve) >>>>>> >>>>>> The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties. >>>>>> >>>>>> Lionel >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : DiME [ >>>>>> mailto:dime-bounces@ietf.org >>>>>> ] De la part de Jouni Korhonen >>>>>> Envoyé : samedi 8 février 2014 11:33 >>>>>> À : Wiehe, Ulrich (NSN - DE/Munich) >>>>>> Cc : >>>>>> dime@ietf.org >>>>>> >>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> >>>>>> Sounds acceptable. Would the following then work for all: >>>>>> >>>>>> o clarify that once the overload report expires there is no >>>>>> reason to remember anything about it >>>>>> o the sequence number would be similar to session-id.. based >>>>>> on the NTP time + any vendor specific data to make it >>>>>> "globally and eternally unique". >>>>>> >>>>>> - Jouni >>>>>> >>>>>> >>>>>> >>>>>> On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" >>>>>> >>>>>> wrote: >>>>>> >>>>>> Steve, >>>>>> >>>>>> sounds like an acceptable proposal which allows to come back to sync after OLR expiry. >>>>>> This requires however an update of clause 5.5.2 to clearly state >>>>>> Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. >>>>>> >>>>>> >>>>>> Ulrich >>>>>> >>>>>> From: DiME [ >>>>>> mailto:dime-bounces@ietf.org >>>>>> ] On Behalf Of ext Steve Donovan >>>>>> Sent: Thursday, February 06, 2014 4:50 PM >>>>>> To: >>>>>> dime@ietf.org >>>>>> >>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> A couple of things - >>>>>> >>>>>> The requirement is that the sequence number increase monotonically over time, including over a reboot. Use of NTP time is one way of doing this but is not the only way. Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent. This actually has better properties than an NTP time stamp as it would take much longer to roll over. One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot. >>>>>> >>>>>> We also have a duration timer on overload reports. This gives us one way to reset. It should only be required to remember the sequence number of an active overload report. Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. >>>>>> >>>>>> The requirement we need is similar to the session-id in the base Diameter specification. The wording there is -- "The Session-Id MUST be globally and eternally unique". We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report. >>>>>> >>>>>> It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..." >>>>>> >>>>>> Steve >>>>>> >>>>>> On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >>>>>> I cannot understand what is the problem with mandating timestamp. >>>>>> But I can see interoperability problems with the current definition: >>>>>> >>>>>> Assume the sender sends sequence numbers >>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 3, 3, ... 3, 4, 4, ... 4, 5,.... >>>>>> but the receicer for any reason receives >>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3, ... 3, 4, 4, ... 4, 5,.... >>>>>> The receiver would accept >>>>>> 1, 1, ... 1, 2, 2, ... 2, 3, 30000 >>>>>> and then silently discards >>>>>> 3, ... 3, 4, 4, ... 4, 5,.... 4, 5, .... >>>>>> with no way to come back to sync. >>>>>> >>>>>> Are we sure that this cannot happen? >>>>>> >>>>>> Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way. >>>>>> >>>>>> Ulrich >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [ >>>>>> mailto:dime-bounces@ietf.org >>>>>> ] On Behalf Of ext Ben Campbell >>>>>> Sent: Wednesday, February 05, 2014 4:57 PM >>>>>> To: ext >>>>>> lionel.morand@orange.com >>>>>> >>>>>> Cc: >>>>>> dime@ietf.org >>>>>> >>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to meet the interop requirements, but it is not, in itself, an interop requirement. >>>>>> >>>>>> On Feb 5, 2014, at 9:53 AM, >>>>>> >>>>>> wrote: >>>>>> >>>>>> Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST". >>>>>> We are not violating anything. >>>>>> >>>>>> Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues. >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : Ben Campbell [ >>>>>> mailto:ben@nostrum.com >>>>>> ] >>>>>> Envoyé : mercredi 5 février 2014 16:47 >>>>>> À : MORAND Lionel IMT/OLN >>>>>> Cc : Steve Donovan; >>>>>> dime@ietf.org >>>>>> >>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following: >>>>>> >>>>>> "In particular, [normative requirements] MUST only be used where it is >>>>>> actually required for interoperation or to limit behavior which has >>>>>> potential for causing harm (e.g., limiting retransmisssions) " >>>>>> >>>>>> The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this. >>>>>> >>>>>> On Feb 5, 2014, at 9:37 AM, >>>>>> lionel.morand@orange.com >>>>>> wrote: >>>>>> >>>>>> I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic. >>>>>> >>>>>> Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone? >>>>>> >>>>>> Lionel >>>>>> >>>>>> De : DiME [ >>>>>> mailto:dime-bounces@ietf.org >>>>>> ] De la part de Steve Donovan >>>>>> Envoyé : mercredi 5 février 2014 15:34 >>>>>> À : >>>>>> dime@ietf.org >>>>>> >>>>>> Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> How the sequence number is implemented is an implementation decision. There is no reason to mandate that is be an NTP timestamp. That should be included only as one way of addressing the requirement. >>>>>> >>>>>> Steve >>>>>> >>>>>> On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote: >>>>>> I also agree. >>>>>> >>>>>> Regards, >>>>>> Nirav. >>>>>> >>>>>> -----Original Message----- >>>>>> From: DiME [ >>>>>> mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com >>>>>> >>>>>> Sent: Tuesday, February 04, 2014 11:50 PM >>>>>> To: >>>>>> dime@ietf.org >>>>>> >>>>>> Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> The existing wording seems actually fuzzy. >>>>>> If it is "like an NTP timestamp", be proud and say it loud! >>>>>> >>>>>> In summary: ok with the proposal if it clarifies this handling of this sequence-number. >>>>>> >>>>>> Lionel >>>>>> >>>>>> -----Message d'origine----- >>>>>> De : dime issue tracker [ >>>>>> mailto:trac+dime@trac.tools.ietf.org >>>>>> ] >>>>>> Envoyé : mardi 4 février 2014 09:50 >>>>>> À : MORAND Lionel IMT/OLN >>>>>> Cc : >>>>>> dime@ietf.org >>>>>> >>>>>> Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> #32: Sequence-Number Time-Stamp values within OC-OLR >>>>>> >>>>>> The -01 draft says in clause 4.4: >>>>>> From the functionality point of view, the OC-Sequence-Number AVP MUST >>>>>> be used as a non-volatile increasing counter between two overload >>>>>> control endpoints (neglecting the fact that the contents of the AVP >>>>>> is a 64-bit NTP timestamp [RFC5905]). The sequence number is only >>>>>> required to be unique between two overload control endpoints. >>>>>> Sequence numbers are treated in uni-directional manner, i.e. two >>>>>> sequence numbers on each direction between two endpoints are not >>>>>> related or correlated. >>>>>> >>>>>> When generating sequence numbers, the new sequence number MUST be >>>>>> greater than any sequence number previously seen between two >>>>>> endpoints within a time window that tolerates the wraparound of the >>>>>> NTP timestamp (i.e. approximately 68 years). >>>>>> >>>>>> >>>>>> With this mechanism it is difficult to get back to sync once you are out of sync (for whatever reason). >>>>>> It is proposed to mandate that the Sequence Number is a real 64-bit NTP timestamp (RFC5905) indicating the point in time when the OLR was created, and to mandate that OLRs with a time stamp higher than time of reception must be ignored by the reacting node. >>>>>> >>>>>> >>>>>> _________________________________________________________________________________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>>> >>>>>> _________________________________________________________________________________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>>> _________________________________________________________________________________________________________________________ >>>>>> >>>>>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >>>>>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>>>> >>>>>> This message and its attachments may contain confidential or privileged information that may be protected by law; >>>>>> they should not be distributed, used or copied without authorisation. >>>>>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>>>>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>>>>> Thank you. >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> DiME mailing list >>>>>> >>>>>> DiME@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> _______________________________________________ >>>>> DiME mailing list >>>>> >>>>> DiME@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dime >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------020103070504090602010600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Jouni,

The reason I suggested the wording on when to close an issue is that a number of the resolutions are still based on concepts and not on final wording.  We can either put the suggested final wording in the ticket or in the -02 draft and let people review it for final agreement.

We can change the practice if the group wants, this just seemed the most logical approach at the time.

Steve


On 2/28/14 9:43 AM, Jouni Korhonen wrote:
First.. sorry for missing the continuum of the thread. My _bad_ mistake.


On Feb 28, 2014, at 5:07 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

Dear Jouni,
My understanding is that #32 is RESOLVED as follows:

Agreed - Sequence-Number is of type Unsigned64.
This is/was ok, since time did not really fit anymore what was concluded even earlier.
 
Agreed - When generated, a new sequence number must be greater than the sequence number contained in the active overload report to which it applies (including over reboot of that node).
Ok.

Note: this allows sequence numbers to start at 1 for the initial occurrence of an overload condition at a reporting node (where "initial occurrence means something like "moving from no overload to overload after a sufficiently long periode of no overload"). 
When received, a sequence number is used to detect outdates/replays/freshness.

Sequence numbers of expired OLRs MUST NOT be remembered by reacting nodes.
Ok.

Can be CLOSED when the next version of the draft correctly reflects this agreement.
Different practises. In some groups we did close tickets once the proposed
change & conclusion was documented in the issue tracker.

One should still update the ticket to contain the conclusion even before
closing it. There is a place for comments. Makes it much easier to track
down the conclusions. (as seen here how easily one misses even a thread
of mails..)

- Jouni

Ulrich




-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Friday, February 28, 2014 3:01 PM
To: dime@ietf.org list; Wiehe, Ulrich (NSN - DE/Munich); lionel.morand@orange.com Morand
Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


<as a chair>

It seems we reached a conclusion here. So summarizing:

o Document that the sequence number is:
- Globally/eternally unique.
- increase monotonically over time, including over a reboot.
o Write a non-normative recommendation/suggestion how to create
 sequence numbers fulfilling the above requirements (e.g. using
 NTP as one component).

@Ulrich or Lionel could you update the above into the ticket
and close it?



- JOuni


On Feb 14, 2014, at 11:28 PM, Ben Campbell <ben@nostrum.com> wrote:

+1. It doesn't even have to be "suggested" in the since of a (non-normative) recommendation. It can merely be an example of an approach which meets the stated requirements.

On Feb 13, 2014, at 6:25 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Jouni,

The important thing is to define the properties.  There should be no harm in giving one suggested implementation.

Steve

On 2/11/14 4:42 PM, Jouni Korhonen wrote:
If the NTP is only going to be guidance when building the globally
and eternally unique sequence number, IMHO better not mention NTP
then at all. Just include the required properties below. One less
mandatory reference..

- Jouni


On Feb 11, 2014, at 11:59 PM, Maria Cruz Bartolome 
<maria.cruz.bartolome@ericsson.com>
wrote:


It sounds reasonable to me as well.
/MCruz

From: DiME [
mailto:dime-bounces@ietf.org
] On Behalf Of Steve Donovan
Sent: lunes, 10 de febrero de 2014 14:59
To: 
dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

+1
On 2/10/14 7:47 AM, 
lionel.morand@orange.com
wrote:
I would add, maybe even before the format (NTP time based), that the real requirements for the sequence-number are:

- Globally/eternally unique
- increase monotonically over time, including over a reboot (as remind by Steve) 

The NTP time based type is just a guidance provided by the draft on how to generate sequence numbers with such properties.

Lionel

-----Message d'origine-----
De : DiME [
mailto:dime-bounces@ietf.org
] De la part de Jouni Korhonen
Envoyé : samedi 8 février 2014 11:33
À : Wiehe, Ulrich (NSN - DE/Munich)
Cc : 
dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR


Sounds acceptable. Would the following then work for all:

o clarify that once the overload report expires there is no
reason to remember anything about it
o the sequence number would be similar to session-id.. based 
on the NTP time + any vendor specific data to make it 
"globally and eternally unique".

- Jouni



On Feb 7, 2014, at 1:00 PM, "Wiehe, Ulrich (NSN - DE/Munich)" 
<ulrich.wiehe@nsn.com>
wrote:

Steve,

sounds like an acceptable proposal which allows to come back to sync after OLR expiry.
This requires however an update of clause 5.5.2 to clearly state
Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 


Ulrich

From: DiME [
mailto:dime-bounces@ietf.org
] On Behalf Of ext Steve Donovan
Sent: Thursday, February 06, 2014 4:50 PM
To: 
dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

A couple of things - 

The requirement is that the sequence number increase monotonically over time, including over a reboot.  Use of NTP time is one way of doing this but is not the only way.  Someone could, for instance, use a time stamp to set the sequence number for the first overload report sent after a reboot and then increment the sequence number value by one for each subsequent overload report sent.  This actually has better properties than an NTP time stamp as it would take much longer to roll over.  One could also create a global sequence number service that is not tied to time and have a Diameter server query that global sequence number server after each reboot.

We also have a duration timer on overload reports.  This gives us one way to reset.  It should only be required to remember the sequence number of an active overload report.  Once the overload report expires there is no reason to remember anything about it and the next overload report received could, conceivably have any value. 

The requirement we need is similar to the session-id in the base Diameter specification.  The wording there is -- "The Session-Id MUST be globally and eternally unique".  We just need eternally as the spacial differentiation is based on the context of the message carrying the overload report.

It would be perfectly valid for the DOIC draft to suggest the use of NTP timestamps to populate the sequence number but it should be worded in a similar fashion as the Diameter base RFC -- The Session-Id includes a mandatory portion and an implementation-defined portion; a recommended format for the implementation-defined portion is outlined below ..."

Steve

On 2/6/14 7:12 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
I cannot understand what is the problem with mandating timestamp.
But I can see interoperability problems with the current definition:

Assume the sender sends sequence numbers
1, 1, ... 1, 2, 2, ... 2, 3, 3, 3,  ... 3, 4, 4, ... 4, 5,.... 
but the receicer for any reason receives 
1, 1, ... 1, 2, 2, ... 2, 3, 30000, 3,  ... 3, 4, 4, ... 4, 5,.... 
The receiver would accept
1, 1, ... 1, 2, 2, ... 2, 3, 30000
and then silently discards
3,  ... 3, 4, 4, ... 4, 5,....  4, 5, .... 
with no way to come back to sync.

Are we sure that this cannot happen?

Mandating timestamp for sequence number generation at the sender and plausibility checking (i.e. received value must be between stored value and time of reception) for the receiver may not be the only way to solve the problem. But in the moment I don't see another way.

Ulrich


-----Original Message-----
From: DiME [
mailto:dime-bounces@ietf.org
] On Behalf Of ext Ben Campbell
Sent: Wednesday, February 05, 2014 4:57 PM
To: ext 
lionel.morand@orange.com

Cc: 
dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

My point is, we have an interop requirement that the sequence number always increases over time scope. We do not have the interop requirement that the sequence number be implemented as a time stamp. A time stamp is probably a good way to  meet the interop requirements, but it is not, in itself, an interop requirement.

On Feb 5, 2014, at 9:53 AM, 
<lionel.morand@orange.com> <lionel.morand@orange.com>
wrote:

Not sure to understand: if there is a kind of "interop requirement", it is a case for a "MUST".
We are not violating anything.

Reporting and reacting nodes will just rely on the Diameter interfaces to know how to handle the received sequence-number. So any MUST on the format of the sequence-number is acceptable if it avoids interop issues.

-----Message d'origine-----
De : Ben Campbell [
mailto:ben@nostrum.com
] 
Envoyé : mercredi 5 février 2014 16:47
À : MORAND Lionel IMT/OLN
Cc : Steve Donovan; 
dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

I concur with Steve on this one. Using a time stamp is a good way to meet the requirements, but it's not our job to normatively state an implementation. In fact, it violates an RFC 2119 "MUST" level requirement to do so. Section 6 of 2119 includes the following:

"In particular, [normative requirements] MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions)  "

The only appropriate reason to require a timestamp would be if we expected peers to interpret the field as a point in time. OTOH, it would be perfectly reasonable to state the actual interop requirements, then add a non-normative (probably indented) paragraph suggesting that a timestamp is a good way to do this.

On Feb 5, 2014, at 9:37 AM, 
lionel.morand@orange.com
wrote:

I think the out-of-sync failover described by Ulrich is a good use case to mandate a specific semantic.

Is there any specific NOT to mandate the use of NTP timestamps if it is a simple way to solve the possible issues and please everyone?

Lionel

De : DiME [
mailto:dime-bounces@ietf.org
] De la part de Steve Donovan
Envoyé : mercredi 5 février 2014 15:34
À : 
dime@ietf.org

Objet : Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

How the sequence number is implemented is an implementation decision.  There is no reason to mandate that is be an NTP timestamp.  That should be included only as one way of addressing the requirement.

Steve

On 2/4/14 10:27 PM, Nirav Salot (nsalot) wrote:
I also agree.

Regards,
Nirav.

-----Original Message-----
From: DiME [
mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com

Sent: Tuesday, February 04, 2014 11:50 PM
To: 
dime@ietf.org

Subject: Re: [Dime] [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

The existing wording seems actually fuzzy.
If it is "like an NTP timestamp", be proud and say it loud!

In summary: ok with the proposal if it clarifies this handling of this sequence-number.

Lionel

-----Message d'origine-----
De : dime issue tracker [
mailto:trac+dime@trac.tools.ietf.org
]
Envoyé : mardi 4 février 2014 09:50
À : MORAND Lionel IMT/OLN
Cc : 
dime@ietf.org

Objet : [dime] #32: Sequence-Number Time-Stamp values within OC-OLR

#32: Sequence-Number Time-Stamp values within OC-OLR

The -01 draft says in clause 4.4:
 From the functionality point of view, the OC-Sequence-Number AVP MUST
 be used as a non-volatile increasing counter between two overload
 control endpoints (neglecting the fact that the contents of the AVP
 is a 64-bit NTP timestamp [RFC5905]).  The sequence number is only
 required to be unique between two overload control endpoints.
 Sequence numbers are treated in uni-directional manner, i.e. two
 sequence numbers on each direction between two endpoints are not
 related or correlated.

 When generating sequence numbers, the new sequence number MUST be
 greater than any sequence number previously seen between two
 endpoints within a time window that tolerates the wraparound of the
 NTP timestamp (i.e. approximately 68 years).


With this mechanism it is difficult to get back to sync once you are out  of sync (for whatever reason).
It is proposed to mandate that the Sequence Number is a real 64-bit NTP  timestamp (RFC5905) indicating the point in time when the OLR was created,  and to mandate that  OLRs with a time stamp higher than time of reception  must be ignored by the reacting node.


_________________________________________________________________________________________________________________________

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

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

_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



_________________________________________________________________________________________________________________________

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

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

_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


_________________________________________________________________________________________________________________________

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

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

_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list

DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

      
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


--------------020103070504090602010600-- From nobody Sun Mar 2 04:29:58 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06ED81A0C8A for ; Sun, 2 Mar 2014 04:29:57 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71glAHmgkbL6 for ; Sun, 2 Mar 2014 04:29:54 -0800 (PST) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id E7E561A0C85 for ; Sun, 2 Mar 2014 04:29:53 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id p61so901241wes.27 for ; Sun, 02 Mar 2014 04:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1aQ8c8Vbgyvgz8EmtqwELh3cMidIvz4FBOoi3aJI0hI=; b=BVg7oIMbqretmRP6uH5AbbibNcalSvYaLhTkNc4s1j9fyM3tuPDCywYJuCeIvFccIl R9LD6UKNmdvZ+L4skKqn/0rA+ruPl0ylkYAqXfYT1z/NGKYDZCBwc3tjX0D6G1C7l5bc SKyY44fqxc4qIghBFD0Ps9ON+Wkr4Lro6d3m6FsnfzAb4YmcBkMCJfJR2lFZZBld/r2v mD0IU4rK9qJh0NKvpjOG2GSQ4uZK4txxrW29m5mJElPN3eLPH2xos0P6kGhxd7NtrA6f bcWE6VPywZH5tHx0VYX+gZTHviXoBf64TGDYFVrukiyZxK4rNS9DrBKYuahNNaAlEQL5 oobg== X-Received: by 10.180.189.43 with SMTP id gf11mr10025430wic.32.1393763390985; Sun, 02 Mar 2014 04:29:50 -0800 (PST) Received: from dhcp-b491.meeting.ietf.org (dhcp-b491.meeting.ietf.org. [31.133.180.145]) by mx.google.com with ESMTPSA id u6sm24587449wif.6.2014.03.02.04.29.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 02 Mar 2014 04:29:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net> Date: Sun, 2 Mar 2014 12:29:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vNC6HsVvtMnOlS1tCrKUsF3n8HM Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 12:29:57 -0000 Ulrich, A couple of observations. In general OK to do rewording this part but more work is needed with the actual text. See some comments inline: On Feb 24, 2014, at 11:44 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > There has been no discussion of this ticket. >=20 > I propose to replace text in claues 5.5.1 as suggested in the ticket. >=20 > Regards > Ulrich >=20 >=20 > -----Original Message----- > From: ext dime issue tracker = [mailto:trac+dime@grenache.tools.ietf.org]=20 > Sent: Tuesday, February 18, 2014 1:35 PM > To: draft-docdt-dime-ovli@tools.ietf.org; Wiehe, Ulrich (NSN - = DE/Munich) > Cc: dime@ietf.org > Subject: [dime] #56: Bad Description of Overload Control State >=20 > #56: Bad Description of Overload Control State >=20 > The description of Overload Control State in clause 5.5.1 is = inaccurate, > incomplete and could be misleading. It does not differentiate between > Overload Control State in a reacting node versus Overload Control = State in > a reporting node. It also does not describe how Overload Control = States > are maintained. >=20 > It is proposed to replace current text with the following: >=20 >=20 > 5.5.1. Overload Control State (OCS) >=20 > 5.5.1.1 Overload Control States for reacting nodes >=20 > A reacting node (client) maintains per supported Diameter = application > a host-type Overload Control State for each Destination-Host = towards > which it sends host-type requests and a realm-type Overload Control > State > for each Destination-Realm toward which it sends realm-type = requests. > A host-type Overload Control State may be identified by the pair of > Application-Id and Destination-Host; a realm-type Overload Control > State Do I understand correctly that you basically propose having a separate state "object" for each OC-Report-Type?=20 > may be identified by the pair of Application-Id and = Destination-Realm. > The host-type/realm-type Overload Control State for a given pair of > Application and Destination-Host / Destination-Realm could include = the > information as shown in table 1/table 2. >=20 > >=20 > Agents that take the role of a reacting node on behalf of clients = MUST > maintain Overload Control States per client. Since we are not going to define the internal structure and = implementation=20 of the overload control state exactly I am a bit cautious going beyond = listing what goes into the state. Also, having MUSTs need to be weighted very = carefully. > 5.5.1.2 Overload Control States for reporting nodes >=20 > A reporting node (server) maintains per supported Diameter = application > an Overload Control State for each Origin-Host from which it = receives > requests that contain an (explicit or implicit) indication of > OLR_DEFAULT_ALGO support. >=20 > A reporting node (agent that is configured to take the role of a > reporting node for a given realm) maintains per supported Diameter > application an Overload Control State for each Origin-Host from = which > it > receives realm-type requests (of that given realm) that contain an > (explicit or implicit) indication of OLR_DEFAULT_ALGO support. >=20 > A Overload Control State may be identified by the pair of = Application- > Id > and Origin-Host. >=20 > The Overload Control State for a given pair of Application and = Origin- > Host could include the information as shown in table 3. > >=20 > Note: For nodes that support other features than just = OLR_DEFAULT_ALGO > the Overload Control State definitions may need to be extended. Or just state the overload control state need to be flexible enough to support multiple abatement algorithms in the future? > 5.5.1.3 Maintaining Overload Control States >=20 > Reacting nodes create a host-type OCS with OCS-Id =3D (x,A) when > receiving > an answer message of application x containing an Orig-Host of A and = a > host-type OC-OLR AVP unless such host-type OCS already exists. >=20 > Reacting nodes create a realm-type OCS with OCS-Id =3D (x,A) when > receiving > an answer message of application x containing an Orig-Realm of A = and a > realm-type OC-OLR AVP unless such realm type OCS already exists. >=20 > Reacting nodes delete an OCS when it expires (i.e. when current = time > minus reception time is greater than validity duration). >=20 > Reacting nodes update the host-type OCS with OCS-Id =3D (x,A) when > receiving an answer message of application x containing an = Orig-Host of > A and a host-type OC-OLR AVP with a sequence number higher than the > stored sequence number. And what about the abatement algorithm? Don't we have a dependency here to Issue #30? I.e. the reacting node would need to take the algorithm also into account? - JOuni >=20 > Reacting nodes update the realm-type OCS with OCS-Id =3D (x,A) when > receiving an answer message of application x containing an = Orig-Realm > of > A and a realm-type OC-OLR AVP with a sequence number higher than = the > stored sequence number. >=20 > Reporting nodes create an OCS with OCS-Id =3D (x,A) when receiving = a > request (indicating support of OLR_DEFAULT_ALGO) of application x > containing an Orig-Host of A unless such OCS already exists. >=20 > Reporting nodes delete an OCS when it expires. >=20 > Reporting nodes update the OCS with OCS-Id =3D (x,A) when they = detect the > need to modify the requested amount of application x traffic = reduction > generated by A. >=20 > --=20 > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-docdt-dime- > ulrich.wiehe@nsn.com | ovli@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: draft- | Version: > docdt-dime-ovli | Keywords: > Severity: Active WG | > Document | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Mar 3 00:25:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99FD21A04B8 for ; Mon, 3 Mar 2014 00:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJJRJBUtJufh for ; Mon, 3 Mar 2014 00:25:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id CFEFD1A0191 for ; Mon, 3 Mar 2014 00:25:09 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 0993622C232; Mon, 3 Mar 2014 09:25:06 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DD5834C06B; Mon, 3 Mar 2014 09:25:05 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 3 Mar 2014 09:25:05 +0100 From: To: Jouni Korhonen , Ben Campbell Thread-Topic: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC Thread-Index: AQHPNK0OV9RNGSSwP0K5DyToUe8DUZrPCTHQ Date: Mon, 3 Mar 2014 08:25:04 +0000 Message-ID: <28213_1393835105_53143C61_28213_3217_1_6B7134B31289DC4FAF731D844122B36E4D926D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.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.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.3.53017 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bshdmc6C68SZs4oxJYKouy7DO1g Cc: "dime@ietf.org" Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 08:25:12 -0000 Hi Jouni, Doing a separate I-D updating the RFC6733 to provide guidelines and recomme= ndations on the use of TOO_BUSY and non-answer cases was already proposed i= n Porto. This is needed independently of the DOIC mechanism. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Envoy=E9=A0: vendredi 28 f=E9vrier 2014 18:46 =C0=A0: Ben Campbell Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Cli= ent that does not support DOIC Ben, On Feb 25, 2014, at 1:11 AM, Ben Campbell wrote: >=20 > On Feb 24, 2014, at 12:40 PM, Steve Donovan wr= ote: >=20 >> There has been no discussion of ticket #27. I can't even find it on the= DIME list, so I'm copying it here to initiate discussion. >>=20 >> The proposal is for an agent to send a TOO-BUSY response when it throttl= es a request from a non supporting client. The behavior of the agent in th= is case would be in the new section to be added to capture agent behavior a= s proposed in issue #24 (and various other places). >>=20 >=20 > RFC6733 has the following to say about TOO_BUSY >=20 > "When returned, a Diameter node SHOULD attempt to send the message to an = alternate peer. This error MUST only be used when a specific server is req= uested, and it cannot provide the requested saervice." "when a specific server is requested" means the use of Destination-Host to = me. > Do those semantics and limitations apply to this usage? Is there a chance= if incorrect behavior from a client that doesn't support DOIC, and therefo= re is not aware of this new usage of TOO_BUSY? For example, if an agent sen= ds TOO_BUSY due due to a host OLR received from the an upstream server, the= client might (actually SHOULD) try to reach that same server via an altern= ate agent. Is that okay? I would say this could be a desired behaviour but I am not sure whether it is okay. DIAMETER_TOO_BUSY is a protocol error, which means an error-answer, which again probably is completely different what the server sent (in the above example). Although this is allowed (see the usage of Error-Reporting-Host AVP) but then RFC 6733 Section 6.2.2. MUST on sending STR to the server does not really fit our use case. A client knows from the Origin-Host & Error-Reporting-Host whether the error came from the final destination or from an intermediate. It can reason based that whether it needs to find a new server or just an alternate path. > I'm not sure I understand the original intent of the MUST only sentence. = But the only way I know of to request a specific server is to use D-H. So w= ould we allow the sending of a TOO_BUSY in response to a realm-routed reque= st? I would think twice updates to RFC6733. But if seen necessary, I would do that in a separate I-D. - Jouni >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Mar 3 01:13:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FFA31A064A for ; Mon, 3 Mar 2014 01:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06kdXPZb7d1Z for ; Mon, 3 Mar 2014 01:13:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE071A0349 for ; Mon, 3 Mar 2014 01:13:45 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s239DeW0011331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Mar 2014 10:13:40 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s239DdgQ010052 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 10:13:39 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 10:13:39 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen , Steve Donovan Thread-Topic: [Dime] Issue#32 status Thread-Index: Ac8tiAGtvQe9mwQAS968RUS8ackr7wEDzhQAAAUk0YAAIZgPgAAD5hfwAJwK344AgyfZQA== Date: Mon, 3 Mar 2014 09:13:38 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B5057@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3D63@DEMUMBX014.nsn-intra.net> <530BAC7C.7080106@usdonovans.com> <530CB073.7000802@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B47C2@DEMUMBX014.nsn-intra.net> <530CC6A2.5010702@usdonovans.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3217 X-purgate-ID: 151667::1393838020-00003660-F2C94692/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7ovQ0WdrDruoSCwv8CLYZrxK2qA Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#32 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:13:50 -0000 Hi Jouni, if d is the maximum validity duration a reporting node ever sent, then d is= sufficiently long. (there may be better i.e. shorter estimations but those would be subject to= more complex conditions) =20 Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 28, 2014 7:22 PM To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich) Cc: Ben Campbell; dime@ietf.org list Subject: Re: [Dime] Issue#32 status A question.. how much is "a sufficiently long period of no overload"? I'd like to see some guidance or minimum values documented. - Jouni On Feb 25, 2014, at 6:36 PM, Steve Donovan wrote= : > Ulrich, >=20 > Yes, with that period being long enough for the reporting node to be conf= ident that all previously sent overload reports have expired. >=20 > Steve >=20 > On 2/25/14 10:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, Ben, >>=20 >> for my clarification, your proposal is to say >>=20 >> *** >> Sequence number is of type Unsigned64. >>=20 >> When generated, a new sequence number must be greater than the sequence = number contained in the active overload report to which it applies (includi= ng over reboot of that node). Note: this allows sequence numbers to start = at 1 for the initial occurrence of an overload condition at a reporting nod= e. >> *** >>=20 >> If so, what is meant by "initial occurrence of an overload condition"? >>=20 >> I guess it means something like moving from no overload to overload afte= r a sufficiently long periode of no overload >>=20 >> Please clarify >>=20 >> Ulrich >>=20 >>=20 >> From: DiME [ >> mailto:dime-bounces@ietf.org >> ] On Behalf Of ext Steve Donovan >> Sent: Tuesday, February 25, 2014 4:02 PM >> To: Ben Campbell >> Cc:=20 >> dime@ietf.org >> list >> Subject: Re: [Dime] Issue#32 status >>=20 >> I agree with the suggested change. >>=20 >> Steve >> On 2/24/14 5:00 PM, Ben Campbell wrote: >> + 1, except as noted: >>=20 >> On Feb 24, 2014, at 2:33 PM, Steve Donovan=20 >> >> wrote: >>=20 >> Ulrich, >>=20 >> Would you agree to the following to replace the first two statements: >>=20 >> Sequence number is of type Unsigned64. >>=20 >> When generated, a new sequence number must be greater than the sequence = number contained in the active overload report to which it applies (includi= ng over reboot of that node). Note: this allows sequence numbers to start = at 1 for any occurrence of overload at a reporting node. This, I think, al= lows us to ignore wraparound issues as wraparound will never happen. Unles= s we are worried about a server staying in overload for billions of years (= assuming reports with a ten minute validity period refreshed every five min= utes). >>=20 >> s/ any occurrence of overload / the initial occurrence of an overload co= ndition >>=20 >>=20 >> The other two statements are good. >>=20 >> Steve >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Mar 3 01:14:02 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70721A09AE for ; Mon, 3 Mar 2014 01:13:59 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRNjsOwJSmnF for ; Mon, 3 Mar 2014 01:13:56 -0800 (PST) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B48091A0957 for ; Mon, 3 Mar 2014 01:13:55 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id t61so340543wes.2 for ; Mon, 03 Mar 2014 01:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1XGYQ0r6jNrrf5YrWiGaE6MtD3YqLLkA6C1oOu/oiUU=; b=T5008Q4eWJZVXMEwArGKb5/Cz/lEloRruoRGzBwsssWVr+LDnGtuPnuEKpUt3IaE7V gIBn7eVk/nuzgGDehxcTRAfz763o97vVkJrSO3/iQTUc+Jp2c1HxGjg5si6Lj3/RWZ36 IdAUUrEmcVyrvThrrVo/PnwHr3FjKutLeDAE2oHZYtNds6VGdHeuQRuIw26rSyTl5aI4 kAhYlHw5O9QpK1S4o0+Lg/gUNDFqnDc1QiWaPEHZSAGMqIy7SEwQOyzb5RanWSC4qf9y 6PVVtxw29UBp7vDZ4Qoo6uiDkpkM2hn1/MSWLIQ4cut0u2M/05qB3m4OCekXZjMiwVd2 er9Q== X-Received: by 10.194.94.162 with SMTP id dd2mr4207182wjb.66.1393838021189; Mon, 03 Mar 2014 01:13:41 -0800 (PST) Received: from dhcp-b491.meeting.ietf.org (dhcp-b491.meeting.ietf.org. [31.133.180.145]) by mx.google.com with ESMTPSA id t5sm32051557wjw.15.2014.03.03.01.13.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 01:13:38 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <28213_1393835105_53143C61_28213_3217_1_6B7134B31289DC4FAF731D844122B36E4D926D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Mon, 3 Mar 2014 09:13:38 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <683CF75B-A6BC-4D6D-B62E-E823600796A8@gmail.com> References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com> <28213_1393835105_53143C61_28213_3217_1_6B7134B31289DC4FAF731D844122B36E4D926D@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: lionel.morand@orange.com X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8lC1BF8W0f6dRVYVsAKsXP8PZfI Cc: Ben Campbell , "dime@ietf.org" Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:14:00 -0000 On Mar 3, 2014, at 8:25 AM, lionel.morand@orange.com wrote: > Hi Jouni, >=20 > Doing a separate I-D updating the RFC6733 to provide guidelines and = recommendations on the use of TOO_BUSY and non-answer cases was already = proposed in Porto. This is needed independently of the DOIC mechanism. Sure. I just wanted to re-emphasize that. - Jouni >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen > Envoy=E9 : vendredi 28 f=E9vrier 2014 18:46 > =C0 : Ben Campbell > Cc : dime@ietf.org > Objet : Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of = Client that does not support DOIC >=20 > Ben, >=20 > On Feb 25, 2014, at 1:11 AM, Ben Campbell wrote: >=20 >>=20 >> On Feb 24, 2014, at 12:40 PM, Steve Donovan = wrote: >>=20 >>> There has been no discussion of ticket #27. I can't even find it on = the DIME list, so I'm copying it here to initiate discussion. >>>=20 >>> The proposal is for an agent to send a TOO-BUSY response when it = throttles a request from a non supporting client. The behavior of the = agent in this case would be in the new section to be added to capture = agent behavior as proposed in issue #24 (and various other places). >>>=20 >>=20 >> RFC6733 has the following to say about TOO_BUSY >>=20 >> "When returned, a Diameter node SHOULD attempt to send the message to = an alternate peer. This error MUST only be used when a specific server = is requested, and it cannot provide the requested saervice." >=20 > "when a specific server is requested" means the use of = Destination-Host to me. >=20 >> Do those semantics and limitations apply to this usage? Is there a = chance if incorrect behavior from a client that doesn't support DOIC, = and therefore is not aware of this new usage of TOO_BUSY? For example, = if an agent sends TOO_BUSY due due to a host OLR received from the an = upstream server, the client might (actually SHOULD) try to reach that = same server via an alternate agent. Is that okay? >=20 > I would say this could be a desired behaviour but I am not sure > whether it is okay. DIAMETER_TOO_BUSY is a protocol error, which > means an error-answer, which again probably is completely different > what the server sent (in the above example). Although this is allowed > (see the usage of Error-Reporting-Host AVP) but then RFC 6733 Section > 6.2.2. MUST on sending STR to the server does not really fit our use > case. >=20 > A client knows from the Origin-Host & Error-Reporting-Host whether the > error came from the final destination or from an intermediate. It can > reason based that whether it needs to find a new server or just an > alternate path. >=20 >> I'm not sure I understand the original intent of the MUST only = sentence. But the only way I know of to request a specific server is to = use D-H. So would we allow the sending of a TOO_BUSY in response to a = realm-routed request? >=20 > I would think twice updates to RFC6733. But if seen necessary, > I would do that in a separate I-D. >=20 > - Jouni >=20 >=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Mon Mar 3 01:23:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDE11A0C81 for ; Mon, 3 Mar 2014 01:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mV2pOkP4ii0C for ; Mon, 3 Mar 2014 01:23:42 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1D61A0BFF for ; Mon, 3 Mar 2014 01:23:42 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s239NHMN050618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Mar 2014 03:23:30 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <683CF75B-A6BC-4D6D-B62E-E823600796A8@gmail.com> Date: Mon, 3 Mar 2014 09:23:17 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1D6D6EED-A2B3-4A3B-B0DD-A0AF9B691EE7@nostrum.com> References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com> <28213_1393835105_53143C61_28213_3217_1_6B7134B31289DC4FAF731D844122B36E4D926D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <683CF75B-A6BC-4D6D-B62E-E823600796A8@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/G4_lMzBoshVbCFnrIxOQI3OSA34 Cc: "dime@ietf.org" Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 09:23:43 -0000 On Mar 3, 2014, at 9:13 AM, Jouni Korhonen = wrote: >=20 > On Mar 3, 2014, at 8:25 AM, lionel.morand@orange.com wrote: >=20 >> Hi Jouni, >>=20 >> Doing a separate I-D updating the RFC6733 to provide guidelines and = recommendations on the use of TOO_BUSY and non-answer cases was already = proposed in Porto. This is needed independently of the DOIC mechanism. >=20 > Sure. I just wanted to re-emphasize that. >=20 Do we expect DOIC to normatively reference that draft? I think that if = DOIC depends on TOO_BUSY to be used in a way that is not supported by = 6733, we would have to do so. If so, we would need that draft to exist and progress ahead of or in = tandem with DOIC. From nobody Mon Mar 3 02:37:01 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707EE1A0DEE for ; Mon, 3 Mar 2014 02:36:57 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjXBL2bYYV4J for ; Mon, 3 Mar 2014 02:36:51 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 15AC61A0E91 for ; Mon, 3 Mar 2014 02:36:50 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id w61so2908681wes.4 for ; Mon, 03 Mar 2014 02:36:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/3G/UXY8bqgrjiMNX+6em+YI1CNBwHl587NT2zXbaUk=; b=gleXxjgyc1bJotbnFwU42f3sU8Akc7RBrbIWlmp/OAzsbM8Xd7YkzcpbSeNWgxGtQA QaYswyb0i8K2Wnr37gTRNtewLT5U2u7Kaqq8g6Ure5cM/rR3QEiSoBsuS6oUNRkE/Kgu HBW4ep+NEiZwHKCTYbiwhzk5MAsrgPiMOC9/5a8zsbDTqPkMeAG0BxkvlxwhwkmOMqtV YmL5Bt6lBB9quLhSHalQOjBykoRpmRuD1J6wcKSEWl0SfDxK4U51Sza5+UUe8SCQDUnn mSv0O8qZbk76rfb05EmQy6RdPyYVWP+BEsHZGT6/Fb7gN82XdO5extmmbsjPWw1cgOpN y01Q== X-Received: by 10.195.12.102 with SMTP id ep6mr4486441wjd.76.1393843007729; Mon, 03 Mar 2014 02:36:47 -0800 (PST) Received: from dhcp-b491.meeting.ietf.org (dhcp-b491.meeting.ietf.org. [31.133.180.145]) by mx.google.com with ESMTPSA id br10sm33088897wjb.3.2014.03.03.02.36.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 02:36:47 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <1D6D6EED-A2B3-4A3B-B0DD-A0AF9B691EE7@nostrum.com> Date: Mon, 3 Mar 2014 10:36:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com> <28213_1393835105_53143C61_28213_3217_1_6B7134B31289DC4FAF731D844122B36E4D926D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <683CF75B-A6BC-4D6D-B62E-E823600796A8@gmail.com> <1D6D6EED-A2B3-4A3B-B0DD-A0AF9B691EE7@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iKVJW9DiATmdEEcx7Lntr2-jr8w Cc: "dime@ietf.org" Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:36:57 -0000 On Mar 3, 2014, at 9:23 AM, Ben Campbell wrote: > On Mar 3, 2014, at 9:13 AM, Jouni Korhonen = wrote: >=20 >>=20 >> On Mar 3, 2014, at 8:25 AM, lionel.morand@orange.com wrote: >>=20 >>> Hi Jouni, >>>=20 >>> Doing a separate I-D updating the RFC6733 to provide guidelines and = recommendations on the use of TOO_BUSY and non-answer cases was already = proposed in Porto. This is needed independently of the DOIC mechanism. >>=20 >> Sure. I just wanted to re-emphasize that. >>=20 >=20 > Do we expect DOIC to normatively reference that draft? I think that if = DOIC depends on TOO_BUSY to be used in a way that is not supported by = 6733, we would have to do so. I do not understand the reason why would we want to deliberately build that kind of dependency into DOIC I-D. To me it would be the other way around, since it is a specific deployment case independent of the DOIC base solution. >=20 > If so, we would need that draft to exist and progress ahead of or in = tandem with DOIC. Just thinking out loud.. the DOIC I-D could e.g. just state this use case is up to separate document and not even referencing which one. We really do not need to name the document in the DOIC base IMHO. This is of course only my personal view.. - Jouni From nobody Mon Mar 3 02:43:06 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76651A0DBB for ; Mon, 3 Mar 2014 02:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apALXh87FUNq for ; Mon, 3 Mar 2014 02:43:02 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BF71A0DF0 for ; Mon, 3 Mar 2014 02:43:02 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s23AgpjE061371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Mar 2014 04:42:53 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: Date: Mon, 3 Mar 2014 10:42:50 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <81D5DC86-A9A8-472F-834C-9A709DCAE7E1@nostrum.com> References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com> <28213_1393835105_53143C61_28213_3217_1_6B7134B31289DC4FAF731D844122B36E4D926D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <683CF75B-A6BC-4D6D-B62E-E823600796A8@gmail.com> <1D6D6EED-A2B3-4A3B-B0DD-A0AF9B691EE7@nostrum.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SS49lHdaQz3PhN4eDnK7j0ZfRF8 Cc: "dime@ietf.org" Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:43:03 -0000 On Mar 3, 2014, at 10:36 AM, Jouni Korhonen = wrote: >>=20 >> Do we expect DOIC to normatively reference that draft? I think that = if DOIC depends on TOO_BUSY to be used in a way that is not supported by = 6733, we would have to do so. >=20 > I do not understand the reason why would we want to deliberately build > that kind of dependency into DOIC I-D. To me it would be the other way > around, since it is a specific deployment case independent of the DOIC > base solution. >=20 >>=20 >> If so, we would need that draft to exist and progress ahead of or in = tandem with DOIC. >=20 > Just thinking out loud.. the DOIC I-D could e.g. just state this use > case is up to separate document and not even referencing which one. > We really do not need to name the document in the DOIC base IMHO. >=20 > This is of course only my personal view.. Maybe I misunderstood, but I gathered we were talking about a proposal = to have DOIC specify sending TOO_BUSY to realm-routed requests. I = interpret the 6733 language to forbid that. So I don't think we can = propose doing that in DOIC, but leave the details to another draft = without a normative reference.=20 OTOH, if the idea is to not mention the which responses to send to a = non-DOIC client when a request is throttled and leave the whole thing to = another draft, then we would not have a dependency. (But we might have = an interop problem due to underspecification.) >=20 > - Jouni From nobody Mon Mar 3 02:50:53 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900061A0DB8 for ; Mon, 3 Mar 2014 02:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dp7IE_1y3bGz for ; Mon, 3 Mar 2014 02:50:47 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 63C501A0CEC for ; Mon, 3 Mar 2014 02:50:47 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s23AoZKW002122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Mar 2014 11:50:35 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s23AoZbV023044 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 11:50:35 +0100 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 3 Mar 2014 11:50:34 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 11:50:34 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioA== Date: Mon, 3 Mar 2014 10:50:34 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 4263 X-purgate-ID: 151667::1393843836-00005322-B1D36EEF/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/U_hONeXntkDEqGXBb8w34YkZH7o Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:50:50 -0000 Jouni, Is this your proposal or your decision? Anyway, what is the expected behaviour of the reacting node (that supports = only OLR_DEFAULT_ALGO) when receiving an answer that contains a) OLR but no Supported-Features b) Supported Features but no OLR c) OLR and Supported Features Is the information received in Supported-Features in the answer something t= hat needs to be taken into account when sending subsequent requests (i.e. d= o less proactive throttling), or something that needs to be taken into acco= unt when interpreting the OLR received in the same answer?=20 What if the received Supported-Features in the answer does not indicate OL= R_DEFAULT_ALGO? What if the received Supported-Features in the answer indicates support of = something different than OLR_DEFAULT_ALGO? What if the received Supported Features in the answer indicates support of = OLR_DEFAULT_ALGO and support of something else? Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Friday, February 28, 2014 2:49 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list Subject: Re: [Dime] Issue#30 status Right. We are going back and forth and continue to do that as long as none of these moving parts can be nailed down. My proposal here is that we simply agree now that OC-Supported-Features is in every answer message. Period. Get one corner nailed down. The rest of the fixing inconsistencies and missing/excess parts listed below then need to be done according to the above decision. - JOuni On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Anders, >=20 > Yes, if we conclude that there is a requirement for OC-Supported-Features= to be sent in answers, then it should be included in every answer. However= , I still don't see that requirement. In addition we would need some text s= pecifying the expected behaviour of the reacting node when receiving OC-Sup= ported-Features in an answer, keeping in mind that the reacting node cannot= know whether it was the server or an agent that inserted the OC-Supported-= Feature, and whether or not a subsequent request will be routed via that no= de. >=20 > Ulrich >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Ander= s > Sent: Thursday, February 27, 2014 6:14 PM > To: Ben Campbell; Steve Donovan > Cc: dime@ietf.org list > Subject: Re: [Dime] Issue#30 status >=20 > I also agree that including OC-Supported-Features in every answer is pref= erable. In addition to mirroring Requests, it is in-line with how Supported= -Features are managed in at least some 3GPP interfaces as well. >=20 > /Anders >=20 > -----Original Message----- > From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell > Sent: Wednesday, February 26, 2014 9:19 AM > To: Steve Donovan > Cc: dime@ietf.org list > Subject: Re: [Dime] Issue#30 status >=20 >=20 > On Feb 26, 2014, at 9:14 AM, Steve Donovan wro= te: >=20 >> SRD> We don't have consensus yet, but if we agree on the need for reacti= ng nodes to know whether there is support for DOIC in the Diameter network = then I think the requirement would be similar to how we are handling overlo= ad reports. The reporting node MUST ensure that all reacting nodes receive= the OC-Supported-Features AVP. This can be done by including the AVP in a= ll answer messages or it can be done by remembering to whom the AVP has bee= n sent. >=20 > Given the trivial nature of sending and reading OC-Supported-Features, I = think we should put it in every answer. This mirrors the way we handle it i= n requests. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Mar 3 03:15:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515421A0EEF for ; Mon, 3 Mar 2014 03:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alBsJQho_CBs for ; Mon, 3 Mar 2014 03:15:01 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id D6E031A0CB7 for ; Mon, 3 Mar 2014 03:15:01 -0800 (PST) Received: from dhcp-a76f.meeting.ietf.org ([31.133.167.111]:51147) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKQpm-0000XR-6A for dime@ietf.org; Mon, 03 Mar 2014 03:14:59 -0800 Message-ID: <53146430.7070804@usdonovans.com> Date: Mon, 03 Mar 2014 11:14:56 +0000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dime@ietf.org References: <530B9202.8040100@usdonovans.com> <54DD35E0-52B1-4FB6-B9AB-2527922C86A5@nostrum.com> <28213_1393835105_53143C61_28213_3217_1_6B7134B31289DC4FAF731D844122B36E4D926D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <683CF75B-A6BC-4D6D-B62E-E823600796A8@gmail.com> <1D6D6EED-A2B3-4A3B-B0DD-A0AF9B691EE7@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/P9BU3stXSf1pVgrM8_YmCPGz0t0 Subject: Re: [Dime] Ticket #27 - Behavior of agent acting on behalf of Client that does not support DOIC X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:15:03 -0000 It seems that we need two things. First, we need to specify the response(s) sent by an agent for throttled requests received from a 6733 node. Second, we need to define the 6733+ node that supports the yet to be defined enhanced Too-Busy logic. If we include the second in the initial version of the DOIC document then there is a dependency on the enhanced Too-Busy document. I propose that we focus on the first case and decide if we update DOIC if and when the definition of enhanced Too-Busy logic exists. Steve On 3/3/14, 10:36 AM, Jouni Korhonen wrote: > On Mar 3, 2014, at 9:23 AM, Ben Campbell wrote: > >> On Mar 3, 2014, at 9:13 AM, Jouni Korhonen wrote: >> >>> On Mar 3, 2014, at 8:25 AM, lionel.morand@orange.com wrote: >>> >>>> Hi Jouni, >>>> >>>> Doing a separate I-D updating the RFC6733 to provide guidelines and recommendations on the use of TOO_BUSY and non-answer cases was already proposed in Porto. This is needed independently of the DOIC mechanism. >>> Sure. I just wanted to re-emphasize that. >>> >> Do we expect DOIC to normatively reference that draft? I think that if DOIC depends on TOO_BUSY to be used in a way that is not supported by 6733, we would have to do so. > I do not understand the reason why would we want to deliberately build > that kind of dependency into DOIC I-D. To me it would be the other way > around, since it is a specific deployment case independent of the DOIC > base solution. > >> If so, we would need that draft to exist and progress ahead of or in tandem with DOIC. > Just thinking out loud.. the DOIC I-D could e.g. just state this use > case is up to separate document and not even referencing which one. > We really do not need to name the document in the DOIC base IMHO. > > This is of course only my personal view.. > > - Jouni > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Mar 3 03:21:25 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683061A0F42 for ; Mon, 3 Mar 2014 03:21:24 -0800 (PST) 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=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3TluxQ0W6SI for ; Mon, 3 Mar 2014 03:21:21 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id D07541A0F44 for ; Mon, 3 Mar 2014 03:21:20 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id k14so1196731wgh.23 for ; Mon, 03 Mar 2014 03:21:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nd7f1Tjd2D7ZVdUmZv+DlprUgmGyD9/Ezx0GAoYhQMI=; b=obvQpPjuEgxxvZcG5qi2/4BeMlqoDSzwXFudcFuFDtCD+IOk+j+Lj4+zwVMymjlrwC 5HyRy4Kdk1BC+Z8C5zf+8oEsbNIf9bsYUI5tklaPVNURceq9YS2tuF3fDwf4+v1n8c2y 6tVrViLjfZ/Y7smInRTobMcSZQ6UqS44bGFbiSEgn7FntWr+Uv70FR5X6uZSYg4OaJ8l tOC2e7pFQ7l2cDziarrwCna9R1P6TL3xDdif4jADHnnB4cXOzPpl9wdAuN4192dwuxj/ WZqepE16qPJ0Xya5wTJ68Ki41BYLPlraR33jISFXmXnijX5umKR7caz2r11fSSy+ntaq xGIg== X-Received: by 10.194.22.129 with SMTP id d1mr16983640wjf.22.1393845677505; Mon, 03 Mar 2014 03:21:17 -0800 (PST) Received: from dhcp-b491.meeting.ietf.org (dhcp-b491.meeting.ietf.org. [31.133.180.145]) by mx.google.com with ESMTPSA id t5sm33697925wjw.15.2014.03.03.03.21.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 03:21:17 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> Date: Mon, 3 Mar 2014 11:21:15 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_eRk1foYvJIRmeLTUEErd6MXLFg Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 11:21:24 -0000 On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Jouni, >=20 > Is this your proposal or your decision? > as none of these moving parts can be nailed down. My proposal here ^^^^^^^^^^^^ > Anyway, what is the expected behaviour of the reacting node (that = supports only OLR_DEFAULT_ALGO) when receiving an answer that contains > a) OLR but no Supported-Features Ehh.. if we agree that OC-Suppoted-Feature is in every answer message this would be an error case (misbehaving reporting node). My proposal would be reporting node to discard the OC-OLR. > b) Supported Features but no OLR Reporting node has nothing to report except that it states it supports DOIC. No chance in the current state, if there is one. > c) OLR and Supported Features >=20 > Is the information received in Supported-Features in the answer = something that needs to be taken into account when sending subsequent = requests (i.e. do less proactive throttling), or something that needs to = be taken into account when interpreting the OLR received in the same = answer?=20 Depends on the abatement algorithm or other future features. In the context of this I-D there is no such dependency since we got only one algorithm which is simple request-reply nature. >=20 > What if the received Supported-Features in the answer does not = indicate OLR_DEFAULT_ALGO? Then the OC-OLR must include abatement information that matches with the=20= algorithm/feature indicated in the OC-Supported-Features. Sending an = empty OC-Supported-Features in not allowed. > What if the received Supported-Features in the answer indicates = support of something different than OLR_DEFAULT_ALGO? Same as above. It is a valid use case (for future deployments) that a network absolutely wants to use some other algorithm than the default. Then announcing the default is no use. Our protocol needs to be flexible enough to allow such policy decision. > What if the received Supported Features in the answer indicates = support of OLR_DEFAULT_ALGO and support of something else? This is something that is open but as I tried to drive at the beginning the OC-Supported-Features in an answer names a single selected abatement algorithm.=20 - Jouni > Ulrich >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, February 28, 2014 2:49 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org = list > Subject: Re: [Dime] Issue#30 status >=20 >=20 > >=20 > Right. We are going back and forth and continue to do that as long > as none of these moving parts can be nailed down. My proposal here > is that we simply agree now that OC-Supported-Features is in every > answer message. Period. Get one corner nailed down. >=20 > The rest of the fixing inconsistencies and missing/excess parts > listed below then need to be done according to the above decision. >=20 > - JOuni >=20 >=20 > On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >=20 >> Anders, >>=20 >> Yes, if we conclude that there is a requirement for = OC-Supported-Features to be sent in answers, then it should be included = in every answer. However, I still don't see that requirement. In = addition we would need some text specifying the expected behaviour of = the reacting node when receiving OC-Supported-Features in an answer, = keeping in mind that the reacting node cannot know whether it was the = server or an agent that inserted the OC-Supported-Feature, and whether = or not a subsequent request will be routed via that node. >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, = Anders >> Sent: Thursday, February 27, 2014 6:14 PM >> To: Ben Campbell; Steve Donovan >> Cc: dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >>=20 >> I also agree that including OC-Supported-Features in every answer is = preferable. In addition to mirroring Requests, it is in-line with how = Supported-Features are managed in at least some 3GPP interfaces as well. >>=20 >> /Anders >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Wednesday, February 26, 2014 9:19 AM >> To: Steve Donovan >> Cc: dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >>=20 >>=20 >> On Feb 26, 2014, at 9:14 AM, Steve Donovan = wrote: >>=20 >>> SRD> We don't have consensus yet, but if we agree on the need for = reacting nodes to know whether there is support for DOIC in the Diameter = network then I think the requirement would be similar to how we are = handling overload reports. The reporting node MUST ensure that all = reacting nodes receive the OC-Supported-Features AVP. This can be done = by including the AVP in all answer messages or it can be done by = remembering to whom the AVP has been sent. >>=20 >> Given the trivial nature of sending and reading = OC-Supported-Features, I think we should put it in every answer. This = mirrors the way we handle it in requests. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From nobody Mon Mar 3 04:52:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 747051A00B8 for ; Mon, 3 Mar 2014 04:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc5jECFXx23m for ; Mon, 3 Mar 2014 04:52:03 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 60AF81A008B for ; Mon, 3 Mar 2014 04:52:03 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s23Cpu1H026250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Mar 2014 13:51:56 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s23Cptkb018556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 13:51:56 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 3 Mar 2014 13:51:55 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 13:51:55 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Jouni Korhonen Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8A= Date: Mon, 3 Mar 2014 12:51:55 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 7454 X-purgate-ID: 151667::1393851116-00005322-95C79CB3/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cH5rSxcgSzw83aWd-owUxiFgWZg Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 12:52:06 -0000 Thank you for the clarification. It seems the proposed principles are: 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an a= nswer message that corresponds to a request which contained an OC-Supported= -Features AVP. 2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message w= hen 2a) There was no OC-Supported-Features AVP in the answer 2b) The OC-Supported-Features AVP in the answer indicated support of more = than one supported feature 2c) The OC-Supported-Features AVP in the answer indicated support of less = than one supported feature 2d) The OC-Supported-Features AVP in the answer indicated support of exact= ly one feature, but that one is not supported by the reacting node. 3. Reacting nodes MUST interpret a received OC-OLR in the context of the se= lected feature as received within the OC-Supported-Features AVP.=20 4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in ans= wers (from a destination) may or may not do proactive throttling towards th= at destination.=20 5. When receiving an answer that does not contain an OC-OLR, the reacting n= ode can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR w= hich needs to be interpreted/ignored based on information received in OC-Su= pported-Features). Is this agreeable? Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, March 03, 2014 12:21 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list Subject: Re: [Dime] Issue#30 status On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Jouni, >=20 > Is this your proposal or your decision? > as none of these moving parts can be nailed down. My proposal here ^^^^^^^^^^^^ > Anyway, what is the expected behaviour of the reacting node (that support= s only OLR_DEFAULT_ALGO) when receiving an answer that contains > a) OLR but no Supported-Features Ehh.. if we agree that OC-Suppoted-Feature is in every answer message this would be an error case (misbehaving reporting node). My proposal would be reporting node to discard the OC-OLR. > b) Supported Features but no OLR Reporting node has nothing to report except that it states it supports DOIC. No chance in the current state, if there is one. > c) OLR and Supported Features >=20 > Is the information received in Supported-Features in the answer something= that needs to be taken into account when sending subsequent requests (i.e.= do less proactive throttling), or something that needs to be taken into ac= count when interpreting the OLR received in the same answer?=20 Depends on the abatement algorithm or other future features. In the context of this I-D there is no such dependency since we got only one algorithm which is simple request-reply nature. >=20 > What if the received Supported-Features in the answer does not indicate = OLR_DEFAULT_ALGO? Then the OC-OLR must include abatement information that matches with the=20 algorithm/feature indicated in the OC-Supported-Features. Sending an empty OC-Supported-Features in not allowed. > What if the received Supported-Features in the answer indicates support o= f something different than OLR_DEFAULT_ALGO? Same as above. It is a valid use case (for future deployments) that a network absolutely wants to use some other algorithm than the default. Then announcing the default is no use. Our protocol needs to be flexible enough to allow such policy decision. > What if the received Supported Features in the answer indicates support o= f OLR_DEFAULT_ALGO and support of something else? This is something that is open but as I tried to drive at the beginning the OC-Supported-Features in an answer names a single selected abatement algorithm.=20 - Jouni > Ulrich >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, February 28, 2014 2:49 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list > Subject: Re: [Dime] Issue#30 status >=20 >=20 > >=20 > Right. We are going back and forth and continue to do that as long > as none of these moving parts can be nailed down. My proposal here > is that we simply agree now that OC-Supported-Features is in every > answer message. Period. Get one corner nailed down. >=20 > The rest of the fixing inconsistencies and missing/excess parts > listed below then need to be done according to the above decision. >=20 > - JOuni >=20 >=20 > On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> Anders, >>=20 >> Yes, if we conclude that there is a requirement for OC-Supported-Feature= s to be sent in answers, then it should be included in every answer. Howeve= r, I still don't see that requirement. In addition we would need some text = specifying the expected behaviour of the reacting node when receiving OC-Su= pported-Features in an answer, keeping in mind that the reacting node canno= t know whether it was the server or an agent that inserted the OC-Supported= -Feature, and whether or not a subsequent request will be routed via that n= ode. >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Ande= rs >> Sent: Thursday, February 27, 2014 6:14 PM >> To: Ben Campbell; Steve Donovan >> Cc: dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >>=20 >> I also agree that including OC-Supported-Features in every answer is pre= ferable. In addition to mirroring Requests, it is in-line with how Supporte= d-Features are managed in at least some 3GPP interfaces as well. >>=20 >> /Anders >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Wednesday, February 26, 2014 9:19 AM >> To: Steve Donovan >> Cc: dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >>=20 >>=20 >> On Feb 26, 2014, at 9:14 AM, Steve Donovan wr= ote: >>=20 >>> SRD> We don't have consensus yet, but if we agree on the need for react= ing nodes to know whether there is support for DOIC in the Diameter network= then I think the requirement would be similar to how we are handling overl= oad reports. The reporting node MUST ensure that all reacting nodes receiv= e the OC-Supported-Features AVP. This can be done by including the AVP in = all answer messages or it can be done by remembering to whom the AVP has be= en sent. >>=20 >> Given the trivial nature of sending and reading OC-Supported-Features, I= think we should put it in every answer. This mirrors the way we handle it = in requests. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 From nobody Mon Mar 3 05:26:12 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B34A1A0112 for ; Mon, 3 Mar 2014 05:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtR4C3YCli_n for ; Mon, 3 Mar 2014 05:25:59 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 02B9D1A00FB for ; Mon, 3 Mar 2014 05:25:59 -0800 (PST) Received: from dhcp-a76f.meeting.ietf.org ([31.133.167.111]:51753) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKSsO-00083z-DD; Mon, 03 Mar 2014 05:25:55 -0800 Message-ID: <531482DB.4030609@usdonovans.com> Date: Mon, 03 Mar 2014 13:25:47 +0000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Jouni Korhonen References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cu0PGv7Zprr5JXYT10Q5P8rik1I Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:26:01 -0000 Ulrich, I think you mean "abatement algorithm" below when you say feature. There will be cases when it is valid to indicate support multiple features. Support for the loss algorithm and agent overload is an example. It is not valid for the reporting node to indicate support for two abatement algorithms. See more below. Steve On 3/3/14, 12:51 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Thank you for the clarification. > It seems the proposed principles are: > > 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an answer message that corresponds to a request which contained an OC-Supported-Features AVP. > > 2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message when > 2a) There was no OC-Supported-Features AVP in the answer > 2b) The OC-Supported-Features AVP in the answer indicated support of more than one supported feature > 2c) The OC-Supported-Features AVP in the answer indicated support of less than one supported feature > 2d) The OC-Supported-Features AVP in the answer indicated support of exactly one feature, but that one is not supported by the reacting node. SRD> The above three should say abatement algorithm instead of feature. > > 3. Reacting nodes MUST interpret a received OC-OLR in the context of the selected feature as received within the OC-Supported-Features AVP. > > 4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in answers (from a destination) may or may not do proactive throttling towards that destination. > > 5. When receiving an answer that does not contain an OC-OLR, the reacting node can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on information received in OC-Supported-Features). SRD> This should be modified with a note saying that this can and likely will change when the protocol is extended. Maybe this would be in an extensibility section. > > Is this agreeable? > > Ulrich > > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Monday, March 03, 2014 12:21 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list > Subject: Re: [Dime] Issue#30 status > > > On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> Jouni, >> >> Is this your proposal or your decision? >> as none of these moving parts can be nailed down. My proposal here > ^^^^^^^^^^^^ >> Anyway, what is the expected behaviour of the reacting node (that supports only OLR_DEFAULT_ALGO) when receiving an answer that contains >> a) OLR but no Supported-Features > Ehh.. if we agree that OC-Suppoted-Feature is in every answer message > this would be an error case (misbehaving reporting node). My proposal > would be reporting node to discard the OC-OLR. > >> b) Supported Features but no OLR > Reporting node has nothing to report except that it states it supports > DOIC. No chance in the current state, if there is one. > >> c) OLR and Supported Features >> >> Is the information received in Supported-Features in the answer something that needs to be taken into account when sending subsequent requests (i.e. do less proactive throttling), or something that needs to be taken into account when interpreting the OLR received in the same answer? > Depends on the abatement algorithm or other future features. In the > context of this I-D there is no such dependency since we got only > one algorithm which is simple request-reply nature. > >> What if the received Supported-Features in the answer does not indicate OLR_DEFAULT_ALGO? > Then the OC-OLR must include abatement information that matches with the > algorithm/feature indicated in the OC-Supported-Features. Sending an empty > OC-Supported-Features in not allowed. > >> What if the received Supported-Features in the answer indicates support of something different than OLR_DEFAULT_ALGO? > Same as above. It is a valid use case (for future deployments) that a > network absolutely wants to use some other algorithm than the default. > Then announcing the default is no use. Our protocol needs to be flexible > enough to allow such policy decision. > >> What if the received Supported Features in the answer indicates support of OLR_DEFAULT_ALGO and support of something else? > This is something that is open but as I tried to drive at the beginning > the OC-Supported-Features in an answer names a single selected abatement > algorithm. > > - Jouni > > > >> Ulrich >> >> >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Friday, February 28, 2014 2:49 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >> >> >> >> >> Right. We are going back and forth and continue to do that as long >> as none of these moving parts can be nailed down. My proposal here >> is that we simply agree now that OC-Supported-Features is in every >> answer message. Period. Get one corner nailed down. >> >> The rest of the fixing inconsistencies and missing/excess parts >> listed below then need to be done according to the above decision. >> >> - JOuni >> >> >> On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> >>> Anders, >>> >>> Yes, if we conclude that there is a requirement for OC-Supported-Features to be sent in answers, then it should be included in every answer. However, I still don't see that requirement. In addition we would need some text specifying the expected behaviour of the reacting node when receiving OC-Supported-Features in an answer, keeping in mind that the reacting node cannot know whether it was the server or an agent that inserted the OC-Supported-Feature, and whether or not a subsequent request will be routed via that node. >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Anders >>> Sent: Thursday, February 27, 2014 6:14 PM >>> To: Ben Campbell; Steve Donovan >>> Cc: dime@ietf.org list >>> Subject: Re: [Dime] Issue#30 status >>> >>> I also agree that including OC-Supported-Features in every answer is preferable. In addition to mirroring Requests, it is in-line with how Supported-Features are managed in at least some 3GPP interfaces as well. >>> >>> /Anders >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >>> Sent: Wednesday, February 26, 2014 9:19 AM >>> To: Steve Donovan >>> Cc: dime@ietf.org list >>> Subject: Re: [Dime] Issue#30 status >>> >>> >>> On Feb 26, 2014, at 9:14 AM, Steve Donovan wrote: >>> >>>> SRD> We don't have consensus yet, but if we agree on the need for reacting nodes to know whether there is support for DOIC in the Diameter network then I think the requirement would be similar to how we are handling overload reports. The reporting node MUST ensure that all reacting nodes receive the OC-Supported-Features AVP. This can be done by including the AVP in all answer messages or it can be done by remembering to whom the AVP has been sent. >>> Given the trivial nature of sending and reading OC-Supported-Features, I think we should put it in every answer. This mirrors the way we handle it in requests. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Mar 3 05:31:08 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59A71A012F for ; Mon, 3 Mar 2014 05:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-qxgYLzUBTI for ; Mon, 3 Mar 2014 05:31:04 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9F11A0123 for ; Mon, 3 Mar 2014 05:31:04 -0800 (PST) Received: from dhcp-b543.meeting.ietf.org (dhcp-b543.meeting.ietf.org [31.133.181.67]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s23DUiDC075220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Mar 2014 07:30:47 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <531482DB.4030609@usdonovans.com> Date: Mon, 3 Mar 2014 13:30:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1344E78C-3DC7-4039-BF45-78C8C3421FA6@nostrum.com> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonov! ans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dnTa3mVHgrKucrgD6D6r5EbpudI Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:31:07 -0000 +1.=20 Also, we don't need to include a lot of normative MUSTS around handling = every way a peer might behave badly, and we shouldn't force = implementations to act as "protocol police" for their peers. 2119 = language should be used sparingly, focusing on places where we think = implementors are likely to make bad choices without guidance.=20 On Mar 3, 2014, at 1:25 PM, Steve Donovan = wrote: > Ulrich, >=20 > I think you mean "abatement algorithm" below when you say feature. >=20 > There will be cases when it is valid to indicate support multiple = features. Support for the loss algorithm and agent overload is an = example. It is not valid for the reporting node to indicate support for = two abatement algorithms. >=20 > See more below. >=20 > Steve >=20 > On 3/3/14, 12:51 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Thank you for the clarification. >> It seems the proposed principles are: >>=20 >> 1. Reporting nodes MUST always include an OC-Supported-Features AVP = to an answer message that corresponds to a request which contained an = OC-Supported-Features AVP. >>=20 >> 2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer = message when >> 2a) There was no OC-Supported-Features AVP in the answer >> 2b) The OC-Supported-Features AVP in the answer indicated = support of more than one supported feature >> 2c) The OC-Supported-Features AVP in the answer indicated = support of less than one supported feature >> 2d) The OC-Supported-Features AVP in the answer indicated = support of exactly one feature, but that one is not supported by the = reacting node. > SRD> The above three should say abatement algorithm instead of = feature. >>=20 >> 3. Reacting nodes MUST interpret a received OC-OLR in the context of = the selected feature as received within the OC-Supported-Features AVP. >>=20 >> 4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features = in answers (from a destination) may or may not do proactive throttling = towards that destination. >>=20 >> 5. When receiving an answer that does not contain an OC-OLR, the = reacting node can safely ignore an OC-Supported-Features AVP (as there = is no OC-OLR which needs to be interpreted/ignored based on information = received in OC-Supported-Features). > SRD> This should be modified with a note saying that this can and = likely will change when the protocol is extended. Maybe this would be = in an extensibility section. >>=20 >> Is this agreeable? >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Monday, March 03, 2014 12:21 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org = list >> Subject: Re: [Dime] Issue#30 status >>=20 >>=20 >> On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >>=20 >>> Jouni, >>>=20 >>> Is this your proposal or your decision? >>> as none of these moving parts can be nailed down. My proposal here >> ^^^^^^^^^^^^ >>> Anyway, what is the expected behaviour of the reacting node (that = supports only OLR_DEFAULT_ALGO) when receiving an answer that contains >>> a) OLR but no Supported-Features >> Ehh.. if we agree that OC-Suppoted-Feature is in every answer message >> this would be an error case (misbehaving reporting node). My proposal >> would be reporting node to discard the OC-OLR. >>=20 >>> b) Supported Features but no OLR >> Reporting node has nothing to report except that it states it = supports >> DOIC. No chance in the current state, if there is one. >>=20 >>> c) OLR and Supported Features >>>=20 >>> Is the information received in Supported-Features in the answer = something that needs to be taken into account when sending subsequent = requests (i.e. do less proactive throttling), or something that needs to = be taken into account when interpreting the OLR received in the same = answer? >> Depends on the abatement algorithm or other future features. In the >> context of this I-D there is no such dependency since we got only >> one algorithm which is simple request-reply nature. >>=20 >>> What if the received Supported-Features in the answer does not = indicate OLR_DEFAULT_ALGO? >> Then the OC-OLR must include abatement information that matches with = the >> algorithm/feature indicated in the OC-Supported-Features. Sending an = empty >> OC-Supported-Features in not allowed. >>=20 >>> What if the received Supported-Features in the answer indicates = support of something different than OLR_DEFAULT_ALGO? >> Same as above. It is a valid use case (for future deployments) that a >> network absolutely wants to use some other algorithm than the = default. >> Then announcing the default is no use. Our protocol needs to be = flexible >> enough to allow such policy decision. >>=20 >>> What if the received Supported Features in the answer indicates = support of OLR_DEFAULT_ALGO and support of something else? >> This is something that is open but as I tried to drive at the = beginning >> the OC-Supported-Features in an answer names a single selected = abatement >> algorithm. >>=20 >> - Jouni >>=20 >>=20 >>=20 >>> Ulrich >>>=20 >>>=20 >>> -----Original Message----- >>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >>> Sent: Friday, February 28, 2014 2:49 PM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org = list >>> Subject: Re: [Dime] Issue#30 status >>>=20 >>>=20 >>> >>>=20 >>> Right. We are going back and forth and continue to do that as long >>> as none of these moving parts can be nailed down. My proposal here >>> is that we simply agree now that OC-Supported-Features is in every >>> answer message. Period. Get one corner nailed down. >>>=20 >>> The rest of the fixing inconsistencies and missing/excess parts >>> listed below then need to be done according to the above decision. >>>=20 >>> - JOuni >>>=20 >>>=20 >>> On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: >>>=20 >>>> Anders, >>>>=20 >>>> Yes, if we conclude that there is a requirement for = OC-Supported-Features to be sent in answers, then it should be included = in every answer. However, I still don't see that requirement. In = addition we would need some text specifying the expected behaviour of = the reacting node when receiving OC-Supported-Features in an answer, = keeping in mind that the reacting node cannot know whether it was the = server or an agent that inserted the OC-Supported-Feature, and whether = or not a subsequent request will be routed via that node. >>>>=20 >>>> Ulrich >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, = Anders >>>> Sent: Thursday, February 27, 2014 6:14 PM >>>> To: Ben Campbell; Steve Donovan >>>> Cc: dime@ietf.org list >>>> Subject: Re: [Dime] Issue#30 status >>>>=20 >>>> I also agree that including OC-Supported-Features in every answer = is preferable. In addition to mirroring Requests, it is in-line with how = Supported-Features are managed in at least some 3GPP interfaces as well. >>>>=20 >>>> /Anders >>>>=20 >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >>>> Sent: Wednesday, February 26, 2014 9:19 AM >>>> To: Steve Donovan >>>> Cc: dime@ietf.org list >>>> Subject: Re: [Dime] Issue#30 status >>>>=20 >>>>=20 >>>> On Feb 26, 2014, at 9:14 AM, Steve Donovan = wrote: >>>>=20 >>>>> SRD> We don't have consensus yet, but if we agree on the need for = reacting nodes to know whether there is support for DOIC in the Diameter = network then I think the requirement would be similar to how we are = handling overload reports. The reporting node MUST ensure that all = reacting nodes receive the OC-Supported-Features AVP. This can be done = by including the AVP in all answer messages or it can be done by = remembering to whom the AVP has been sent. >>>> Given the trivial nature of sending and reading = OC-Supported-Features, I think we should put it in every answer. This = mirrors the way we handle it in requests. >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>>=20 >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>=20 >=20 From nobody Mon Mar 3 05:56:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA92B1A0176 for ; Mon, 3 Mar 2014 05:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wX81XTMnutx for ; Mon, 3 Mar 2014 05:56:45 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A16001A0175 for ; Mon, 3 Mar 2014 05:56:44 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s23DubR1026564 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 3 Mar 2014 14:56:37 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s23DuaP3007410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 14:56:36 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 3 Mar 2014 14:56:36 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 14:56:36 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , ext Jouni Korhonen Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EvEWgP4lzthw Date: Mon, 3 Mar 2014 13:56:35 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> In-Reply-To: <531482DB.4030609@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 9128 X-purgate-ID: 151667::1393854997-00003660-EFFB1A96/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JSfCf2jKAn-j1Vfi4Y4ikq7vzmE Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:56:49 -0000 Steve, but (ad 2.) how would (implementers of) the reacting node know whether e.g. bit= 5 of the OC-Feature-Vector will be allocated to an "abatement algorithm" o= r to something else? Ad 5. Would it be ok to say: 5. When receiving an answer that does not contain an OC-OLR, the reacting n= ode which supports only OLR_DEFAULT_ALGO and no other feature can safely ig= nore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be = interpreted/ignored based on information received in OC-Supported-Features)= . This may be different for reacting nodes which support other features tha= n just OLR_DEFAULT_ALGO. Ulrich =20 -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20 Sent: Monday, March 03, 2014 2:26 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen Cc: ext Askerup, Anders; Ben Campbell; dime@ietf.org list Subject: Re: [Dime] Issue#30 status Ulrich, I think you mean "abatement algorithm" below when you say feature. There will be cases when it is valid to indicate support multiple=20 features. Support for the loss algorithm and agent overload is an=20 example. It is not valid for the reporting node to indicate support for=20 two abatement algorithms. See more below. Steve On 3/3/14, 12:51 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Thank you for the clarification. > It seems the proposed principles are: > > 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an= answer message that corresponds to a request which contained an OC-Support= ed-Features AVP. > > 2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message= when > 2a) There was no OC-Supported-Features AVP in the answer > 2b) The OC-Supported-Features AVP in the answer indicated support of mor= e than one supported feature > 2c) The OC-Supported-Features AVP in the answer indicated support of les= s than one supported feature > 2d) The OC-Supported-Features AVP in the answer indicated support of exa= ctly one feature, but that one is not supported by the reacting node. SRD> The above three should say abatement algorithm instead of feature. > > 3. Reacting nodes MUST interpret a received OC-OLR in the context of the = selected feature as received within the OC-Supported-Features AVP. > > 4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in a= nswers (from a destination) may or may not do proactive throttling towards = that destination. > > 5. When receiving an answer that does not contain an OC-OLR, the reacting= node can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR= which needs to be interpreted/ignored based on information received in OC-= Supported-Features). SRD> This should be modified with a note saying that this can and likely=20 will change when the protocol is extended. Maybe this would be in an=20 extensibility section. > > Is this agreeable? > > Ulrich > > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Monday, March 03, 2014 12:21 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list > Subject: Re: [Dime] Issue#30 status > > > On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > >> Jouni, >> >> Is this your proposal or your decision? >> as none of these moving parts can be nailed down. My proposal here > ^^^^^^^^^^^^ >> Anyway, what is the expected behaviour of the reacting node (that suppor= ts only OLR_DEFAULT_ALGO) when receiving an answer that contains >> a) OLR but no Supported-Features > Ehh.. if we agree that OC-Suppoted-Feature is in every answer message > this would be an error case (misbehaving reporting node). My proposal > would be reporting node to discard the OC-OLR. > >> b) Supported Features but no OLR > Reporting node has nothing to report except that it states it supports > DOIC. No chance in the current state, if there is one. > >> c) OLR and Supported Features >> >> Is the information received in Supported-Features in the answer somethin= g that needs to be taken into account when sending subsequent requests (i.e= . do less proactive throttling), or something that needs to be taken into a= ccount when interpreting the OLR received in the same answer? > Depends on the abatement algorithm or other future features. In the > context of this I-D there is no such dependency since we got only > one algorithm which is simple request-reply nature. > >> What if the received Supported-Features in the answer does not indicate= OLR_DEFAULT_ALGO? > Then the OC-OLR must include abatement information that matches with the > algorithm/feature indicated in the OC-Supported-Features. Sending an empt= y > OC-Supported-Features in not allowed. > >> What if the received Supported-Features in the answer indicates support = of something different than OLR_DEFAULT_ALGO? > Same as above. It is a valid use case (for future deployments) that a > network absolutely wants to use some other algorithm than the default. > Then announcing the default is no use. Our protocol needs to be flexible > enough to allow such policy decision. > >> What if the received Supported Features in the answer indicates support = of OLR_DEFAULT_ALGO and support of something else? > This is something that is open but as I tried to drive at the beginning > the OC-Supported-Features in an answer names a single selected abatement > algorithm. > > - Jouni > > > >> Ulrich >> >> >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Friday, February 28, 2014 2:49 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >> >> >> >> >> Right. We are going back and forth and continue to do that as long >> as none of these moving parts can be nailed down. My proposal here >> is that we simply agree now that OC-Supported-Features is in every >> answer message. Period. Get one corner nailed down. >> >> The rest of the fixing inconsistencies and missing/excess parts >> listed below then need to be done according to the above decision. >> >> - JOuni >> >> >> On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> >>> Anders, >>> >>> Yes, if we conclude that there is a requirement for OC-Supported-Featur= es to be sent in answers, then it should be included in every answer. Howev= er, I still don't see that requirement. In addition we would need some text= specifying the expected behaviour of the reacting node when receiving OC-S= upported-Features in an answer, keeping in mind that the reacting node cann= ot know whether it was the server or an agent that inserted the OC-Supporte= d-Feature, and whether or not a subsequent request will be routed via that = node. >>> >>> Ulrich >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, And= ers >>> Sent: Thursday, February 27, 2014 6:14 PM >>> To: Ben Campbell; Steve Donovan >>> Cc: dime@ietf.org list >>> Subject: Re: [Dime] Issue#30 status >>> >>> I also agree that including OC-Supported-Features in every answer is pr= eferable. In addition to mirroring Requests, it is in-line with how Support= ed-Features are managed in at least some 3GPP interfaces as well. >>> >>> /Anders >>> >>> -----Original Message----- >>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >>> Sent: Wednesday, February 26, 2014 9:19 AM >>> To: Steve Donovan >>> Cc: dime@ietf.org list >>> Subject: Re: [Dime] Issue#30 status >>> >>> >>> On Feb 26, 2014, at 9:14 AM, Steve Donovan w= rote: >>> >>>> SRD> We don't have consensus yet, but if we agree on the need for reac= ting nodes to know whether there is support for DOIC in the Diameter networ= k then I think the requirement would be similar to how we are handling over= load reports. The reporting node MUST ensure that all reacting nodes recei= ve the OC-Supported-Features AVP. This can be done by including the AVP in= all answer messages or it can be done by remembering to whom the AVP has b= een sent. >>> Given the trivial nature of sending and reading OC-Supported-Features, = I think we should put it in every answer. This mirrors the way we handle it= in requests. >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime >>> >>> _______________________________________________ >>> DiME mailing list >>> DiME@ietf.org >>> https://www.ietf.org/mailman/listinfo/dime > From nobody Mon Mar 3 08:01:16 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2E01A00E3 for ; Mon, 3 Mar 2014 08:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2w4krTtQXd8 for ; Mon, 3 Mar 2014 08:01:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 815A61A00BE for ; Mon, 3 Mar 2014 08:01:13 -0800 (PST) Received: from localhost ([127.0.0.1]:36960 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WKVIj-0005n9-Uc; Mon, 03 Mar 2014 17:01:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Mon, 03 Mar 2014 16:01:09 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/59 Message-ID: <064.bb0da2c00030e1b9c3d10d3561221494@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KuYQhqd9AOLrr1_n4dn74rCOeVk Cc: dime@ietf.org Subject: [Dime] [dime] #59 (draft-docdt-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:01:15 -0000 #59: test just testing. -- ------------------------------------+------------------------------------ Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: enhancement | Status: new Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Keywords: ------------------------------------+------------------------------------ Ticket URL: dime From nobody Mon Mar 3 08:02:17 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EE51A0171 for ; Mon, 3 Mar 2014 08:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX9gWBtCJd-B for ; Mon, 3 Mar 2014 08:02:12 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D71A00BE for ; Mon, 3 Mar 2014 08:02:12 -0800 (PST) Received: from localhost ([127.0.0.1]:36979 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WKVJh-0005ha-Cl; Mon, 03 Mar 2014 17:02:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Mon, 03 Mar 2014 16:02:09 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/59#comment:1 Message-ID: <079.d888b817510e5f041d859e03926f6481@trac.tools.ietf.org> References: <064.bb0da2c00030e1b9c3d10d3561221494@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <064.bb0da2c00030e1b9c3d10d3561221494@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3RXqFvJR2ms-8Z5dTpVmmFJB4zY Cc: dime@ietf.org Subject: Re: [Dime] [dime] #59 (draft-docdt-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:02:15 -0000 #59: test Changes (by jouni.nospam@gmail.com): * status: new => assigned Comment: Update. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: enhancement | Status: assigned Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: Keywords: | ------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Mar 3 08:07:19 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A901A0260 for ; Mon, 3 Mar 2014 08:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMQa18CNLh4E for ; Mon, 3 Mar 2014 08:07:11 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5371A01EF for ; Mon, 3 Mar 2014 08:06:43 -0800 (PST) Received: from localhost ([127.0.0.1]:37079 helo=grenache.tools.ietf.org) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WKVNa-00060L-IE; Mon, 03 Mar 2014 17:06:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "dime issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: jouni.nospam@gmail.com X-Trac-Project: dime Date: Mon, 03 Mar 2014 16:06:05 -0000 X-URL: http://tools.ietf.org/wg/dime/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/59#comment:2 Message-ID: <079.eec28de104c305e15ed08ba3e8f7d091@trac.tools.ietf.org> References: <064.bb0da2c00030e1b9c3d10d3561221494@trac.tools.ietf.org> X-Trac-Ticket-ID: 59 In-Reply-To: <064.bb0da2c00030e1b9c3d10d3561221494@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: jouni.nospam@gmail.com, dime@ietf.org X-SA-Exim-Mail-From: trac+dime@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LdQL3GlRgn5tFbZVGXHcY6SFIho Cc: dime@ietf.org Subject: Re: [Dime] [dime] #59 (draft-docdt-dime-ovli): test X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Reply-To: dime@ietf.org List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 16:07:16 -0000 #59: test Changes (by jouni.nospam@gmail.com): * status: assigned => closed * resolution: => worksforme Comment: last update. -- ------------------------------------+------------------------------------- Reporter: jouni.nospam@gmail.com | Owner: jouni.nospam@gmail.com Type: enhancement | Status: closed Priority: major | Milestone: Component: draft-docdt-dime-ovli | Version: Severity: Active WG Document | Resolution: worksforme Keywords: | ------------------------------------+------------------------------------- Ticket URL: dime From nobody Mon Mar 3 09:43:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88AA11A0311 for ; Mon, 3 Mar 2014 09:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDvDlUXt9e1W for ; Mon, 3 Mar 2014 09:42:52 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A714E1A0317 for ; Mon, 3 Mar 2014 09:42:51 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-6e-5314bf179183 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.A0.04249.81FB4135; Mon, 3 Mar 2014 18:42:48 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Mon, 3 Mar 2014 18:42:47 +0100 From: Maria Cruz Bartolome To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Jouni Korhonen" Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EpkDoA== Date: Mon, 3 Mar 2014 17:42:46 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209788539@ESESSMB101.ericsson.se> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B3C7A@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja7EfpFgg69LBCzmd55mt5jbu4LN Yv+6BiaLdW9XMDmweOycdZfdY8mSn0wes3Y+YfH4uf4qewBLFJdNSmpOZllqkb5dAlfG+Ytd bAVz7Cs2XvjF3MC43LiLkZNDQsBE4tGm+cwQtpjEhXvr2boYuTiEBI4wSsx8/o8VwlnEKDHn 5zY2kCo2ATuJS6dfMIHYIgK5EmuOfwCLMwt4SLRMXgTUwMEhLKAscfddFIgpIqAi8fqvGsgY EYFljBIdWw+wgpSzAMWvbt4HNoZXwFeiZ/1/qF3TOCTeHdsNVsQpECAx99V3MJsR6Lrvp9Yw QewSl7j1ZD4TxNUCEkv2nIf6QFTi5eN/rBC2ksSi25+h6nUkFuz+BHWntsSyha+ZIRYLSpyc +YRlAqPYLCRjZyFpmYWkZRaSlgWMLKsYOYpTi5Ny040MNjEC4+nglt8WOxgv/7U5xCjNwaIk zvvxrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsZFnF1bLn6uM/3NufoYpyNXcJdFgfWt 5yXcryQvZewU5Dh3XvmSloJZ2Sf2Vo7D8xoiWjeZ8aTv1xH7dyVxZcgcKbs3qx63fp4r8+vU JbOZW81+a+t8O3Fw3jNt3wt1B3e4qVa1S/9mu2HUtCSMYUYY87/Hoq7ruNJ+Tl5S5vxO6czN 5njBDAUlluKMREMt5qLiRACPAe0idQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YQr76yr1cCxVEjmVkZKnSeEh6y4 Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:42:56 -0000 Dear Ulrich, all, I think number 4 can be removed from the list of principles, this does not = provide any information as such, but just a possibility that is equally ope= n without this principle in the list. Don't you think? Cheers /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: lunes, 03 de marzo de 2014 13:52 To: ext Jouni Korhonen Cc: Ben Campbell; dime@ietf.org list Subject: Re: [Dime] Issue#30 status Thank you for the clarification. It seems the proposed principles are: 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an a= nswer message that corresponds to a request which contained an OC-Supported= -Features AVP. 2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message w= hen 2a) There was no OC-Supported-Features AVP in the answer 2b) The OC-Supported-Features AVP in the answer indicated support of more = than one supported feature 2c) The OC-Supported-Features AVP in the answer indicated support of less = than one supported feature 2d) The OC-Supported-Features AVP in the answer indicated support of exact= ly one feature, but that one is not supported by the reacting node. 3. Reacting nodes MUST interpret a received OC-OLR in the context of the se= lected feature as received within the OC-Supported-Features AVP.=20 4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in ans= wers (from a destination) may or may not do proactive throttling towards th= at destination.=20 5. When receiving an answer that does not contain an OC-OLR, the reacting n= ode can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR w= hich needs to be interpreted/ignored based on information received in OC-Su= pported-Features). Is this agreeable? Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Monday, March 03, 2014 12:21 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list Subject: Re: [Dime] Issue#30 status On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: > Jouni, >=20 > Is this your proposal or your decision? > as none of these moving parts can be nailed down. My proposal here ^^^^^^^^^^^^ > Anyway, what is the expected behaviour of the reacting node (that support= s only OLR_DEFAULT_ALGO) when receiving an answer that contains > a) OLR but no Supported-Features Ehh.. if we agree that OC-Suppoted-Feature is in every answer message this would be an error case (misbehaving reporting node). My proposal would be reporting node to discard the OC-OLR. > b) Supported Features but no OLR Reporting node has nothing to report except that it states it supports DOIC. No chance in the current state, if there is one. > c) OLR and Supported Features >=20 > Is the information received in Supported-Features in the answer something= that needs to be taken into account when sending subsequent requests (i.e.= do less proactive throttling), or something that needs to be taken into ac= count when interpreting the OLR received in the same answer?=20 Depends on the abatement algorithm or other future features. In the context of this I-D there is no such dependency since we got only one algorithm which is simple request-reply nature. >=20 > What if the received Supported-Features in the answer does not indicate = OLR_DEFAULT_ALGO? Then the OC-OLR must include abatement information that matches with the=20 algorithm/feature indicated in the OC-Supported-Features. Sending an empty OC-Supported-Features in not allowed. > What if the received Supported-Features in the answer indicates support o= f something different than OLR_DEFAULT_ALGO? Same as above. It is a valid use case (for future deployments) that a network absolutely wants to use some other algorithm than the default. Then announcing the default is no use. Our protocol needs to be flexible enough to allow such policy decision. > What if the received Supported Features in the answer indicates support o= f OLR_DEFAULT_ALGO and support of something else? This is something that is open but as I tried to drive at the beginning the OC-Supported-Features in an answer names a single selected abatement algorithm.=20 - Jouni > Ulrich >=20 >=20 > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 > Sent: Friday, February 28, 2014 2:49 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list > Subject: Re: [Dime] Issue#30 status >=20 >=20 > >=20 > Right. We are going back and forth and continue to do that as long > as none of these moving parts can be nailed down. My proposal here > is that we simply agree now that OC-Supported-Features is in every > answer message. Period. Get one corner nailed down. >=20 > The rest of the fixing inconsistencies and missing/excess parts > listed below then need to be done according to the above decision. >=20 > - JOuni >=20 >=20 > On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >=20 >> Anders, >>=20 >> Yes, if we conclude that there is a requirement for OC-Supported-Feature= s to be sent in answers, then it should be included in every answer. Howeve= r, I still don't see that requirement. In addition we would need some text = specifying the expected behaviour of the reacting node when receiving OC-Su= pported-Features in an answer, keeping in mind that the reacting node canno= t know whether it was the server or an agent that inserted the OC-Supported= -Feature, and whether or not a subsequent request will be routed via that n= ode. >>=20 >> Ulrich >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Ande= rs >> Sent: Thursday, February 27, 2014 6:14 PM >> To: Ben Campbell; Steve Donovan >> Cc: dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >>=20 >> I also agree that including OC-Supported-Features in every answer is pre= ferable. In addition to mirroring Requests, it is in-line with how Supporte= d-Features are managed in at least some 3GPP interfaces as well. >>=20 >> /Anders >>=20 >> -----Original Message----- >> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >> Sent: Wednesday, February 26, 2014 9:19 AM >> To: Steve Donovan >> Cc: dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >>=20 >>=20 >> On Feb 26, 2014, at 9:14 AM, Steve Donovan wr= ote: >>=20 >>> SRD> We don't have consensus yet, but if we agree on the need for react= ing nodes to know whether there is support for DOIC in the Diameter network= then I think the requirement would be similar to how we are handling overl= oad reports. The reporting node MUST ensure that all reacting nodes receiv= e the OC-Supported-Features AVP. This can be done by including the AVP in = all answer messages or it can be done by remembering to whom the AVP has be= en sent. >>=20 >> Given the trivial nature of sending and reading OC-Supported-Features, I= think we should put it in every answer. This mirrors the way we handle it = in requests. >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From nobody Mon Mar 3 10:09:23 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2791A023E; Mon, 3 Mar 2014 10:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9HCodNS_66O; Mon, 3 Mar 2014 10:08:54 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by ietfa.amsl.com (Postfix) with ESMTP id 684081A026F; Mon, 3 Mar 2014 10:08:46 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-86.messagelabs.com!1393870096!44584561!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3452 invoked from network); 3 Mar 2014 18:08:16 -0000 Received: from amer-mta101.csc.com (HELO amer-mta111.csc.com) (20.137.2.87) by server-9.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Mar 2014 18:08:16 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta111.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s23I8FsP009690; Mon, 3 Mar 2014 13:08:15 -0500 In-Reply-To: <22770_1393595933_5310961D_22770_13149_1_6B7134B31289DC4FAF731D844122B36E4CF58D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6C65.8080707@usdonovans.com> <087A34937E64E74E848732CFF8354B92097867F4@ESESSMB101.ericsson.se> <22770_1393595933_5310961D_22770_13149_1_6B7134B31289DC4FAF731D844122B36E4CF58D@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: MIME-Version: 1.0 X-KeepSent: 0E40572A:0A17B638-85257C90:00637BED; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 3 Mar 2014 13:08:14 -0500 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 03/03/2014 01:08:15 PM, Serialize complete at 03/03/2014 01:08:15 PM Content-Type: multipart/alternative; boundary="=_alternative 0063A28B85257C90_=" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ngJCnc9l-hFuxp05JXB5xpnussQ Cc: DiME , "dime@ietf.org" Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:09:03 -0000 This is a multipart message in MIME format. --=_alternative 0063A28B85257C90_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdG8gbWUgdGhpcyBiZWdzIHRoZSBxdWVzdGlvbjoNCldoYXQgZG9lcyAibm9ybWFs bHkgc2VuZHMgMTAwIHBhY2tldHMiIGFjdHVhbGx5IE1FQU4/ICBIb3cgaXMgdGhlIG51bWJlciAN Cm9mIHBhY2tldHMgaXQgIm5vcm1hbGx5IHNlbmRzIiBjYWxjdWxhdGVkPw0KDQpKYW5ldA0KDQpU aGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCBwbGVhc2UgDQpkZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNl IHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbiANCmRlbGl2ZXJ5LiBOT1RFOiBSZWdhcmRs ZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIA0KYmluZCBD U0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBs aWNpdCANCndyaXR0ZW4gYWdyZWVtZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNz bHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIA0KZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuDQoNCg0K DQpGcm9tOiAgIDxsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+DQpUbzogICAgIEpvdW5pIEtvcmhv bmVuIDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPiwgImRpbWVAaWV0Zi5vcmciIA0KPGRpbWVAaWV0 Zi5vcmc+DQpEYXRlOiAgIDAyLzI4LzIwMTQgMDg6NTkgQU0NClN1YmplY3Q6ICAgICAgICBSZTog W0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIA0KcHJldmlv dXMgaGlzdG9yeSAtIGNvbmNsdXNpb24NClNlbnQgYnk6ICAgICAgICAiRGlNRSIgPGRpbWUtYm91 bmNlc0BpZXRmLm9yZz4NCg0KDQoNCkpvdW5pLCBJJ20gYXNzdW1pbmcgdGhhdCB5b3UgYXJlIE9L IHdpdGggdGhlIGNvbmNsdXNpb24gZ2l2ZW4gaGVyZSB0b28sIA0KcmlnaHQ/IEogDQogDQpEZSA6 IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWFyaWEg Q3J1eiANCkJhcnRvbG9tZQ0KRW52b3nDqSA6IG1lcmNyZWRpIDI2IGbDqXZyaWVyIDIwMTQgMTM6 NTYNCsOAIDogZGltZUBpZXRmLm9yZw0KT2JqZXQgOiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGlu ZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIA0KaGlzdG9yeSAtIGNvbmNsdXNp b24NCiANCkZpbmUNCiANCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBUUk9UVElOLCANCkpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKQ0KU2Vu dDogbWnDqXJjb2xlcywgMjYgZGUgZmVicmVybyBkZSAyMDE0IDg6NDMNClRvOiBkaW1lQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJl IGJhc2VkIG9uIHByZXZpb3VzIA0KaGlzdG9yeSAtIGNvbmNsdXNpb24NCiANCkhpDQogDQpSZW1v dmUg4oCcZnJvbSBub3cgb27igJ0gaXMgYWNjZXB0YWJsZSBmb3IgbWUsIGJ1dCAgSSBoYXZlIGEg cHJlZmVyZW5jZSBmb3IgDQp0aGUgcmV2ZXJzZSB3b3JkaW5nIExpb25lbCBwcm9wb3Nlcywgd2hp Y2ggaXMgc2hvcnRlciBhbmQgYnJpbmdzIHRoZSANCmNsYXJpZmljYXRpb24gSSB3YXMgbG9va2lu ZyBmb3IsOg0KRm9yIGV4YW1wbGUgaWYgYW4gT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUg b2YgDQogMTAgaGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGluZyBub2RlIHdoaWNoIA0KIHdv dWxkIG5vcm1hbGx5IHNlbmQgMTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgDQogcGFja2V0 cyB0byB0aGUgcmVwb3J0aW5nIG5vZGUuDQogDQogDQpCZXN0IHJlZ2FyZHMgDQogDQpKSmFjcXVl cyANCiANCiANCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydCBkZSBTdGV2ZSBEb25vdmFuDQpFbnZvecOpIDogbHVuZGkgMjQgZsOpdnJpZXIgMjAxNCAx NzowMA0Kw4AgOiBkaW1lQGlldGYub3JnDQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRs aW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5IC0gY29uY2x1 c2lvbg0KIA0KSSdtIHdpdGggTGlvbmVsLiAgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUgcHJv cG9zZWQgd29yZGluZyBpcyANCmNvbmZ1c2luZy4gIFJlYWN0aW5nIG5vZGVzIGFsd2F5cyBvbmx5 IGFwcGx5IHRoZSByZWR1Y3Rpb24gcGVyY2VudGFnZSBmb3IgDQp0aGUgcGVyaW9kIG9mIHRpbWUg dGhhdCB0aGUgc3BlY2lmaWMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZS4gIFRoYXQgDQpwZXJp b2QgZWl0aGVyIGVuZHMgd2hlbiBhIG5ldyBvdmVybG9hZCByZXBvcnQgaXMgcmVjZWl2ZWQgb3Ig d2hlbiB0aGUgDQpvdmVybG9hZCByZXBvcnQgZXhwaXJlcy4NCg0KVGhhdCBzYWlkLCBJJ20gaGFw cHkgd2l0aCBqdXN0IHJlbW92aW5nIHRoZSB3b3JkcyAiZnJvbSBubyBvbiIgYXMgcHJvcG9zZWQg DQpieSBMaW9uZWwgYmVsb3cuDQoNClN0ZXZlDQogDQpPbiAyLzI0LzE0IDc6MjYgQU0sIGxpb25l bC5tb3JhbmRAb3JhbmdlLmNvbSB3cm90ZToNCkkgZG9uJ3Qgc2VlIHRoZSBpc3N1ZSwgYXMgZXhw bGFpbmVkIGluIG15IG1haWwgYnV0IE9LIHRvIHJlbW92ZSBpdC4gDQogDQpJZiAiZm9yIG5vdyIg aXMgcmVtb3ZlZCwgdGhlIHJlc3VsdGluZyB0ZXh0IHdvdWxkIGJlOg0KIA0KICBGb3IgZXhhbXBs ZSBpZiB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBzZW5kaW5nDQogIDEwMCBwYWNrZXRzIHBl ciBzZWNvbmQgdG8gdGhlIHJlcG9ydGluZyBub2RlLCB0aGVuDQogIGEgcmVjZXB0aW9uIG9mIE9D LVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDEwDQogIHdvdWxkIG1lYW4gdGhhdCBmcm9t IG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUDQogIG9ubHkgc2VuZCA5MCBwYWNrZXRzIHBl ciBzZWNvbmQuDQogDQpNYXliZSBpdCB3b3VsZCBiZSBldmVuIGVhc2llciB0byByZXZlcnNlIHRo ZSBzZW50ZW5jZSBhcyBmb2xsb3c6DQogDQogRm9yIGV4YW1wbGUgaWYgYW4gT0MtUmVkdWN0aW9u LVBlcmNlbnRhZ2UgdmFsdWUgb2YgDQogMTAgaGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGlu ZyBub2RlIHdoaWNoIA0KIHdvdWxkIG5vcm1hbGx5IHNlbmQgMTAwIHBhY2tldHMgTVVTVCBvbmx5 IHNlbmQgOTAgDQogcGFja2V0cyB0byB0aGUgcmVwb3J0aW5nIG5vZGUuDQogDQogDQpCdXQgSSdt IGZpbmUgaWYgdGhlIGluaXRpYWwgcHJvcG9zZWQgcmV2aXNlZCB0ZXh0IGlzIGtlcHQuDQogDQpM aW9uZWwNCiANCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEg cGFydCBkZSBNYXJpYSBDcnV6IA0KQmFydG9sb21lDQpFbnZvecOpIDogbHVuZGkgMjQgZsOpdnJp ZXIgMjAxNCAxNDoxMw0Kw4AgOiBkaW1lQGlldGYub3JnDQpPYmpldCA6IFJlOiBbRGltZV0gIzUy OiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5 IC0gY29uY2x1c2lvbg0KIA0KSGVsbG8sDQogDQpJIGFncmVlIHdpdGggVWxyaWNoJ3MgcHJvcG9z YWwNCkNoZWVycw0KL01DcnV6DQogDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIA0KLSBERS9NdW5pY2gpDQpT ZW50OiBsdW5lcywgMjQgZGUgZmVicmVybyBkZSAyMDE0IDEwOjQ2DQpUbzogZXh0IFRST1RUSU4s IEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91 cyANCmhpc3RvcnkgLSBjb25jbHVzaW9uDQogDQpJIHNoYXJlIEpKYWNxdWVzIGNvbmNlcm4uIFJl cGxhY2luZyAiZnJvbSBub3cgb24iIHdpdGggImZvciB0aGUgcGVyaW9kIA0KdGhhdCB0aGUgb3Zl cmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSINCmlzIG1pc2xlYWRpbmcuIE1heSBiZSBpdHMgYmV0dGVy IHRvIHNpbXBseSByZW1vdmUgImZyb20gbm93IG9uIi4NCiANClVscmljaA0KIA0KIA0KIA0KIA0K IA0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IGV4dCBUUk9UVElOLCANCkpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKQ0KU2VudDogRnJpZGF5 LCBGZWJydWFyeSAyMSwgMjAxNCA3OjExIFBNDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDog UmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2 aW91cyANCmhpc3RvcnkgLSBjb25jbHVzaW9uDQogDQpIaSBNQ3J1eiwgU3RldmUNCiANCkkgYWxz byBhZ3JlZSBvbiB0aGUgIndvdWxkIHNlbmQgIiBpbnN0ZWFkIG9mIHRoZSAid291bGQgaGF2ZSBz ZW50IiAgZm9yIA0Kc3VyZS4gIEJ1dCBJIGhhdmUgIGEgc21hbGwgY29uY2Vybi8gY2xhcmlmaWNh dGlvbiAgYWJvdXQgdGhlIFN0ZXZlIGNvbW1lbnQgDQpvbiAgICJmb3IgdGhlIHBlcmlvZCB0aGF0 IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlIiBhbmQgdGhlIGV4YW1wbGUgDQp0byB3aGlj aCBpdCByZWZlcnMuDQogDQpEdXJpbmcgdGhlIHRpbWUgdGhlIE9MUiBpcyBhY3RpdmUsIHdoaWNo IG1heSBiZSByYXRoZXIgbG9uZywgIHRoZSB0cmFmZmljIA0KdGhlIHJlYWN0aW5nIG5vZGUgd291 bGQgc2VuZCBtYXkgYmUgMTAwIHBhY2tldCAgd2hlbiBpdCBoYXMganVzdCByZWNlaXZlZCANCnRo ZSBPTFIuIEEgYml0IGxhdGVyLCB0aGUgdHJhZmZpYyBpdCB3b3VsZCBzZW5kIGNvdWxkIGJlIDEy MCAob3IgODApLCBhbmQgDQpmcm9tIHRoZSBPTFIgZGVmaW5pdGlvbiwgICBpdCB3b3VsZCBzZW5k IDEyMHgwLDkgKG9yIDgwKiAwLDkpIHBhY2tldHMsIG9uIA0Kd2hpY2ggSSBhZ3JlZS4gVGhpcyBp cyBpbiBsaW5lICB3aXRoIHRoZSBldmVyeSAxMHRoIHBhY2tldCBkcm9wcGluZyAgb24gDQp3aGlj aCBJIGFsc28gYWdyZWUuIA0KIA0KQXMgdGhlIHRleHQgICB3b3VsZCAgYmUgd3JpdHRlbiB3aXRo IHRoZSBTdGV2ZSBtb2RpZmljYXRpb24gLCB3ZSBtYXkgDQp1bmRlcnN0YW5kIGl0IGlzICA4MCBQ YWNrZXQgZHVyaW5nIGFsbCB0aGUgdGltZSAgdGhlIE9MUiBpcyBhY3RpdmUuIE5vdCANCnlldCB0 aGluayB0byBhbiBhbHRlcm5hdGl2ZSB0ZXh0LCBidXQgZmlyc3QgdG8gc2VlIGlmIHlvdSBhZ3Jl ZSB3aXRoIG15IA0KcmVtYXJrLg0KIA0KSkphY3F1ZXMgDQogDQogDQpEZSA6IERpTUUgW21haWx0 bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgDQpsaW9uZWwubW9yYW5kQG9y YW5nZS5jb20NCkVudm95w6kgOiB2ZW5kcmVkaSAyMSBmw6l2cmllciAyMDE0IDE4OjMzDQrDgCA6 IFN0ZXZlIERvbm92YW47IGRpbWVAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRo cm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyANCmhpc3RvcnkgLSBj b25jbHVzaW9uDQogDQorMSAoaW5jbHVkaW5nIFN0ZXZlIGNvbW1lbnQpDQogDQpEZSA6IERpTUUg W21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgU3RldmUgRG9ub3Zh bg0KRW52b3nDqSA6IHZlbmRyZWRpIDIxIGbDqXZyaWVyIDIwMTQgMTY6MzcNCsOAIDogZGltZUBp ZXRmLm9yZw0KT2JqZXQgOiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRv IGJlIGJhc2VkIG9uIHByZXZpb3VzIA0KaGlzdG9yeSAtIGNvbmNsdXNpb24NCiANCk1hcmlhIENy dXosDQogDQpJIHN1cHBvcnQgeW91ciBzdWdnZXN0ZWQgY2hhbmdlcy4gIEkgaGF2ZSBvbmUgZnVy dGhlciBzdWdnZXN0ZWQgY2hhbmdlIA0KYmVsb3cuDQogDQpTdGV2ZQ0KT24gMi8yMS8xNCAyOjQw IEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZToNCiM1MjogVGhyb3R0bGluZyBub3QgbmVl ZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkNCiANCkZvbGxvd2luZyBhZ3JlZW1l bnQgaXMgcmVhY2hlZDoNCiANCiBOb3cgKGNoYXB0ZXIgNC43KToNCiAgICBUaGUgT0MtUmVkdWN0 aW9uLVBlcmNlbnRhZ2UgQVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzIN CiAgICBhbmQgZGVzY3JpYmVzIHRoZSBwZXJjZW50YWdlIG9mIHRoZSB0cmFmZmljIHRoYXQgdGhl IHNlbmRlciBpcw0KICAgIHJlcXVlc3RlZCB0byByZWR1Y2UsIGNvbXBhcmVkIHRvIHdoYXQgaXQg b3RoZXJ3aXNlIHdvdWxkIGhhdmUgc2VudC4NCiANCiBQcm9wb3NhbDoNCiAgIFRoZSBPQy1SZWR1 Y3Rpb24tUGVyY2VudGFnZSBBVlAgKEFWUCBjb2RlIFRCRDgpIGlzIHR5cGUgb2YgVW5zaWduZWQz MiANCiAgIGFuZCBkZXNjcmliZXMgdGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0 aGUgc2VuZGVyIGlzIA0KICAgcmVxdWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8gd2hhdCBp dCBvdGhlcndpc2Ugd291bGQgc2VuZC4gIDwtLS0tDQogDQogDQogTm93IChjaGFwdGVyIDUuNS4y KToNCiAgICAgIEluZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVh Y3Rpbmcgbm9kZSB0bw0KICAgICAgcmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2Vu dGFnZS4gIEZvciBleGFtcGxlIGlmIHRoZQ0KICAgICAgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBz ZW5kaW5nIDEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8gdGhlDQogICAgICByZXBvcnRpbmcgbm9k ZSwgdGhlbiBhIHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZQ0KICAg ICAgb2YgMTAgd291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1V U1Qgb25seSBzZW5kDQogICAgICA5MCBwYWNrZXRzIHBlciBzZWNvbmQuICBIb3cgdGhlIHJlYWN0 aW5nIG5vZGUgYWNoaWV2ZXMgdGhlICJ0cnVlDQogICAgICByZWR1Y3Rpb24iIHRyYW5zYWN0aW9u cyBsZWFkaW5nIHRvIHRoZSBzZW50IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXANCiAgICAgIHRvIHRo ZSBpbXBsZW1lbnRhdGlvbi4gIFRoZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVy eQ0KICAgICAgMTB0aCBwYWNrZXQgZnJvbSBpdHMgb3V0cHV0IHF1ZXVlIGFuZCBsZXQgdGhlIGdl bmVyaWMgYXBwbGljYXRpb24NCiAgICAgIGxvZ2ljIHRyeSB0byByZWNvdmVyIGZyb20gaXQuMCA8 IHZhbHVlIDwgMTAwDQogDQogIFByb3Bvc2FsOg0KIEluZGljYXRlcyB0aGF0IHRoZSByZXBvcnRp bmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9kZSB0byByZWR1Y2UgDQogaXRzIHRyYWZmaWMg YnkgYSBnaXZlbiBwZXJjZW50YWdlLiBGb3IgZXhhbXBsZSBpZiB0aGUNCiByZWFjdGluZyBub2Rl IHdvdWxkIHNlbmQgMTAwIHBhY2tldHMgdG8gdGhlICAgICAgICAgICAgICAgICAgICAgICAgICA8 LS0tDQogcmVwb3J0aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBl cmNlbnRhZ2UgdmFsdWUgb2YgDQogMTAgd291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSBy ZWFjdGluZyBub2RlIE1VU1Qgb25seSBzZW5kDQogOTAgcGFja2V0cyBpbnN0ZWFkIG9mIDEwMC4g SG93IHRoZSByZWFjdGluZyBub2RlIGFjaGlldmVzIHRoZSAidHJ1ZSA8LS0tDQogcmVkdWN0aW9u IiB0cmFuc2FjdGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0IG1lc3NhZ2VzIGlzIHVw IHRvIA0KIHRoZSBpbXBsZW1lbnRhdGlvbi4gVGhlIHJlYWN0aW5nIG5vZGUgTUFZIHNpbXBseSBk cm9wIGV2ZXJ5IDEwdGggDQogcGFja2V0IGZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRo ZSBnZW5lcmljIGFwcGxpY2F0aW9uIGxvZ2ljIHRyeSANCiB0byByZWNvdmVyIGZyb20gaXQuDQpT UkQ+IFJlcGxhY2UgImZyb20gbm93IG9uIiBpbiB0aGUgYWJvdmUgd2l0aCAiZm9yIHRoZSBwZXJp b2QgdGhhdCB0aGUgDQpvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlIg0KIA0KIA0KIA0KIA0KIA0K IA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRp TUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RpbWUNCiANCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiANCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCmNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IA0KcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgDQplbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSANCmZhbHNpZmllLiBNZXJjaS4NCiANClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIA0KaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCANCmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIA0KbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KVGhhbmsgeW91Lg0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KIA0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0KY29uZmlkZW50aWVsbGVz IG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogDQpyZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyANCmVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9y YW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0 ZXJlLCBkZWZvcm1lIG91IA0KZmFsc2lmaWUuIE1lcmNpLg0KIA0KVGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgDQpp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIA0KZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gDQptb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFu ayB5b3UuDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZQ0KIA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQpjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiANCnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0K YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIA0KZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgDQpmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIA0KaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCANCmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIA0KbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLg0KVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQo= --=_alternative 0063A28B85257C90_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkl0IHNlZW1zIHRvIG1lIHRoaXMgYmVncyB0 aGUgcXVlc3Rpb246PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5X aGF0IGRvZXMgJnF1b3Q7bm9ybWFsbHkgc2VuZHMgMTAwIHBhY2tldHMmcXVvdDsNCmFjdHVhbGx5 IE1FQU4/ICZuYnNwO0hvdyBpcyB0aGUgbnVtYmVyIG9mIHBhY2tldHMgaXQgJnF1b3Q7bm9ybWFs bHkgc2VuZHMmcXVvdDsNCmNhbGN1bGF0ZWQ/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5KYW5ldDxicj4NCjxicj4NClRoaXMgaXMgYSBQUklWQVRFIG1l c3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZQ0KZGVs ZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhl IG1pc3Rha2UgaW4NCmRlbGl2ZXJ5LiBOT1RFOiBSZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMg ZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvDQpiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3Ro ZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IHdyaXR0ZW4NCmFncmVlbWVu dCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBv ZiBlLW1haWwNCmZvciBzdWNoIHB1cnBvc2UuPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkZyb206ICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPiZsdDtsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlRvOiAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Kb3VuaSBL b3Job25lbiAmbHQ7am91bmkubm9zcGFtQGdtYWlsLmNvbSZndDssDQomcXVvdDtkaW1lQGlldGYu b3JnJnF1b3Q7ICZsdDtkaW1lQGlldGYub3JnJmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEg Y29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5EYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNw Ow0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4wMi8yOC8yMDE0 IDA4OjU5IEFNPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNh bnMtc2VyaWYiPlN1YmplY3Q6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbRGltZV0gIzUyOg0KVGhyb3R0bGluZyBu b3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uPC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlNl bnQgYnk6ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPiZxdW90O0RpTUUmcXVvdDsNCiZsdDtkaW1lLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7PC9mb250Pg0KPGJyPg0KPGhyIG5vc2hhZGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Sm91bmksIEknbSBhc3N1bWluZyB0 aGF0DQp5b3UgYXJlIE9LIHdpdGggdGhlIGNvbmNsdXNpb24gZ2l2ZW4gaGVyZSB0b28sIHJpZ2h0 PyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iV2luZ2RpbmdzIj5KPC9m b250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPg0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5EZSA6PC9iPiBEaU1FIFs8L2Zv bnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGZh Y2U9IlRhaG9tYSI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48L2E+PGZvbnQg c2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gTWFyaWEgQ3J1eiBC YXJ0b2xvbWU8Yj48YnI+DQpFbnZvecOpIDo8L2I+IG1lcmNyZWRpIDI2IGbDqXZyaWVyIDIwMTQg MTM6NTY8Yj48YnI+DQrDgCA6PC9iPiBkaW1lQGlldGYub3JnPGI+PGJyPg0KT2JqZXQgOjwvYj4g UmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2 aW91cw0KaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j MDA0MDgwIGZhY2U9IkNhbGlicmkiPkZpbmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRp bWUtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+bWFpbHRvOmRp bWUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVF Uyk8Yj48YnI+DQpTZW50OjwvYj4gbWnDqXJjb2xlcywgMjYgZGUgZmVicmVybyBkZSAyMDE0IDg6 NDM8Yj48YnI+DQpUbzo8L2I+IGRpbWVAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6 IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91 cw0KaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPkhpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5SZW1vdmUg4oCcZnJvbSBub3cgb27igJ0gaXMNCmFjY2Vw dGFibGUgZm9yIG1lLCBidXQgJm5ic3A7SSBoYXZlIGEgcHJlZmVyZW5jZSBmb3IgdGhlIHJldmVy c2Ugd29yZGluZw0KTGlvbmVsIHByb3Bvc2VzLCB3aGljaCBpcyBzaG9ydGVyIGFuZCBicmluZ3Mg dGhlIGNsYXJpZmljYXRpb24gSSB3YXMgbG9va2luZw0KZm9yLDo8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5Gb3IgZXhhbXBsZSBpZiBhbiBPQy1SZWR1Y3Rpb24t UGVyY2VudGFnZQ0KdmFsdWUgb2YgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+Jm5ic3A7MTAgaGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGluZw0Kbm9kZSB3 aGljaCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDt3 b3VsZCBub3JtYWxseSBzZW5kIDEwMCBwYWNrZXRzDQpNVVNUIG9ubHkgc2VuZCA5MCA8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDtwYWNrZXRzIHRvIHRo ZSByZXBvcnRpbmcgbm9kZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0 MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9 IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5CZXN0IHJlZ2FyZHMgPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5KSmFjcXVlcyA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5EZSA6PC9iPiBEaU1FIFs8 L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0y IGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+XQ0KPGI+RGUgbGEgcGFy dCBkZTwvYj4gU3RldmUgRG9ub3ZhbjxiPjxicj4NCkVudm95w6kgOjwvYj4gbHVuZGkgMjQgZsOp dnJpZXIgMjAxNCAxNzowMDxiPjxicj4NCsOAIDo8L2I+IDwvZm9udD48YSBocmVmPW1haWx0bzpk aW1lQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+PHU+ZGlt ZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxi cj4NCk9iamV0IDo8L2I+IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8g YmUgYmFzZWQgb24gcHJldmlvdXMNCmhpc3RvcnkgLSBjb25jbHVzaW9uPC9mb250Pg0KPGJyPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5JJ20gd2l0aCBMaW9uZWwuICZuYnNwO0kg ZG9uJ3QNCnVuZGVyc3RhbmQgd2h5IHRoZSBwcm9wb3NlZCB3b3JkaW5nIGlzIGNvbmZ1c2luZy4g Jm5ic3A7UmVhY3Rpbmcgbm9kZXMNCmFsd2F5cyBvbmx5IGFwcGx5IHRoZSByZWR1Y3Rpb24gcGVy Y2VudGFnZSBmb3IgdGhlIHBlcmlvZCBvZiB0aW1lIHRoYXQNCnRoZSBzcGVjaWZpYyBvdmVybG9h ZCByZXBvcnQgaXMgYWN0aXZlLiAmbmJzcDtUaGF0IHBlcmlvZCBlaXRoZXIgZW5kcyB3aGVuDQph IG5ldyBvdmVybG9hZCByZXBvcnQgaXMgcmVjZWl2ZWQgb3Igd2hlbiB0aGUgb3ZlcmxvYWQgcmVw b3J0IGV4cGlyZXMuPGJyPg0KPGJyPg0KVGhhdCBzYWlkLCBJJ20gaGFwcHkgd2l0aCBqdXN0IHJl bW92aW5nIHRoZSB3b3JkcyAmcXVvdDtmcm9tIG5vIG9uJnF1b3Q7DQphcyBwcm9wb3NlZCBieSBM aW9uZWwgYmVsb3cuPGJyPg0KPGJyPg0KU3RldmU8YnI+DQogPC9mb250Pg0KPGJyPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPk9uIDIvMjQvMTQgNzoyNiBBTSwgPC9mb250Pjxh IGhyZWY9bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0Kd3JvdGU6 PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SSBkb24ndCBzZWUg dGhlIGlzc3VlLCBhcyBleHBsYWluZWQNCmluIG15IG1haWwgYnV0IE9LIHRvIHJlbW92ZSBpdC4g PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SWYgJnF1b3Q7Zm9yIG5vdyZx dW90OyBpcyByZW1vdmVkLA0KdGhlIHJlc3VsdGluZyB0ZXh0IHdvdWxkIGJlOjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyBGb3IgZXhhbXBsZSBpZiB0aGUgcmVh Y3RpbmcNCm5vZGUgaGFzIGJlZW4gc2VuZGluZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPiZuYnNwOyAxMDAgcGFja2V0cyBwZXIgc2Vjb25kIHRvIHRoZQ0KcmVw b3J0aW5nIG5vZGUsIHRoZW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij4mbmJzcDsgYSByZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UNCnZhbHVl IG9mIDEwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 IHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbg0KdGhlIHJlYWN0aW5nIG5vZGUgTVVTVDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyBvbmx5IHNlbmQg OTAgcGFja2V0cyBwZXIgc2Vjb25kLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPk1heWJlIGl0IHdvdWxkIGJlIGV2ZW4gZWFzaWVyIHRvIHJldmVyc2UNCnRoZSBzZW50ZW5j ZSBhcyBmb2xsb3c6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 Rm9yIGV4YW1wbGUgaWYgYW4gT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UNCnZhbHVlIG9mIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzEwIGhhcyBiZWVu IHJlY2VpdmVkLCB0aGUgcmVhY3RpbmcNCm5vZGUgd2hpY2ggPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7d291bGQgbm9ybWFsbHkgc2VuZCAxMDAgcGFj a2V0cw0KTVVTVCBvbmx5IHNlbmQgOTAgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+Jm5ic3A7cGFja2V0cyB0byB0aGUgcmVwb3J0aW5nIG5vZGUuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+QnV0IEknbSBmaW5lIGlmIHRoZSBpbml0aWFsIHByb3Bv c2VkDQpyZXZpc2VkIHRleHQgaXMga2VwdC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij5MaW9uZWw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5EZSA6 IERpTUUgWzwvZm9udD48YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48Zm9u dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bWFpbHRvOmRpbWUtYm91 bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+XQ0KRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6IEJhcnRvbG9tZTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkVudm95w6kgOiBsdW5kaSAyNCBmw6l2cmllciAy MDE0IDE0OjEzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+w4Ag OiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGltZUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ZGltZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+T2JqZXQgOiBSZTogW0RpbWVdICM1 MjogVGhyb3R0bGluZw0Kbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5 IC0gY29uY2x1c2lvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkhlbGxv LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkkgYWdyZWUgd2l0aCBVbHJp Y2gncyBwcm9wb3NhbDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PkNoZWVyczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPi9NQ3J1 ejwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkZyb206IERpTUUgWzwvZm9u dD48YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9y ZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+XQ0KT24gQmVo YWxmIE9mIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCk8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5TZW50OiBsdW5lcywgMjQgZGUgZmVicmVybyBkZSAy MDE0DQoxMDo0NjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRv OiBleHQgVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpOw0KPC9mb250PjxhIGhy ZWY9bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291 cmllciBOZXciPjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPlN1YmplY3Q6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5n DQpub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9u PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SSBzaGFyZSBKSmFjcXVlcyBj b25jZXJuLiBSZXBsYWNpbmcNCiZxdW90O2Zyb20gbm93IG9uJnF1b3Q7IHdpdGggJnF1b3Q7Zm9y IHRoZSBwZXJpb2QgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0DQppcyBhY3RpdmUmcXVvdDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5pcyBtaXNsZWFkaW5nLiBN YXkgYmUgaXRzIGJldHRlciB0bw0Kc2ltcGx5IHJlbW92ZSAmcXVvdDtmcm9tIG5vdyBvbiZxdW90 Oy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5VbHJpY2g8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij5Gcm9tOiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm Lm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1haWx0 bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPl0NCk9uIEJlaGFsZiBPZiBleHQgVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChK RUFOLUpBQ1FVRVMpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ U2VudDogRnJpZGF5LCBGZWJydWFyeSAyMSwgMjAxNCA3OjExDQpQTTwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRvOiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGlt ZUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ ZGltZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+U3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcNCm5vdCBuZWVkZWQg dG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5IaSBNQ3J1eiwgU3RldmU8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5JIGFsc28gYWdyZWUgb24gdGhlICZxdW90O3dvdWxkIHNl bmQNCiZxdW90OyBpbnN0ZWFkIG9mIHRoZSAmcXVvdDt3b3VsZCBoYXZlIHNlbnQmcXVvdDsgJm5i c3A7Zm9yIHN1cmUuICZuYnNwO0J1dA0KSSBoYXZlICZuYnNwO2Egc21hbGwgY29uY2Vybi8gY2xh cmlmaWNhdGlvbiAmbmJzcDthYm91dCB0aGUgU3RldmUgY29tbWVudA0Kb24gJm5ic3A7ICZxdW90 O2ZvciB0aGUgcGVyaW9kIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUmcXVvdDsN CmFuZCB0aGUgZXhhbXBsZSB0byB3aGljaCBpdCByZWZlcnMuPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+RHVyaW5nIHRoZSB0aW1lIHRoZSBPTFIgaXMgYWN0aXZlLA0Kd2hp Y2ggbWF5IGJlIHJhdGhlciBsb25nLCAmbmJzcDt0aGUgdHJhZmZpYyB0aGUgcmVhY3Rpbmcgbm9k ZSB3b3VsZCBzZW5kDQptYXkgYmUgMTAwIHBhY2tldCAmbmJzcDt3aGVuIGl0IGhhcyBqdXN0IHJl Y2VpdmVkIHRoZSBPTFIuIEEgYml0IGxhdGVyLA0KdGhlIHRyYWZmaWMgaXQgd291bGQgc2VuZCBj b3VsZCBiZSAxMjAgKG9yIDgwKSwgYW5kIGZyb20gdGhlIE9MUiBkZWZpbml0aW9uLA0KJm5ic3A7 IGl0IHdvdWxkIHNlbmQgMTIweDAsOSAob3IgODAqIDAsOSkgcGFja2V0cywgb24gJm5ic3A7d2hp Y2ggSSBhZ3JlZS4NClRoaXMgaXMgaW4gbGluZSAmbmJzcDt3aXRoIHRoZSBldmVyeSAxMHRoIHBh Y2tldCBkcm9wcGluZyAmbmJzcDtvbiB3aGljaA0KSSBhbHNvIGFncmVlLiA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+QXMgdGhlIHRleHQgJm5ic3A7IHdvdWxkICZuYnNw O2JlIHdyaXR0ZW4NCndpdGggdGhlIFN0ZXZlIG1vZGlmaWNhdGlvbiAsIHdlIG1heSB1bmRlcnN0 YW5kIGl0IGlzICZuYnNwOzgwIFBhY2tldCBkdXJpbmcNCmFsbCB0aGUgdGltZSAmbmJzcDt0aGUg T0xSIGlzIGFjdGl2ZS4gTm90IHlldCB0aGluayB0byBhbiBhbHRlcm5hdGl2ZSB0ZXh0LA0KYnV0 IGZpcnN0IHRvIHNlZSBpZiB5b3UgYWdyZWUgd2l0aCBteSByZW1hcmsuPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+SkphY3F1ZXMgPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+RGUgOiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0Bp ZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1h aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPl0NCkRlIGxhIHBhcnQgZGUgPC9mb250PjxhIGhyZWY9bWFpbHRvOmxp b25lbC5tb3JhbmRAb3JhbmdlLmNvbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3Vy aWVyIE5ldyI+PHU+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC91PjwvZm9udD48L2E+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5FbnZvecOpIDogdmVuZHJlZGkgMjEgZsOp dnJpZXIgMjAxNCAxODozMzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPsOAIDogU3RldmUgRG9ub3ZhbjsgPC9mb250PjxhIGhyZWY9bWFpbHRvOmRpbWVAaWV0Zi5v cmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmRpbWVAaWV0 Zi5vcmc8L3U+PC9mb250PjwvYT4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcNCm5vdCBuZWVkZWQgdG8gYmUgYmFz ZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij4rMSAoaW5jbHVkaW5nIFN0ZXZlIGNvbW1lbnQpPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+RGUgOiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFp bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciBOZXciPjx1Pm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250Pjwv YT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPl0NCkRlIGxhIHBhcnQgZGUgU3RldmUg RG9ub3ZhbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkVudm95 w6kgOiB2ZW5kcmVkaSAyMSBmw6l2cmllciAyMDE0IDE2OjM3PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+w4AgOiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGltZUBp ZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ZGlt ZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+T2JqZXQgOiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZw0Kbm90IG5lZWRlZCB0byBi ZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPk1hcmlhIENydXosPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+SSBzdXBwb3J0IHlvdXIgc3VnZ2VzdGVkIGNoYW5nZXMuICZuYnNwO0kN CmhhdmUgb25lIGZ1cnRoZXIgc3VnZ2VzdGVkIGNoYW5nZSBiZWxvdy48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5TdGV2ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPk9uIDIvMjEvMTQgMjo0MCBBTSwgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUN Cndyb3RlOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiM1Mjog VGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkDQpvbiBwcmV2aW91cyBoaXN0b3J5PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Rm9sbG93aW5nIGFncmVlbWVudCBp cyByZWFjaGVkOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZu YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwO05v dyAoY2hhcHRlciA0LjcpOjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPiZuYnNwOyAmbmJzcDsgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlDQpBVlAgKEFWUCBj b2RlIFRCRDgpIGlzIHR5cGUgb2YgVW5zaWduZWQzMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgYW5kIGRlc2NyaWJlcyB0aGUgcGVyY2Vu dGFnZQ0Kb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyByZXF1ZXN0ZWQgdG8gcmVk dWNlLA0KY29tcGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2Ugd291bGQgaGF2ZSBzZW50LjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwO1Byb3Bvc2FsOjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtUaGUgT0Mt UmVkdWN0aW9uLVBlcmNlbnRhZ2UNCkFWUCAoQVZQIGNvZGUgVEJEOCkgaXMgdHlwZSBvZiBVbnNp Z25lZDMyICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZuYnNwOyAmbmJzcDthbmQgZGVzY3JpYmVzIHRoZSBwZXJjZW50YWdlDQpvZiB0aGUgdHJhZmZp YyB0aGF0IHRoZSBzZW5kZXIgaXMgJm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO3JlcXVlc3RlZCB0byByZWR1Y2UsIGNvbXBhcmVk DQp0byB3aGF0IGl0IG90aGVyd2lzZSB3b3VsZCBzZW5kLiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsmbHQ7LS0tLTwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwO05vdyAoY2hhcHRlciA1LjUuMik6PC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJz cDsgSW5kaWNhdGVzIHRoYXQNCnRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcg bm9kZSB0bzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNw OyAmbmJzcDsgJm5ic3A7IHJlZHVjZSBpdHMgdHJhZmZpYw0KYnkgYSBnaXZlbiBwZXJjZW50YWdl LiAmbmJzcDtGb3IgZXhhbXBsZSBpZiB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyByZWFjdGluZyBub2RlDQpoYXMgYmVl biBzZW5kaW5nIDEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8gdGhlPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVwb3J0aW5n IG5vZGUsDQp0aGVuIGEgcmVjZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVl PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgb2YgMTAgd291bGQgbWVhbg0KdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcg bm9kZSBNVVNUIG9ubHkgc2VuZDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IDkwIHBhY2tldHMgcGVyDQpzZWNvbmQuICZuYnNw O0hvdyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hpZXZlcyB0aGUgJnF1b3Q7dHJ1ZTwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJl ZHVjdGlvbiZxdW90Ow0KdHJhbnNhY3Rpb25zIGxlYWRpbmcgdG8gdGhlIHNlbnQgcmVxdWVzdCBt ZXNzYWdlcyBpcyB1cDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci PiZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4NCiZuYnNwO1RoZSBy ZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeTwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5ic3A7IDEwdGggcGFja2V0IGZy b20NCml0cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlvbjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDsgJm5i c3A7IGxvZ2ljIHRyeSB0byByZWNvdmVyDQpmcm9tIGl0LjAgJmx0OyB2YWx1ZSAmbHQ7IDEwMDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyBQcm9wb3NhbDo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDtJbmRpY2F0ZXMg dGhhdCB0aGUgcmVwb3J0aW5nDQpub2RlIHVyZ2VzIHRoZSByZWFjdGluZyBub2RlIHRvIHJlZHVj ZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDtpdHMg dHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2UuDQpGb3IgZXhhbXBsZSBpZiB0aGU8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDtyZWFjdGluZyBub2Rl IHdvdWxkIHNlbmQgMTAwDQpwYWNrZXRzIHRvIHRoZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0Oy0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPiZuYnNwO3JlcG9ydGluZyBub2RlLCB0aGVuIGEgcmVjZXB0aW9uDQpvZiBPQy1SZWR1Y3Rp b24tUGVyY2VudGFnZSB2YWx1ZSBvZiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij4mbmJzcDsxMCB3b3VsZCBtZWFuIHRoYXQgZnJvbSBub3cgb24NCnRoZSByZWFj dGluZyBub2RlIE1VU1Qgb25seSBzZW5kPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+Jm5ic3A7OTAgcGFja2V0cyBpbnN0ZWFkIG9mIDEwMC4gSG93DQp0aGUgcmVh Y3Rpbmcgbm9kZSBhY2hpZXZlcyB0aGUgJnF1b3Q7dHJ1ZSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bHQ7LS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7 cmVkdWN0aW9uJnF1b3Q7IHRyYW5zYWN0aW9ucw0KbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0 IG1lc3NhZ2VzIGlzIHVwIHRvIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPiZuYnNwO3RoZSBpbXBsZW1lbnRhdGlvbi4gVGhlIHJlYWN0aW5nDQpub2RlIE1BWSBz aW1wbHkgZHJvcCBldmVyeSAxMHRoIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPiZuYnNwO3BhY2tldCBmcm9tIGl0cyBvdXRwdXQgcXVldWUNCmFuZCBsZXQgdGhl IGdlbmVyaWMgYXBwbGljYXRpb24gbG9naWMgdHJ5IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPiZuYnNwO3RvIHJlY292ZXIgZnJvbSBpdC48L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5TUkQmZ3Q7IFJlcGxhY2UgJnF1b3Q7ZnJv bSBub3cgb24mcXVvdDsNCmluIHRoZSBhYm92ZSB3aXRoICZxdW90O2ZvciB0aGUgcGVyaW9kIHRo YXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUmcXVvdDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPkRpTUUgbWFpbGluZyBsaXN0PC9mb250Pg0KPGJyPjxhIGhyZWY9 bWFpbHRvOkRpTUVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll ciBOZXciPjx1PkRpTUVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT4NCjxicj48YSBocmVmPWh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZT48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaW1lPC91PjwvZm9udD48L2E+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Q2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudA0KY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQNCmRvbmM8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5wYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcw0Kc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNl IG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUNCnNpZ25hbGVyPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kNCnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUNCnNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkNCmNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5DQpsYXc7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkDQpvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4NCmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcw0Kbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRo YW5rIHlvdS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJz cDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Q2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudA0KY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQNCmRvbmM8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcw0Kc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUNCnNpZ25hbGVyPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu c2kNCnF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0 YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUNCnNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkNCmNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5DQpsYXc7PC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkDQpvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4NCmVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcw0Kbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlRoYW5rIHlv dS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPkRpTUUgbWFpbGluZyBsaXN0PC9mb250Pg0KPGJyPjxhIGhyZWY9 bWFpbHRvOkRpTUVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll ciBOZXciPjx1PkRpTUVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT4NCjxicj48YSBocmVmPWh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZT48Zm9udCBzaXplPTIgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kaW1lPC91PjwvZm9udD48L2E+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQo8YnI+DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzDQpvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJyPg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleg0KcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzDQplbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPGJyPg0K T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUNCm91IGZhbHNpZmllLiBNZXJjaS48YnI+DQo8YnI+DQpUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmls ZWdlZA0KaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi48YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kDQpkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMuPGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4NCm1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC48YnI+DQpUaGFuayB5b3UuPGJyPg0KPC9mb250Pjx0dD48Zm9udCBzaXplPTI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1F IG1haWxpbmcgbGlzdDxicj4NCkRpTUVAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90dD48YSBocmVm PWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZT48dHQ+PGZvbnQgc2l6 ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwvZm9udD48L3R0 PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0063A28B85257C90_=-- From nobody Mon Mar 3 10:22:13 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278E51A023E for ; Mon, 3 Mar 2014 10:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABOPhIIK285N for ; Mon, 3 Mar 2014 10:21:59 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDE71A0206 for ; Mon, 3 Mar 2014 10:21:59 -0800 (PST) Received: from dhcp-a513.meeting.ietf.org ([31.133.165.19]:52749) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKXUt-000552-SG; Mon, 03 Mar 2014 10:21:55 -0800 Message-ID: <5314C842.5040105@usdonovans.com> Date: Mon, 03 Mar 2014 18:21:54 +0000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Jouni Korhonen References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------050606060304030708080809" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xBfyuQCGYoLQH22bQjGBCygMVew Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:22:03 -0000 This is a multi-part message in MIME format. --------------050606060304030708080809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Inline... On 3/3/14 1:56 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > > but > > (ad 2.) how would (implementers of) the reacting node know whether e.g. bit 5 of the OC-Feature-Vector will be allocated to an "abatement algorithm" or to something else? SRD> A node that doesn't understand the meaning of a bit presumably should ignore that bit. In addition, I believe we have it defined that the reporting node selects from the abatement algorithms in the OC-Supported-Features AVP received from the reacting node. > > Ad 5. Would it be ok to say: > 5. When receiving an answer that does not contain an OC-OLR, the reacting node which supports only OLR_DEFAULT_ALGO and no other feature can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on information received in OC-Supported-Features). This may be different for reacting nodes which support other features than just OLR_DEFAULT_ALGO. SRD> I ok with this if we remove the parenthetical statement. > > Ulrich > > > > -----Original Message----- > From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] > Sent: Monday, March 03, 2014 2:26 PM > To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen > Cc: ext Askerup, Anders; Ben Campbell; dime@ietf.org list > Subject: Re: [Dime] Issue#30 status > > Ulrich, > > I think you mean "abatement algorithm" below when you say feature. > > There will be cases when it is valid to indicate support multiple > features. Support for the loss algorithm and agent overload is an > example. It is not valid for the reporting node to indicate support for > two abatement algorithms. > > See more below. > > Steve > > On 3/3/14, 12:51 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Thank you for the clarification. >> It seems the proposed principles are: >> >> 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an answer message that corresponds to a request which contained an OC-Supported-Features AVP. >> >> 2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message when >> 2a) There was no OC-Supported-Features AVP in the answer >> 2b) The OC-Supported-Features AVP in the answer indicated support of more than one supported feature >> 2c) The OC-Supported-Features AVP in the answer indicated support of less than one supported feature >> 2d) The OC-Supported-Features AVP in the answer indicated support of exactly one feature, but that one is not supported by the reacting node. > SRD> The above three should say abatement algorithm instead of feature. >> 3. Reacting nodes MUST interpret a received OC-OLR in the context of the selected feature as received within the OC-Supported-Features AVP. >> >> 4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in answers (from a destination) may or may not do proactive throttling towards that destination. >> >> 5. When receiving an answer that does not contain an OC-OLR, the reacting node can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on information received in OC-Supported-Features). > SRD> This should be modified with a note saying that this can and likely > will change when the protocol is extended. Maybe this would be in an > extensibility section. >> Is this agreeable? >> >> Ulrich >> >> -----Original Message----- >> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >> Sent: Monday, March 03, 2014 12:21 PM >> To: Wiehe, Ulrich (NSN - DE/Munich) >> Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list >> Subject: Re: [Dime] Issue#30 status >> >> >> On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >> >>> Jouni, >>> >>> Is this your proposal or your decision? >>> as none of these moving parts can be nailed down. My proposal here >> ^^^^^^^^^^^^ >>> Anyway, what is the expected behaviour of the reacting node (that supports only OLR_DEFAULT_ALGO) when receiving an answer that contains >>> a) OLR but no Supported-Features >> Ehh.. if we agree that OC-Suppoted-Feature is in every answer message >> this would be an error case (misbehaving reporting node). My proposal >> would be reporting node to discard the OC-OLR. >> >>> b) Supported Features but no OLR >> Reporting node has nothing to report except that it states it supports >> DOIC. No chance in the current state, if there is one. >> >>> c) OLR and Supported Features >>> >>> Is the information received in Supported-Features in the answer something that needs to be taken into account when sending subsequent requests (i.e. do less proactive throttling), or something that needs to be taken into account when interpreting the OLR received in the same answer? >> Depends on the abatement algorithm or other future features. In the >> context of this I-D there is no such dependency since we got only >> one algorithm which is simple request-reply nature. >> >>> What if the received Supported-Features in the answer does not indicate OLR_DEFAULT_ALGO? >> Then the OC-OLR must include abatement information that matches with the >> algorithm/feature indicated in the OC-Supported-Features. Sending an empty >> OC-Supported-Features in not allowed. >> >>> What if the received Supported-Features in the answer indicates support of something different than OLR_DEFAULT_ALGO? >> Same as above. It is a valid use case (for future deployments) that a >> network absolutely wants to use some other algorithm than the default. >> Then announcing the default is no use. Our protocol needs to be flexible >> enough to allow such policy decision. >> >>> What if the received Supported Features in the answer indicates support of OLR_DEFAULT_ALGO and support of something else? >> This is something that is open but as I tried to drive at the beginning >> the OC-Supported-Features in an answer names a single selected abatement >> algorithm. >> >> - Jouni >> >> >> >>> Ulrich >>> >>> >>> -----Original Message----- >>> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] >>> Sent: Friday, February 28, 2014 2:49 PM >>> To: Wiehe, Ulrich (NSN - DE/Munich) >>> Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list >>> Subject: Re: [Dime] Issue#30 status >>> >>> >>> >>> >>> Right. We are going back and forth and continue to do that as long >>> as none of these moving parts can be nailed down. My proposal here >>> is that we simply agree now that OC-Supported-Features is in every >>> answer message. Period. Get one corner nailed down. >>> >>> The rest of the fixing inconsistencies and missing/excess parts >>> listed below then need to be done according to the above decision. >>> >>> - JOuni >>> >>> >>> On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: >>> >>>> Anders, >>>> >>>> Yes, if we conclude that there is a requirement for OC-Supported-Features to be sent in answers, then it should be included in every answer. However, I still don't see that requirement. In addition we would need some text specifying the expected behaviour of the reacting node when receiving OC-Supported-Features in an answer, keeping in mind that the reacting node cannot know whether it was the server or an agent that inserted the OC-Supported-Feature, and whether or not a subsequent request will be routed via that node. >>>> >>>> Ulrich >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Anders >>>> Sent: Thursday, February 27, 2014 6:14 PM >>>> To: Ben Campbell; Steve Donovan >>>> Cc: dime@ietf.org list >>>> Subject: Re: [Dime] Issue#30 status >>>> >>>> I also agree that including OC-Supported-Features in every answer is preferable. In addition to mirroring Requests, it is in-line with how Supported-Features are managed in at least some 3GPP interfaces as well. >>>> >>>> /Anders >>>> >>>> -----Original Message----- >>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell >>>> Sent: Wednesday, February 26, 2014 9:19 AM >>>> To: Steve Donovan >>>> Cc: dime@ietf.org list >>>> Subject: Re: [Dime] Issue#30 status >>>> >>>> >>>> On Feb 26, 2014, at 9:14 AM, Steve Donovan wrote: >>>> >>>>> SRD> We don't have consensus yet, but if we agree on the need for reacting nodes to know whether there is support for DOIC in the Diameter network then I think the requirement would be similar to how we are handling overload reports. The reporting node MUST ensure that all reacting nodes receive the OC-Supported-Features AVP. This can be done by including the AVP in all answer messages or it can be done by remembering to whom the AVP has been sent. >>>> Given the trivial nature of sending and reading OC-Supported-Features, I think we should put it in every answer. This mirrors the way we handle it in requests. >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime >>>> >>>> _______________________________________________ >>>> DiME mailing list >>>> DiME@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dime > --------------050606060304030708080809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Inline...

On 3/3/14 1:56 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

but

(ad 2.) how would (implementers of) the reacting node know whether e.g. bit 5 of the OC-Feature-Vector will be allocated to an "abatement algorithm" or to something else?
SRD> A node that doesn't understand the meaning of a bit presumably should ignore that bit.  In addition, I believe we have it defined that the reporting node selects from the abatement algorithms in the OC-Supported-Features AVP received from the reacting node. 

Ad 5. Would it be ok to say:
5. When receiving an answer that does not contain an OC-OLR, the reacting node which supports only OLR_DEFAULT_ALGO and no other feature can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on information received in OC-Supported-Features). This may be different for reacting nodes which support other features than just OLR_DEFAULT_ALGO.
SRD> I ok with this if we remove the parenthetical statement.

Ulrich
 


-----Original Message-----
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] 
Sent: Monday, March 03, 2014 2:26 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen
Cc: ext Askerup, Anders; Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

Ulrich,

I think you mean "abatement algorithm" below when you say feature.

There will be cases when it is valid to indicate support multiple 
features.  Support for the loss algorithm and agent overload is an 
example.  It is not valid for the reporting node to indicate support for 
two abatement algorithms.

See more below.

Steve

On 3/3/14, 12:51 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Thank you for the clarification.
It seems the proposed principles are:

1. Reporting nodes MUST always include an OC-Supported-Features AVP to an answer message that corresponds to a request which contained an OC-Supported-Features AVP.

2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message when
	2a) There was no OC-Supported-Features AVP in the answer
	2b) The OC-Supported-Features AVP in the answer indicated support of more than one supported feature
	2c) The OC-Supported-Features AVP in the answer indicated support of less than one supported feature
	2d) The OC-Supported-Features AVP in the answer indicated support of exactly one feature, but that one is not supported by the reacting node.
SRD> The above three should say abatement algorithm instead of feature.
3. Reacting nodes MUST interpret a received OC-OLR in the context of the selected feature as received within the OC-Supported-Features AVP.

4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in answers (from a destination) may or may not do proactive throttling towards that destination.

5. When receiving an answer that does not contain an OC-OLR, the reacting node can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on information received in OC-Supported-Features).
SRD> This should be modified with a note saying that this can and likely 
will change when the protocol is extended.  Maybe this would be in an 
extensibility section.
Is this agreeable?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
Sent: Monday, March 03, 2014 12:21 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

Jouni,

Is this your proposal or your decision?
as none of these moving parts can be nailed down. My proposal here
                                                     ^^^^^^^^^^^^
Anyway, what is the expected behaviour of the reacting node (that supports only OLR_DEFAULT_ALGO) when receiving an answer that contains
a) OLR but no Supported-Features
Ehh.. if we agree that OC-Suppoted-Feature is in every answer message
this would be an error case (misbehaving reporting node). My proposal
would be reporting node to discard the OC-OLR.

b) Supported Features but no OLR
Reporting node has nothing to report except that it states it supports
DOIC. No chance in the current state, if there is one.

c) OLR and Supported Features

Is the information received in Supported-Features in the answer something that needs to be taken into account when sending subsequent requests (i.e. do less proactive throttling), or something that needs to be taken into account when interpreting the OLR received in the same answer?
Depends on the abatement algorithm or other future features. In the
context of this I-D there is no such dependency since we got only
one algorithm which is simple request-reply nature.

What if the received Supported-Features in the answer  does not indicate OLR_DEFAULT_ALGO?
Then the OC-OLR must include abatement information that matches with the
algorithm/feature indicated in the OC-Supported-Features. Sending an empty
OC-Supported-Features in not allowed.

What if the received Supported-Features in the answer indicates support of something different than OLR_DEFAULT_ALGO?
Same as above. It is a valid use case (for future deployments) that a
network absolutely wants to use some other algorithm than the default.
Then announcing the default is no use. Our protocol needs to be flexible
enough to allow such policy decision.

What if the received Supported Features in the answer indicates support of OLR_DEFAULT_ALGO and support of something else?
This is something that is open but as I tried to drive at the beginning
the OC-Supported-Features in an answer names a single selected abatement
algorithm.

- Jouni



Ulrich


-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]
Sent: Friday, February 28, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


<as a chair>

Right. We are going back and forth and continue to do that as long
as none of these moving parts can be nailed down. My proposal here
is that we simply agree now that OC-Supported-Features is in every
answer message. Period. Get one corner nailed down.

The rest of the fixing inconsistencies and missing/excess parts
listed below then need to be done according to the above decision.

- JOuni


On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

Anders,

Yes, if we conclude that there is a requirement for OC-Supported-Features to be sent in answers, then it should be included in every answer. However, I still don't see that requirement. In addition we would need some text specifying the expected behaviour of the reacting node when receiving OC-Supported-Features in an answer, keeping in mind that the reacting node cannot know whether it was the server or an agent that inserted the OC-Supported-Feature, and whether or not a subsequent request will be routed via that node.

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Anders
Sent: Thursday, February 27, 2014 6:14 PM
To: Ben Campbell; Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

I also agree that including OC-Supported-Features in every answer is preferable. In addition to mirroring Requests, it is in-line with how Supported-Features are managed in at least some 3GPP interfaces as well.

/Anders

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Wednesday, February 26, 2014 9:19 AM
To: Steve Donovan
Cc: dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Feb 26, 2014, at 9:14 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

SRD> We don't have consensus yet, but if we agree on the need for reacting nodes to know whether there is support for DOIC in the Diameter network then I think the requirement would be similar to how we are handling overload reports.  The reporting node MUST ensure that all reacting nodes receive the OC-Supported-Features AVP.  This can be done by including the AVP in all answer messages or it can be done by remembering to whom the AVP has been sent.
Given the trivial nature of sending and reading OC-Supported-Features, I think we should put it in every answer. This mirrors the way we handle it in requests.

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

      


--------------050606060304030708080809-- From nobody Mon Mar 3 10:28:33 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FBA1A02C2 for ; Mon, 3 Mar 2014 10:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id re8s6ii9b1O4 for ; Mon, 3 Mar 2014 10:28:27 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 473A31A01C7 for ; Mon, 3 Mar 2014 10:28:27 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s23ISCV0099967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 3 Mar 2014 12:28:15 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <5314C842.5040105@usdonovans.com> Date: Mon, 3 Mar 2014 18:28:12 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/J6oOQYPb5FQKVqEyG2VMVLmo2xk Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:28:29 -0000 On Mar 3, 2014, at 6:21 PM, Steve Donovan = wrote: > Inline... >=20 > On 3/3/14 1:56 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: >> Steve, >>=20 >> but >>=20 >> (ad 2.) how would (implementers of) the reacting node know whether = e.g. bit 5 of the OC-Feature-Vector will be allocated to an "abatement = algorithm" or to something else? >>=20 > SRD> A node that doesn't understand the meaning of a bit presumably = should ignore that bit. In addition, I believe we have it defined that = the reporting node selects from the abatement algorithms in the = OC-Supported-Features AVP received from the reacting node. =20 This.=20 Can we assume that to be true for all "features" that can be identified = in OC-Supported-Features? >>=20 >> Ad 5. Would it be ok to say: >> 5. When receiving an answer that does not contain an OC-OLR, the = reacting node which supports only OLR_DEFAULT_ALGO and no other feature = can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR = which needs to be interpreted/ignored based on information received in = OC-Supported-Features). This may be different for reacting nodes which = support other features than just OLR_DEFAULT_ALGO. >>=20 > SRD> I ok with this if we remove the parenthetical statement.=20 I'm not sure what the point of saying that would be, at least with = normative language; it's just a statement of fact. What behavior are we = trying to avoid by saying the reacting node can ignore it?=20 >>=20 >> Ulrich >> =20 >>=20 From nobody Mon Mar 3 10:52:43 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8808E1A0356 for ; Mon, 3 Mar 2014 10:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr2Pd_DuiEbQ for ; Mon, 3 Mar 2014 10:52:35 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 29DAE1A0352 for ; Mon, 3 Mar 2014 10:52:35 -0800 (PST) Received: from dhcp-a513.meeting.ietf.org ([31.133.165.19]:52877) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKXyW-00020s-Tg for dime@ietf.org; Mon, 03 Mar 2014 10:52:31 -0800 Message-ID: <5314CF70.5000704@usdonovans.com> Date: Mon, 03 Mar 2014 18:52:32 +0000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dime@ietf.org References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6C65.8080707@usdonovans.com> <087A34937E64E74E848732CFF8354B92097867F4@ESESSMB101.ericsson.se> <22770_1393595933_5310961D_22770_13149_1_6B7134B31289DC4FAF731D844122B36E4CF58D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070209090105070704070709" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/J5bVJJ23sDdfOavUv8Vz2uyTtxM Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:52:41 -0000 This is a multi-part message in MIME format. --------------070209090105070704070709 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Janet, I'm not sure why we use the word packets. It should be requests instead. Throttling does not impact packets carrying answer messages, for instance. What is meant is that if normal handling would have resulted in 100 request messages being sent then an overload report requesting a reduction of 10% would result in 90 request messages being sent and 10 request messages being throttled. The loss algorithm is intentionally simple and stateless. The proposed implementation being to drop 1 in X messages where X is calculated based on the requested percentage reduction received in the overload report. This is meant to be independent of any hysteresis and independent of the arrival rate of service requests. Steve On 3/3/14 6:08 PM, Janet P Gunn wrote: > It seems to me this begs the question: > What does "normally sends 100 packets" actually MEAN? How is the > number of packets it "normally sends" calculated? > > Janet > > This is a PRIVATE message. If you are not the intended recipient, > please delete without copying and kindly advise us by e-mail of the > mistake in delivery. NOTE: Regardless of content, this e-mail shall > not operate to bind CSC to any order or other contract unless pursuant > to explicit written agreement or government initiative expressly > permitting the use of e-mail for such purpose. > > > > From: > To: Jouni Korhonen , "dime@ietf.org" > > Date: 02/28/2014 08:59 AM > Subject: Re: [Dime] #52: Throttling not needed to be based on > previous history - conclusion > Sent by: "DiME" > ------------------------------------------------------------------------ > > > > Jouni, I'm assuming that you are OK with the conclusion given here > too, right? J > > *De :* DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz > Bartolome* > Envoyé :* mercredi 26 février 2014 13:56* > À :* dime@ietf.org* > Objet :* Re: [Dime] #52: Throttling not needed to be based on previous > history - conclusion > > Fine > > *From:* DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *TROTTIN, > JEAN-JACQUES (JEAN-JACQUES)* > Sent:* miércoles, 26 de febrero de 2014 8:43* > To:* dime@ietf.org* > Subject:* Re: [Dime] #52: Throttling not needed to be based on > previous history - conclusion > > Hi > > Remove "from now on" is acceptable for me, but I have a preference > for the reverse wording Lionel proposes, which is shorter and brings > the clarification I was looking for,: > For example if an OC-Reduction-Percentage value of > 10 has been received, the reacting node which > would normally send 100 packets MUST only send 90 > packets to the reporting node. > > > Best regards > > JJacques > > > *De :* DiME [_mailto:dime-bounces@ietf.org_] *De la part de* Steve > Donovan* > Envoyé :* lundi 24 février 2014 17:00* > À :* _dime@ietf.org_ * > Objet :* Re: [Dime] #52: Throttling not needed to be based on previous > history - conclusion > > I'm with Lionel. I don't understand why the proposed wording is > confusing. Reacting nodes always only apply the reduction percentage > for the period of time that the specific overload report is active. > That period either ends when a new overload report is received or > when the overload report expires. > > That said, I'm happy with just removing the words "from no on" as > proposed by Lionel below. > > Steve > > On 2/24/14 7:26 AM, _lionel.morand@orange.com_ > wrote: > I don't see the issue, as explained in my mail but OK to remove it. > > If "for now" is removed, the resulting text would be: > > For example if the reacting node has been sending > 100 packets per second to the reporting node, then > a reception of OC-Reduction-Percentage value of 10 > would mean that from now on the reacting node MUST > only send 90 packets per second. > > Maybe it would be even easier to reverse the sentence as follow: > > For example if an OC-Reduction-Percentage value of > 10 has been received, the reacting node which > would normally send 100 packets MUST only send 90 > packets to the reporting node. > > > But I'm fine if the initial proposed revised text is kept. > > Lionel > > De : DiME [_mailto:dime-bounces@ietf.org_] De la part de Maria Cruz > Bartolome > Envoyé : lundi 24 février 2014 14:13 > À : _dime@ietf.org_ > Objet : Re: [Dime] #52: Throttling not needed to be based on previous > history - conclusion > > Hello, > > I agree with Ulrich's proposal > Cheers > /MCruz > > From: DiME [_mailto:dime-bounces@ietf.org_] On Behalf Of Wiehe, Ulrich > (NSN - DE/Munich) > Sent: lunes, 24 de febrero de 2014 10:46 > To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); _dime@ietf.org_ > > Subject: Re: [Dime] #52: Throttling not needed to be based on previous > history - conclusion > > I share JJacques concern. Replacing "from now on" with "for the period > that the overload report is active" > is misleading. May be its better to simply remove "from now on". > > Ulrich > > > > > > From: DiME [_mailto:dime-bounces@ietf.org_] On Behalf Of ext TROTTIN, > JEAN-JACQUES (JEAN-JACQUES) > Sent: Friday, February 21, 2014 7:11 PM > To: _dime@ietf.org_ > Subject: Re: [Dime] #52: Throttling not needed to be based on previous > history - conclusion > > Hi MCruz, Steve > > I also agree on the "would send " instead of the "would have sent" > for sure. But I have a small concern/ clarification about the > Steve comment on "for the period that the overload report is active" > and the example to which it refers. > > During the time the OLR is active, which may be rather long, the > traffic the reacting node would send may be 100 packet when it has > just received the OLR. A bit later, the traffic it would send could be > 120 (or 80), and from the OLR definition, it would send 120x0,9 (or > 80* 0,9) packets, on which I agree. This is in line with the every > 10th packet dropping on which I also agree. > > As the text would be written with the Steve modification , we may > understand it is 80 Packet during all the time the OLR is active. > Not yet think to an alternative text, but first to see if you agree > with my remark. > > JJacques > > > De : DiME [_mailto:dime-bounces@ietf.org_] De la part de > _lionel.morand@orange.com_ > Envoyé : vendredi 21 février 2014 18:33 > À : Steve Donovan; _dime@ietf.org_ > Objet : Re: [Dime] #52: Throttling not needed to be based on previous > history - conclusion > > +1 (including Steve comment) > > De : DiME [_mailto:dime-bounces@ietf.org_] De la part de Steve Donovan > Envoyé : vendredi 21 février 2014 16:37 > À : _dime@ietf.org_ > Objet : Re: [Dime] #52: Throttling not needed to be based on previous > history - conclusion > > Maria Cruz, > > I support your suggested changes. I have one further suggested change > below. > > Steve > On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote: > #52: Throttling not needed to be based on previous history > > Following agreement is reached: > > Now (chapter 4.7): > The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32 > and describes the percentage of the traffic that the sender is > requested to reduce, compared to what it otherwise would have sent. > > Proposal: > The OC-Reduction-Percentage AVP (AVP code TBD8) is type of > Unsigned32 > and describes the percentage of the traffic that the sender is > requested to reduce, compared to what it otherwise would send. > <---- > > > Now (chapter 5.5.2): > Indicates that the reporting node urges the reacting node to > reduce its traffic by a given percentage. For example if the > reacting node has been sending 100 packets per second to the > reporting node, then a reception of OC-Reduction-Percentage value > of 10 would mean that from now on the reacting node MUST only send > 90 packets per second. How the reacting node achieves the "true > reduction" transactions leading to the sent request messages is up > to the implementation. The reacting node MAY simply drop every > 10th packet from its output queue and let the generic application > logic try to recover from it.0 < value < 100 > > Proposal: > Indicates that the reporting node urges the reacting node to reduce > its traffic by a given percentage. For example if the > reacting node would send 100 packets to the > <--- > reporting node, then a reception of OC-Reduction-Percentage value of > 10 would mean that from now on the reacting node MUST only send > 90 packets instead of 100. How the reacting node achieves the "true > <--- > reduction" transactions leading to the sent request messages is up to > the implementation. The reacting node MAY simply drop every 10th > packet from its output queue and let the generic application logic try > to recover from it. > SRD> Replace "from now on" in the above with "for the period that the > overload report is active" > > > > > > > > _______________________________________________ > DiME mailing list > _DiME@ietf.org_ > _https://www.ietf.org/mailman/listinfo/dime_ > > > _________________________________________________________________________________________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _________________________________________________________________________________________________________________________ > > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > DiME mailing list > _DiME@ietf.org_ > _https://www.ietf.org/mailman/listinfo/dime_ > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, > deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------070209090105070704070709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Janet,

I'm not sure why we use the word packets.  It should be requests instead.  Throttling does not impact packets carrying answer messages, for instance.

What is meant is that if normal handling would have resulted in 100 request messages being sent then an overload report requesting a reduction of 10% would result in 90 request messages being sent and 10 request messages being throttled.  The loss algorithm is intentionally simple and stateless.  The proposed implementation being to drop 1 in X messages where X is calculated based on the requested percentage reduction received in the overload report.  This is meant to be independent of any hysteresis and independent of the arrival rate of service requests.

Steve

On 3/3/14 6:08 PM, Janet P Gunn wrote:
It seems to me this begs the question:
What does "normally sends 100 packets" actually MEAN?  How is the number of packets it "normally sends" calculated?

Janet

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




From:        <lionel.morand@orange.com>
To:        Jouni Korhonen <jouni.nospam@gmail.com>, "dime@ietf.org" <dime@ietf.org>
Date:        02/28/2014 08:59 AM
Subject:        Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Sent by:        "DiME" <dime-bounces@ietf.org>




Jouni, I'm assuming that you are OK with the conclusion given here too, right? J
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé :
mercredi 26 février 2014 13:56
À :
dime@ietf.org
Objet :
Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

 
Fine
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent:
miércoles, 26 de febrero de 2014 8:43
To:
dime@ietf.org
Subject:
Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

 
Hi
 
Remove “from now on” is acceptable for me, but  I have a preference for the reverse wording Lionel proposes, which is shorter and brings the clarification I was looking for,:
For example if an OC-Reduction-Percentage value of
 10 has been received, the reacting node which
 would normally send 100 packets MUST only send 90
 packets to the reporting node.
 
 
Best regards
 
JJacques
 
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé :
lundi 24 février 2014 17:00
À :
dime@ietf.org
Objet :
Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion

 
I'm with Lionel.  I don't understand why the proposed wording is confusing.  Reacting nodes always only apply the reduction percentage for the period of time that the specific overload report is active.  That period either ends when a new overload report is received or when the overload report expires.

That said, I'm happy with just removing the words "from no on" as proposed by Lionel below.

Steve

On 2/24/14 7:26 AM, lionel.morand@orange.com wrote:
I don't see the issue, as explained in my mail but OK to remove it.
 
If "for now" is removed, the resulting text would be:
 
  For example if the reacting node has been sending
  100 packets per second to the reporting node, then
  a reception of OC-Reduction-Percentage value of 10
  would mean that from now on the reacting node MUST
  only send 90 packets per second.
 
Maybe it would be even easier to reverse the sentence as follow:
 
 For example if an OC-Reduction-Percentage value of
 10 has been received, the reacting node which
 would normally send 100 packets MUST only send 90
 packets to the reporting node.
 
 
But I'm fine if the initial proposed revised text is kept.
 
Lionel
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : lundi 24 février 2014 14:13
À : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
Hello,
 
I agree with Ulrich's proposal
Cheers
/MCruz
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 10:46
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
I share JJacques concern. Replacing "from now on" with "for the period that the overload report is active"
is misleading. May be its better to simply remove "from now on".
 
Ulrich
 
 
 
 
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Friday, February 21, 2014 7:11 PM
To: dime@ietf.org
Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
Hi MCruz, Steve
 
I also agree on the "would send " instead of the "would have sent"  for sure.  But I have  a small concern/ clarification  about the Steve comment on   "for the period that the overload report is active" and the example to which it refers.
 
During the time the OLR is active, which may be rather long,  the traffic the reacting node would send may be 100 packet  when it has just received the OLR. A bit later, the traffic it would send could be 120 (or 80), and from the OLR definition,   it would send 120x0,9 (or 80* 0,9) packets, on  which I agree. This is in line  with the every 10th packet dropping  on which I also agree.
 
As the text   would  be written with the Steve modification , we may understand it is  80 Packet during all the time  the OLR is active. Not yet think to an alternative text, but first to see if you agree with my remark.
 
JJacques
 
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange.com
Envoyé : vendredi 21 février 2014 18:33
À : Steve Donovan; dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
+1 (including Steve comment)
 
De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : vendredi 21 février 2014 16:37
À : dime@ietf.org
Objet : Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion
 
Maria Cruz,
 
I support your suggested changes.  I have one further suggested change below.
 
Steve
On 2/21/14 2:40 AM, Maria Cruz Bartolome wrote:
#52: Throttling not needed to be based on previous history
 
Following agreement is reached:
 
 Now (chapter 4.7):
    The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32
    and describes the percentage of the traffic that the sender is
    requested to reduce, compared to what it otherwise would have sent.
 
 Proposal:
   The OC-Reduction-Percentage AVP (AVP code TBD8) is type of Unsigned32  
   and describes the percentage of the traffic that the sender is  
   requested to reduce, compared to what it otherwise would send.                  <----
 
 
 Now (chapter 5.5.2):
      Indicates that the reporting node urges the reacting node to
      reduce its traffic by a given percentage.  For example if the
      reacting node has been sending 100 packets per second to the
      reporting node, then a reception of OC-Reduction-Percentage value
      of 10 would mean that from now on the reacting node MUST only send
      90 packets per second.  How the reacting node achieves the "true
      reduction" transactions leading to the sent request messages is up
      to the implementation.  The reacting node MAY simply drop every
      10th packet from its output queue and let the generic application
      logic try to recover from it.0 < value < 100
 
  Proposal:
 Indicates that the reporting node urges the reacting node to reduce
 its traffic by a given percentage. For example if the
 reacting node would send 100 packets to the                          <---
 reporting node, then a reception of OC-Reduction-Percentage value of
 10 would mean that from now on the reacting node MUST only send
 90 packets instead of 100. How the reacting node achieves the "true       <---
 reduction" transactions leading to the sent request messages is up to
 the implementation. The reacting node MAY simply drop every 10th
 packet from its output queue and let the generic application logic try
 to recover from it.
SRD> Replace "from now on" in the above with "for the period that the overload report is active"
 
 
 
 
 
 
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 
_________________________________________________________________________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
 
 
_________________________________________________________________________________________________________________________

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

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------070209090105070704070709-- From nobody Mon Mar 3 12:08:21 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F2EB1A0341; Mon, 3 Mar 2014 12:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHY2o3n5ffuT; Mon, 3 Mar 2014 12:08:11 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4461A0151; Mon, 3 Mar 2014 12:08:10 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-2.tower-85.messagelabs.com!1393877285!23802137!1 X-Originating-IP: [20.137.2.180] X-StarScan-Received: X-StarScan-Version: 6.9.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30081 invoked from network); 3 Mar 2014 20:08:06 -0000 Received: from amer-mta103.csc.com (HELO amer-mta113.csc.com) (20.137.2.180) by server-2.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 3 Mar 2014 20:08:06 -0000 Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta113.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s23K85gR030354; Mon, 3 Mar 2014 15:08:05 -0500 In-Reply-To: <5314CF70.5000704@usdonovans.com> References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6C65.8080707@usdonovans.com> <087A34937E64E74E848732CFF8354B92097867F4@ESESSMB101.ericsson.se> <22770_1393595933_5310961D_22770_13149_1_6B7134B31289DC4FAF731D844122B36E4CF58D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5314CF70.5000704@usdonovans.com> To: Steve Donovan MIME-Version: 1.0 X-KeepSent: 135DE10D:C723F06A-85257C90:006D1BE9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Mon, 3 Mar 2014 15:08:04 -0500 X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 03/03/2014 03:08:05 PM, Serialize complete at 03/03/2014 03:08:05 PM Content-Type: multipart/alternative; boundary="=_alternative 006E9AEA85257C90_=" Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zg7_aJoVlewDtIKYX_C_N10oabk Cc: DiME , dime@ietf.org Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 20:08:17 -0000 This is a multipart message in MIME format. --=_alternative 006E9AEA85257C90_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 T0ssIEkgYWRtaXQgdG8gYmVpbmcgY29uZnVzZWQuDQoNCkluZGVwZW5kZW50IG9mIHRoZSBwYWNr ZXRzIHZzIHJlcXVlc3RzIGRpc3RpbmN0aW9uLQ0KDQpBc3N1bWluZyBhIG5vZGUgcmVjZWl2ZXMg YSBtZXNzYWdlIHJlcXVpcmluZyAxMCUgcmVkdWN0aW9uLCBkb2VzIHRoaXMgbWVhbg0KDQpBIC0g VGhlIG5vZGUgd2lsbCBkcm9wIG9uZSBvdXQgb2YgZXZlcnkgMTAgcmVxdWVzdHMgaXQgIndhbnRz IiB0byBzZW5kICwgDQp3aGV0aGVyIGl0ICJ3YW50cyIgdG8gc2VuZCAxMCByZXF1ZXN0cyBvciAx MDAwIHJlcXVlc3RzIHBlciB1bml0IHRpbWUuDQoNCm9yIA0KDQpCLSBJZiBpdCAibm9ybWFsbHki IHNlbmRzIDEwMCBtZXNzYWdlcyBwZXIgdW5pdCB0aW1lLCBpdCB3aWxsIHJlc3RyaWN0IA0KaXRz ZWxmIHRvIDkwIG1lc3NhZ2VzIHBlciB1bml0IHRpbWUsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBp dCAid2FudHMiIHRvIA0Kc2VuZCAxMCBvciAxMDAwDQo/DQoNCiJBIiBtYWtlcyBtb3JlIHNlbnNl IHRvIG1lLCBidXQgdGhlIHByb3Bvc2VkIHRleHQgKHJlcGVhdGVkIGJlbG93KSBzZWVtcyANCnRv IGltcGx5ICJCIiAoOTAgcGFja2V0cyBwZXIgc2Vjb25kIGJhc2VkIG9uIHdoYXQgaXQgImhhcyBi ZWVuIHNlbmRpbmciIG9yIA0KIndvdWxkIG5vcm1hbGx5IHNlbmQiIGluZGVwZW5kZW50IG9mIHRo ZSBudW1iZXIgdGhlIG5vZGUgIndhbnRzIiB0byANCnNlbmQiKS4NCg0KSWYgIkEiIGlzIGludGVu ZGVkLCBJIHN1Z2dlc3QgcmV3b3JkaW5nIHRoZSB0ZXh0IHRvIG1ha2UgaXQgY2xlYXJlcg0KDQo8 cXVvdGVkIGZyb20gYmVsb3c+DQogIEZvciBleGFtcGxlIGlmIHRoZSByZWFjdGluZyBub2RlIGhh cyBiZWVuIHNlbmRpbmcgDQogIDEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8gdGhlIHJlcG9ydGlu ZyBub2RlLCB0aGVuIA0KICBhIHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2 YWx1ZSBvZiAxMCANCiAgd291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBu b2RlIE1VU1QgDQogIG9ubHkgc2VuZCA5MCBwYWNrZXRzIHBlciBzZWNvbmQuIA0KICANCk1heWJl IGl0IHdvdWxkIGJlIGV2ZW4gZWFzaWVyIHRvIHJldmVyc2UgdGhlIHNlbnRlbmNlIGFzIGZvbGxv dzogDQogIA0KIEZvciBleGFtcGxlIGlmIGFuIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVl IG9mIA0KIDEwIGhhcyBiZWVuIHJlY2VpdmVkLCB0aGUgcmVhY3Rpbmcgbm9kZSB3aGljaCANCiB3 b3VsZCBub3JtYWxseSBzZW5kIDEwMCBwYWNrZXRzIE1VU1Qgb25seSBzZW5kIDkwIA0KIHBhY2tl dHMgdG8gdGhlIHJlcG9ydGluZyBub2RlLiANCjwvcXVvdGVkIGZyb20gYmVsb3c+DQoNCg0KSXQg aXMgcG9zc2libGUgdGhhdCB5b3VyICJ3b3VsZCBub3JtYWxseSBzZW5kIiBpcyB0aGUgc2FtZSBh cyBteSAid2FudHMgdG8gDQpzZW5kIiwgYnV0IHRoYXQgaXNuJ3QgdGhlIHdheSBpdCByZWFkcywg YXQgbGVhc3QgdG8gbWUuDQoNClRoYW5rcywNCg0KSmFuZXQNCg0KVGhpcyBpcyBhIFBSSVZBVEUg bWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIA0K ZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2Yg dGhlIG1pc3Rha2UgaW4gDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0 aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byANCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBv ciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgDQp3cml0dGVuIGFn cmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhl IHVzZSBvZiANCmUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLg0KDQoNCg0KRnJvbTogICBTdGV2ZSBE b25vdmFuIDxzcmRvbm92YW5AdXNkb25vdmFucy5jb20+DQpUbzogICAgIGRpbWVAaWV0Zi5vcmcN CkRhdGU6ICAgMDMvMDMvMjAxNCAwMTo1MiBQTQ0KU3ViamVjdDogICAgICAgIFJlOiBbRGltZV0g IzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gDQpwcmV2aW91cyBoaXN0 b3J5IC0gY29uY2x1c2lvbg0KU2VudCBieTogICAgICAgICJEaU1FIiA8ZGltZS1ib3VuY2VzQGll dGYub3JnPg0KDQoNCg0KSmFuZXQsDQoNCkknbSBub3Qgc3VyZSB3aHkgd2UgdXNlIHRoZSB3b3Jk IHBhY2tldHMuICBJdCBzaG91bGQgYmUgcmVxdWVzdHMgaW5zdGVhZC4gDQpUaHJvdHRsaW5nIGRv ZXMgbm90IGltcGFjdCBwYWNrZXRzIGNhcnJ5aW5nIGFuc3dlciBtZXNzYWdlcywgZm9yIGluc3Rh bmNlLg0KDQpXaGF0IGlzIG1lYW50IGlzIHRoYXQgaWYgbm9ybWFsIGhhbmRsaW5nIHdvdWxkIGhh dmUgcmVzdWx0ZWQgaW4gMTAwIA0KcmVxdWVzdCBtZXNzYWdlcyBiZWluZyBzZW50IHRoZW4gYW4g b3ZlcmxvYWQgcmVwb3J0IHJlcXVlc3RpbmcgYSByZWR1Y3Rpb24gDQpvZiAxMCUgd291bGQgcmVz dWx0IGluIDkwIHJlcXVlc3QgbWVzc2FnZXMgYmVpbmcgc2VudCBhbmQgMTAgcmVxdWVzdCANCm1l c3NhZ2VzIGJlaW5nIHRocm90dGxlZC4gIFRoZSBsb3NzIGFsZ29yaXRobSBpcyBpbnRlbnRpb25h bGx5IHNpbXBsZSBhbmQgDQpzdGF0ZWxlc3MuICBUaGUgcHJvcG9zZWQgaW1wbGVtZW50YXRpb24g YmVpbmcgdG8gZHJvcCAxIGluIFggbWVzc2FnZXMgDQp3aGVyZSBYIGlzIGNhbGN1bGF0ZWQgYmFz ZWQgb24gdGhlIHJlcXVlc3RlZCBwZXJjZW50YWdlIHJlZHVjdGlvbiByZWNlaXZlZCANCmluIHRo ZSBvdmVybG9hZCByZXBvcnQuICBUaGlzIGlzIG1lYW50IHRvIGJlIGluZGVwZW5kZW50IG9mIGFu eSBoeXN0ZXJlc2lzIA0KYW5kIGluZGVwZW5kZW50IG9mIHRoZSBhcnJpdmFsIHJhdGUgb2Ygc2Vy dmljZSByZXF1ZXN0cy4gDQoNClN0ZXZlDQoNCk9uIDMvMy8xNCA2OjA4IFBNLCBKYW5ldCBQIEd1 bm4gd3JvdGU6DQpJdCBzZWVtcyB0byBtZSB0aGlzIGJlZ3MgdGhlIHF1ZXN0aW9uOiANCldoYXQg ZG9lcyAibm9ybWFsbHkgc2VuZHMgMTAwIHBhY2tldHMiIGFjdHVhbGx5IE1FQU4/ICBIb3cgaXMg dGhlIG51bWJlciANCm9mIHBhY2tldHMgaXQgIm5vcm1hbGx5IHNlbmRzIiBjYWxjdWxhdGVkPyAN Cg0KSmFuZXQNCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhl IGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIA0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQg a2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gDQpkZWxpdmVyeS4g Tk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0 ZSB0byANCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVy c3VhbnQgdG8gZXhwbGljaXQgDQp3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRp YXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiANCmUtbWFpbCBmb3Igc3VjaCBw dXJwb3NlLiANCg0KDQoNCkZyb206ICAgICAgICA8bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPiAN ClRvOiAgICAgICAgSm91bmkgS29yaG9uZW4gPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+LCAiZGlt ZUBpZXRmLm9yZyIgDQo8ZGltZUBpZXRmLm9yZz4gDQpEYXRlOiAgICAgICAgMDIvMjgvMjAxNCAw ODo1OSBBTSANClN1YmplY3Q6ICAgICAgICBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3Qg bmVlZGVkIHRvIGJlIGJhc2VkIG9uIA0KcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb24gDQpT ZW50IGJ5OiAgICAgICAgIkRpTUUiIDxkaW1lLWJvdW5jZXNAaWV0Zi5vcmc+IA0KDQoNCg0KSm91 bmksIEknbSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgT0sgd2l0aCB0aGUgY29uY2x1c2lvbiBnaXZl biBoZXJlIHRvbywgDQpyaWdodD8gSiANCiAgDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiANCkJhcnRvbG9tZQ0KRW52b3nD qSA6IG1lcmNyZWRpIDI2IGbDqXZyaWVyIDIwMTQgMTM6NTYNCsOAIDogZGltZUBpZXRmLm9yZw0K T2JqZXQgOiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2Vk IG9uIHByZXZpb3VzIA0KaGlzdG9yeSAtIGNvbmNsdXNpb24gDQogIA0KRmluZSANCiAgDQpGcm9t OiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVFJPVFRJ TiwgDQpKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykNClNlbnQ6IG1pw6lyY29sZXMsIDI2IGRl IGZlYnJlcm8gZGUgMjAxNCA4OjQzDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtE aW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyAN Cmhpc3RvcnkgLSBjb25jbHVzaW9uIA0KICANCkhpIA0KICANClJlbW92ZSDigJxmcm9tIG5vdyBv buKAnSBpcyBhY2NlcHRhYmxlIGZvciBtZSwgYnV0ICBJIGhhdmUgYSBwcmVmZXJlbmNlIGZvciAN CnRoZSByZXZlcnNlIHdvcmRpbmcgTGlvbmVsIHByb3Bvc2VzLCB3aGljaCBpcyBzaG9ydGVyIGFu ZCBicmluZ3MgdGhlIA0KY2xhcmlmaWNhdGlvbiBJIHdhcyBsb29raW5nIGZvciw6IA0KRm9yIGV4 YW1wbGUgaWYgYW4gT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgDQogMTAgaGFzIGJl ZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGluZyBub2RlIHdoaWNoIA0KIHdvdWxkIG5vcm1hbGx5IHNl bmQgMTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgDQogcGFja2V0cyB0byB0aGUgcmVwb3J0 aW5nIG5vZGUuIA0KICANCiAgDQpCZXN0IHJlZ2FyZHMgDQogIA0KSkphY3F1ZXMgDQogIA0KICAN CkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBT dGV2ZSBEb25vdmFuDQpFbnZvecOpIDogbHVuZGkgMjQgZsOpdnJpZXIgMjAxNCAxNzowMA0Kw4Ag OiBkaW1lQGlldGYub3JnDQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBu ZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5IC0gY29uY2x1c2lvbiANCiAg DQpJJ20gd2l0aCBMaW9uZWwuICBJIGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZSBwcm9wb3NlZCB3 b3JkaW5nIGlzIA0KY29uZnVzaW5nLiAgUmVhY3Rpbmcgbm9kZXMgYWx3YXlzIG9ubHkgYXBwbHkg dGhlIHJlZHVjdGlvbiBwZXJjZW50YWdlIGZvciANCnRoZSBwZXJpb2Qgb2YgdGltZSB0aGF0IHRo ZSBzcGVjaWZpYyBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlLiAgVGhhdCANCnBlcmlvZCBlaXRo ZXIgZW5kcyB3aGVuIGEgbmV3IG92ZXJsb2FkIHJlcG9ydCBpcyByZWNlaXZlZCBvciB3aGVuIHRo ZSANCm92ZXJsb2FkIHJlcG9ydCBleHBpcmVzLg0KDQpUaGF0IHNhaWQsIEknbSBoYXBweSB3aXRo IGp1c3QgcmVtb3ZpbmcgdGhlIHdvcmRzICJmcm9tIG5vIG9uIiBhcyBwcm9wb3NlZCANCmJ5IExp b25lbCBiZWxvdy4NCg0KU3RldmUNCg0KT24gMi8yNC8xNCA3OjI2IEFNLCBsaW9uZWwubW9yYW5k QG9yYW5nZS5jb20gd3JvdGU6IA0KSSBkb24ndCBzZWUgdGhlIGlzc3VlLCBhcyBleHBsYWluZWQg aW4gbXkgbWFpbCBidXQgT0sgdG8gcmVtb3ZlIGl0LiANCiAgDQpJZiAiZm9yIG5vdyIgaXMgcmVt b3ZlZCwgdGhlIHJlc3VsdGluZyB0ZXh0IHdvdWxkIGJlOiANCiAgDQogIEZvciBleGFtcGxlIGlm IHRoZSByZWFjdGluZyBub2RlIGhhcyBiZWVuIHNlbmRpbmcgDQogIDEwMCBwYWNrZXRzIHBlciBz ZWNvbmQgdG8gdGhlIHJlcG9ydGluZyBub2RlLCB0aGVuIA0KICBhIHJlY2VwdGlvbiBvZiBPQy1S ZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSBvZiAxMCANCiAgd291bGQgbWVhbiB0aGF0IGZyb20g bm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1QgDQogIG9ubHkgc2VuZCA5MCBwYWNrZXRzIHBl ciBzZWNvbmQuIA0KICANCk1heWJlIGl0IHdvdWxkIGJlIGV2ZW4gZWFzaWVyIHRvIHJldmVyc2Ug dGhlIHNlbnRlbmNlIGFzIGZvbGxvdzogDQogIA0KIEZvciBleGFtcGxlIGlmIGFuIE9DLVJlZHVj dGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIA0KIDEwIGhhcyBiZWVuIHJlY2VpdmVkLCB0aGUgcmVh Y3Rpbmcgbm9kZSB3aGljaCANCiB3b3VsZCBub3JtYWxseSBzZW5kIDEwMCBwYWNrZXRzIE1VU1Qg b25seSBzZW5kIDkwIA0KIHBhY2tldHMgdG8gdGhlIHJlcG9ydGluZyBub2RlLiANCiAgDQogIA0K QnV0IEknbSBmaW5lIGlmIHRoZSBpbml0aWFsIHByb3Bvc2VkIHJldmlzZWQgdGV4dCBpcyBrZXB0 LiANCiAgDQpMaW9uZWwgDQogIA0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogDQpCYXJ0b2xvbWUgDQpFbnZvecOpIDogbHVu ZGkgMjQgZsOpdnJpZXIgMjAxNCAxNDoxMyANCsOAIDogZGltZUBpZXRmLm9yZyANCk9iamV0IDog UmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2 aW91cyANCmhpc3RvcnkgLSBjb25jbHVzaW9uIA0KICANCkhlbGxvLCANCiAgDQpJIGFncmVlIHdp dGggVWxyaWNoJ3MgcHJvcG9zYWwgDQpDaGVlcnMgDQovTUNydXogDQogIA0KRnJvbTogRGlNRSBb bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdpZWhlLCBVbHJpY2gg KE5TTiANCi0gREUvTXVuaWNoKSANClNlbnQ6IGx1bmVzLCAyNCBkZSBmZWJyZXJvIGRlIDIwMTQg MTA6NDYgDQpUbzogZXh0IFRST1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKTsgZGlt ZUBpZXRmLm9yZyANClN1YmplY3Q6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVk ZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5IC0gY29uY2x1c2lvbiANCiAgDQpJ IHNoYXJlIEpKYWNxdWVzIGNvbmNlcm4uIFJlcGxhY2luZyAiZnJvbSBub3cgb24iIHdpdGggImZv ciB0aGUgcGVyaW9kIA0KdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSIgDQppcyBt aXNsZWFkaW5nLiBNYXkgYmUgaXRzIGJldHRlciB0byBzaW1wbHkgcmVtb3ZlICJmcm9tIG5vdyBv biIuIA0KICANClVscmljaCANCiAgDQogIA0KICANCiAgDQogIA0KRnJvbTogRGlNRSBbbWFpbHRv OmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBUUk9UVElOLCANCkpFQU4t SkFDUVVFUyAoSkVBTi1KQUNRVUVTKSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMjEsIDIwMTQg NzoxMSBQTSANClRvOiBkaW1lQGlldGYub3JnIA0KU3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRo cm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyANCmhpc3RvcnkgLSBj b25jbHVzaW9uIA0KICANCkhpIE1DcnV6LCBTdGV2ZSANCiAgDQpJIGFsc28gYWdyZWUgb24gdGhl ICJ3b3VsZCBzZW5kICIgaW5zdGVhZCBvZiB0aGUgIndvdWxkIGhhdmUgc2VudCIgIGZvciANCnN1 cmUuICBCdXQgSSBoYXZlICBhIHNtYWxsIGNvbmNlcm4vIGNsYXJpZmljYXRpb24gIGFib3V0IHRo ZSBTdGV2ZSBjb21tZW50IA0Kb24gICAiZm9yIHRoZSBwZXJpb2QgdGhhdCB0aGUgb3ZlcmxvYWQg cmVwb3J0IGlzIGFjdGl2ZSIgYW5kIHRoZSBleGFtcGxlIA0KdG8gd2hpY2ggaXQgcmVmZXJzLiAN CiAgDQpEdXJpbmcgdGhlIHRpbWUgdGhlIE9MUiBpcyBhY3RpdmUsIHdoaWNoIG1heSBiZSByYXRo ZXIgbG9uZywgIHRoZSB0cmFmZmljIA0KdGhlIHJlYWN0aW5nIG5vZGUgd291bGQgc2VuZCBtYXkg YmUgMTAwIHBhY2tldCAgd2hlbiBpdCBoYXMganVzdCByZWNlaXZlZCANCnRoZSBPTFIuIEEgYml0 IGxhdGVyLCB0aGUgdHJhZmZpYyBpdCB3b3VsZCBzZW5kIGNvdWxkIGJlIDEyMCAob3IgODApLCBh bmQgDQpmcm9tIHRoZSBPTFIgZGVmaW5pdGlvbiwgICBpdCB3b3VsZCBzZW5kIDEyMHgwLDkgKG9y IDgwKiAwLDkpIHBhY2tldHMsIG9uIA0Kd2hpY2ggSSBhZ3JlZS4gVGhpcyBpcyBpbiBsaW5lICB3 aXRoIHRoZSBldmVyeSAxMHRoIHBhY2tldCBkcm9wcGluZyAgb24gDQp3aGljaCBJIGFsc28gYWdy ZWUuIA0KIA0KQXMgdGhlIHRleHQgICB3b3VsZCAgYmUgd3JpdHRlbiB3aXRoIHRoZSBTdGV2ZSBt b2RpZmljYXRpb24gLCB3ZSBtYXkgDQp1bmRlcnN0YW5kIGl0IGlzICA4MCBQYWNrZXQgZHVyaW5n IGFsbCB0aGUgdGltZSAgdGhlIE9MUiBpcyBhY3RpdmUuIE5vdCANCnlldCB0aGluayB0byBhbiBh bHRlcm5hdGl2ZSB0ZXh0LCBidXQgZmlyc3QgdG8gc2VlIGlmIHlvdSBhZ3JlZSB3aXRoIG15IA0K cmVtYXJrLiANCiAgDQpKSmFjcXVlcyANCiAgDQogIA0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIA0KbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29t IA0KRW52b3nDqSA6IHZlbmRyZWRpIDIxIGbDqXZyaWVyIDIwMTQgMTg6MzMgDQrDgCA6IFN0ZXZl IERvbm92YW47IGRpbWVAaWV0Zi5vcmcgDQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRs aW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5IC0gY29uY2x1 c2lvbiANCiAgDQorMSAoaW5jbHVkaW5nIFN0ZXZlIGNvbW1lbnQpIA0KICANCkRlIDogRGlNRSBb bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2ZSBEb25vdmFu IA0KRW52b3nDqSA6IHZlbmRyZWRpIDIxIGbDqXZyaWVyIDIwMTQgMTY6MzcgDQrDgCA6IGRpbWVA aWV0Zi5vcmcgDQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQg dG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5IC0gY29uY2x1c2lvbiANCiAgDQpNYXJp YSBDcnV6LCANCiAgDQpJIHN1cHBvcnQgeW91ciBzdWdnZXN0ZWQgY2hhbmdlcy4gIEkgaGF2ZSBv bmUgZnVydGhlciBzdWdnZXN0ZWQgY2hhbmdlIA0KYmVsb3cuIA0KICANClN0ZXZlIA0KT24gMi8y MS8xNCAyOjQwIEFNLCBNYXJpYSBDcnV6IEJhcnRvbG9tZSB3cm90ZTogDQojNTI6IFRocm90dGxp bmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IA0KICANCkZvbGxv d2luZyBhZ3JlZW1lbnQgaXMgcmVhY2hlZDogDQogIA0KIE5vdyAoY2hhcHRlciA0LjcpOiANCiAg ICBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgQVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBl IG9mIFVuc2lnbmVkMzIgDQogICAgYW5kIGRlc2NyaWJlcyB0aGUgcGVyY2VudGFnZSBvZiB0aGUg dHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMgDQogICAgcmVxdWVzdGVkIHRvIHJlZHVjZSwgY29t cGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2Ugd291bGQgaGF2ZSBzZW50LiANCiAgDQogUHJvcG9z YWw6IA0KICAgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIEFWUCAoQVZQIGNvZGUgVEJEOCkg aXMgdHlwZSBvZiBVbnNpZ25lZDMyICAgDQoNCiAgIGFuZCBkZXNjcmliZXMgdGhlIHBlcmNlbnRh Z2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzICAgDQogICByZXF1ZXN0ZWQgdG8g cmVkdWNlLCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3VsZCBzZW5kLiAgPC0tLS0g DQogIA0KICANCiBOb3cgKGNoYXB0ZXIgNS41LjIpOiANCiAgICAgIEluZGljYXRlcyB0aGF0IHRo ZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9kZSB0byANCiAgICAgIHJlZHVj ZSBpdHMgdHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2UuICBGb3IgZXhhbXBsZSBpZiB0aGUg DQogICAgICByZWFjdGluZyBub2RlIGhhcyBiZWVuIHNlbmRpbmcgMTAwIHBhY2tldHMgcGVyIHNl Y29uZCB0byB0aGUgDQogICAgICByZXBvcnRpbmcgbm9kZSwgdGhlbiBhIHJlY2VwdGlvbiBvZiBP Qy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSANCiAgICAgIG9mIDEwIHdvdWxkIG1lYW4gdGhh dCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIG9ubHkgc2VuZCANCiAgICAgIDkw IHBhY2tldHMgcGVyIHNlY29uZC4gIEhvdyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hpZXZlcyB0aGUg InRydWUgDQogICAgICByZWR1Y3Rpb24iIHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRoZSBzZW50 IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXAgDQogICAgICB0byB0aGUgaW1wbGVtZW50YXRpb24uICBU aGUgcmVhY3Rpbmcgbm9kZSBNQVkgc2ltcGx5IGRyb3AgZXZlcnkgDQogICAgICAxMHRoIHBhY2tl dCBmcm9tIGl0cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlvbiAN CiAgICAgIGxvZ2ljIHRyeSB0byByZWNvdmVyIGZyb20gaXQuMCA8IHZhbHVlIDwgMTAwIA0KICAN CiAgUHJvcG9zYWw6IA0KIEluZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0 aGUgcmVhY3Rpbmcgbm9kZSB0byByZWR1Y2UgDQogaXRzIHRyYWZmaWMgYnkgYSBnaXZlbiBwZXJj ZW50YWdlLiBGb3IgZXhhbXBsZSBpZiB0aGUgDQogcmVhY3Rpbmcgbm9kZSB3b3VsZCBzZW5kIDEw MCBwYWNrZXRzIHRvIHRoZSAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLSANCg0KIHJlcG9y dGluZyBub2RlLCB0aGVuIGEgcmVjZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZh bHVlIG9mIA0KIDEwIHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9k ZSBNVVNUIG9ubHkgc2VuZCANCiA5MCBwYWNrZXRzIGluc3RlYWQgb2YgMTAwLiBIb3cgdGhlIHJl YWN0aW5nIG5vZGUgYWNoaWV2ZXMgdGhlICJ0cnVlIDwtLS0gDQogcmVkdWN0aW9uIiB0cmFuc2Fj dGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0IG1lc3NhZ2VzIGlzIHVwIHRvIA0KIHRo ZSBpbXBsZW1lbnRhdGlvbi4gVGhlIHJlYWN0aW5nIG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5 IDEwdGggDQogcGFja2V0IGZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmlj IGFwcGxpY2F0aW9uIGxvZ2ljIHRyeSANCiB0byByZWNvdmVyIGZyb20gaXQuIA0KU1JEPiBSZXBs YWNlICJmcm9tIG5vdyBvbiIgaW4gdGhlIGFib3ZlIHdpdGggImZvciB0aGUgcGVyaW9kIHRoYXQg dGhlIA0Kb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSIgDQogIA0KICANCiAgDQogIA0KICANCiAg DQogIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQpE aU1FIG1haWxpbmcgbGlzdCANCkRpTUVAaWV0Zi5vcmcgDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2RpbWUgDQogIA0KICANCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQoNCiAgDQpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg DQpjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyANCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogDQpyZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXIgDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgDQplbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sIA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kg Y2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgDQpmYWxzaWZpZS4gTWVyY2kuIA0K ICANClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIA0KaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsgDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIA0KZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLiANCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIA0KbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLiANClRoYW5rIHlvdS4gDQogIA0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCg0KICANCkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyANCmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jIA0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlz YXRpb24uIFNpIHZvdXMgYXZleiANCnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlciANCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBs ZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyANCmVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJp bGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSANCmZhbHNpZmllLiBN ZXJjaS4gDQogIA0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgDQppbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3OyANCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgDQpkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuIA0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gDQptb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuIA0KVGhhbmsgeW91LiANCiAgDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCkRpTUUgbWFpbGluZyBsaXN0 IA0KRGlNRUBpZXRmLm9yZyANCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGltZSANCiAgDQogIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQpjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiANCnJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IA0KZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgDQpmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIA0KaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCANCmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIA0KbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91 Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUg bWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RpbWUNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0K --=_alternative 006E9AEA85257C90_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9LLCBJIGFkbWl0IHRvIGJlaW5nIGNvbmZ1 c2VkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SW5k ZXBlbmRlbnQgb2YgdGhlIHBhY2tldHMgdnMgcmVxdWVzdHMNCmRpc3RpbmN0aW9uLTwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXNzdW1pbmcgYSBub2Rl IHJlY2VpdmVzIGEgbWVzc2FnZSByZXF1aXJpbmcNCjEwJSByZWR1Y3Rpb24sIGRvZXMgdGhpcyBt ZWFuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BIC0g VGhlIG5vZGUgd2lsbCBkcm9wIG9uZSBvdXQgb2YgZXZlcnkNCjEwIHJlcXVlc3RzIGl0ICZxdW90 O3dhbnRzJnF1b3Q7IHRvIHNlbmQgLCB3aGV0aGVyIGl0ICZxdW90O3dhbnRzJnF1b3Q7DQp0byBz ZW5kIDEwIHJlcXVlc3RzIG9yIDEwMDAgcmVxdWVzdHMgcGVyIHVuaXQgdGltZS48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPm9yIDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Qi0gSWYgaXQgJnF1b3Q7bm9ybWFs bHkmcXVvdDsgc2VuZHMNCjEwMCBtZXNzYWdlcyBwZXIgdW5pdCB0aW1lLCBpdCB3aWxsIHJlc3Ry aWN0IGl0c2VsZiB0byA5MCBtZXNzYWdlcyBwZXINCnVuaXQgdGltZSwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIGl0ICZxdW90O3dhbnRzJnF1b3Q7IHRvIHNlbmQgMTAgb3IgMTAwMDwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7QSZxdW90OyBtYWtlcyBtb3JlIHNlbnNl IHRvIG1lLA0KYnV0IHRoZSBwcm9wb3NlZCB0ZXh0IChyZXBlYXRlZCBiZWxvdykgc2VlbXMgdG8g aW1wbHkgJnF1b3Q7QiZxdW90OyAoOTANCnBhY2tldHMgcGVyIHNlY29uZCBiYXNlZCBvbiB3aGF0 IGl0ICZxdW90O2hhcyBiZWVuIHNlbmRpbmcmcXVvdDsgb3IgJnF1b3Q7d291bGQNCm5vcm1hbGx5 IHNlbmQmcXVvdDsgaW5kZXBlbmRlbnQgb2YgdGhlIG51bWJlciB0aGUgbm9kZSAmcXVvdDt3YW50 cyZxdW90Ow0KdG8gc2VuZCZxdW90OykuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5JZiAmcXVvdDtBJnF1b3Q7IGlzIGludGVuZGVkLCBJIHN1Z2dlc3QN CnJld29yZGluZyB0aGUgdGV4dCB0byBtYWtlIGl0IGNsZWFyZXI8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbHQ7cXVvdGVkIGZyb20gYmVsb3cmZ3Q7 PGJyPg0KICZuYnNwO0ZvciBleGFtcGxlIGlmIHRoZSByZWFjdGluZyBub2RlIDxiPmhhcyBiZWVu IHNlbmRpbmc8L2I+PC9mb250Pjxmb250IHNpemU9Mz48Yj4NCjwvYj48L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj48YnI+DQogJm5ic3A7MTAwIHBhY2tldHMgcGVyIHNl Y29uZDwvYj4gdG8gdGhlIHJlcG9ydGluZyBub2RlLCB0aGVuPC9mb250Pjxmb250IHNpemU9Mz4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDthIHJl Y2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSBvZiAxMDwvZm9udD48Zm9u dCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQog Jm5ic3A7d291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1Q8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KICZuYnNwO29ubHkgc2VuZDxiPiA5MCBwYWNrZXRzIHBlciBzZWNvbmQ8L2I+Ljwv Zm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCk1heWJlIGl0IHdvdWxkIGJlIGV2ZW4gZWFzaWVyIHRvIHJl dmVyc2UgdGhlIHNlbnRlbmNlIGFzIGZvbGxvdzo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXpl PTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIEZv ciBleGFtcGxlIGlmIGFuIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDxicj4NCiAx MCBoYXMgYmVlbiByZWNlaXZlZCwgdGhlIHJlYWN0aW5nIG5vZGUgd2hpY2ggPGJyPg0KIHdvdWxk IG5vcm1hbGx5IHNlbmQgMTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgPGJyPg0KIHBhY2tl dHMgdG8gdGhlIHJlcG9ydGluZyBub2RlLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZsdDsvcXVvdGVkIGZyb20gYmVsb3cm Z3Q7PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5JdCBpcyBwb3NzaWJsZSB0aGF0IHlvdXIgJnF1b3Q7d291bGQNCm5vcm1hbGx5IHNlbmQmcXVv dDsgaXMgdGhlIHNhbWUgYXMgbXkgJnF1b3Q7d2FudHMgdG8gc2VuZCZxdW90OywgYnV0IHRoYXQN Cmlzbid0IHRoZSB3YXkgaXQgcmVhZHMsIGF0IGxlYXN0IHRvIG1lLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SmFuZXQ8YnI+DQo8YnI+DQpUaGlzIGlz IGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UNCmRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkg ZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBj b250ZW50LCB0aGlzIGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0bw0KYmluZCBDU0MgdG8gYW55 IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0 dGVuDQphZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0 aW5nIHRoZSB1c2Ugb2YgZS1tYWlsDQpmb3Igc3VjaCBwdXJwb3NlLjwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlm Ij5Gcm9tOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj5TdGV2ZSBEb25vdmFuICZsdDtzcmRvbm92YW5AdXNkb25vdmFucy5j b20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMt c2VyaWYiPlRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5kaW1lQGlldGYub3JnPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjAzLzAzLzIw MTQgMDE6NTIgUE08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0i c2Fucy1zZXJpZiI+U3ViamVjdDogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtEaW1lXSAjNTI6DQpUaHJvdHRsaW5n IG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb248 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+ U2VudCBieTogJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7RGlNRSZxdW90Ow0KJmx0O2RpbWUtYm91bmNlc0BpZXRm Lm9yZyZndDs8L2ZvbnQ+DQo8YnI+DQo8aHIgbm9zaGFkZT4NCjxicj4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5KYW5ldCw8YnI+DQo8YnI+DQpJJ20gbm90 IHN1cmUgd2h5IHdlIHVzZSB0aGUgd29yZCBwYWNrZXRzLiAmbmJzcDtJdCBzaG91bGQgYmUgcmVx dWVzdHMgaW5zdGVhZC4NCiZuYnNwO1Rocm90dGxpbmcgZG9lcyBub3QgaW1wYWN0IHBhY2tldHMg Y2FycnlpbmcgYW5zd2VyIG1lc3NhZ2VzLCBmb3INCmluc3RhbmNlLjxicj4NCjxicj4NCldoYXQg aXMgbWVhbnQgaXMgdGhhdCBpZiBub3JtYWwgaGFuZGxpbmcgd291bGQgaGF2ZSByZXN1bHRlZCBp biAxMDAgcmVxdWVzdA0KbWVzc2FnZXMgYmVpbmcgc2VudCB0aGVuIGFuIG92ZXJsb2FkIHJlcG9y dCByZXF1ZXN0aW5nIGEgcmVkdWN0aW9uIG9mIDEwJQ0Kd291bGQgcmVzdWx0IGluIDkwIHJlcXVl c3QgbWVzc2FnZXMgYmVpbmcgc2VudCBhbmQgMTAgcmVxdWVzdCBtZXNzYWdlcw0KYmVpbmcgdGhy b3R0bGVkLiAmbmJzcDtUaGUgbG9zcyBhbGdvcml0aG0gaXMgaW50ZW50aW9uYWxseSBzaW1wbGUg YW5kIHN0YXRlbGVzcy4NCiZuYnNwO1RoZSBwcm9wb3NlZCBpbXBsZW1lbnRhdGlvbiBiZWluZyB0 byBkcm9wIDEgaW4gWCBtZXNzYWdlcyB3aGVyZSBYDQppcyBjYWxjdWxhdGVkIGJhc2VkIG9uIHRo ZSByZXF1ZXN0ZWQgcGVyY2VudGFnZSByZWR1Y3Rpb24gcmVjZWl2ZWQgaW4gdGhlDQpvdmVybG9h ZCByZXBvcnQuICZuYnNwO1RoaXMgaXMgbWVhbnQgdG8gYmUgaW5kZXBlbmRlbnQgb2YgYW55IGh5 c3RlcmVzaXMNCmFuZCBpbmRlcGVuZGVudCBvZiB0aGUgYXJyaXZhbCByYXRlIG9mIHNlcnZpY2Ug cmVxdWVzdHMuIDxicj4NCjxicj4NClN0ZXZlPC9mb250Pjxmb250IHNpemU9Mz48YnI+DQo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPk9uIDMvMy8xNCA2OjA4IFBNLCBKYW5ldCBQIEd1bm4gd3Jv dGU6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JdCBzZWVtcyB0 byBtZSB0aGlzIGJlZ3MgdGhlIHF1ZXN0aW9uOjwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCldoYXQgZG9lcyAmcXVvdDtub3Jt YWxseSBzZW5kcyAxMDAgcGFja2V0cyZxdW90OyBhY3R1YWxseSBNRUFOPyAmbmJzcDtIb3cNCmlz IHRoZSBudW1iZXIgb2YgcGFja2V0cyBpdCAmcXVvdDtub3JtYWxseSBzZW5kcyZxdW90OyBjYWxj dWxhdGVkPzwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPjxicj4NCkphbmV0PGJyPg0KPGJyPg0KVGhpcyBpcyBhIFBSSVZBVEUg bWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpk ZWxldGUgd2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0 aGUgbWlzdGFrZSBpbg0KZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhp cyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8NCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBv dGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbg0KYWdyZWVt ZW50IG9yIGdvdmVybm1lbnQgaW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNl IG9mIGUtbWFpbA0KZm9yIHN1Y2ggcHVycG9zZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8 YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1z ZXJpZiI+PGJyPg0KRnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250PjxhIGhy ZWY9bWFpbHRvOmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT48Zm9udCBzaXplPTEgY29sb3I9Ymx1 ZSBmYWNlPSJzYW5zLXNlcmlmIj48dT4mbHQ7bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tJmd0Ozwv dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVm NWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpUbzogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Kb3VuaQ0KS29yaG9uZW4g PC9mb250PjxhIGhyZWY9bWFpbHRvOmpvdW5pLm5vc3BhbUBnbWFpbC5jb20+PGZvbnQgc2l6ZT0x IGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+Jmx0O2pvdW5pLm5vc3BhbUBnbWFpbC5j b20mZ3Q7PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiwNCjwv Zm9udD48YSBocmVmPW1haWx0bzpkaW1lQGlldGYub3JnPjxmb250IHNpemU9MSBjb2xvcj1ibHVl IGZhY2U9InNhbnMtc2VyaWYiPjx1PiZxdW90O2RpbWVAaWV0Zi5vcmcmcXVvdDs8L3U+PC9mb250 PjwvYT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2ZvbnQ+PGEgaHJlZj1tYWls dG86ZGltZUBpZXRmLm9yZz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5zLXNlcmlm Ij48dT4mbHQ7ZGltZUBpZXRmLm9yZyZndDs8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0K RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4wMi8yOC8yMDE0DQowODo1OSBBTTwvZm9udD48Zm9udCBzaXplPTM+IDwv Zm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQpT dWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlJlOg0KW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRv IGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uPC9mb250Pjxmb250IHNp emU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlm Ij48YnI+DQpTZW50IGJ5OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0RpTUUmcXVvdDsNCjwvZm9udD48YSBocmVm PSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBm YWNlPSJzYW5zLXNlcmlmIj48dT4mbHQ7ZGltZS1ib3VuY2VzQGlldGYub3JnJmd0OzwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9udD4NCjxociBub3NoYWRlPjxmb250IHNp emU9Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0i Q2FsaWJyaSI+PGJyPg0KSm91bmksIEknbSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgT0sgd2l0aCB0 aGUgY29uY2x1c2lvbiBnaXZlbiBoZXJlIHRvbywNCnJpZ2h0PyA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGNvbG9yPSMwMDQwODAgZmFjZT0iV2luZ2RpbmdzIj5KPC9mb250Pjxmb250IHNpemU9MiBjb2xv cj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPg0KPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5i c3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkRlIDo8L2I+IERp TUUgWzwvZm9udD48YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBz aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0 Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj5EZSBs YSBwYXJ0IGRlPC9iPiBNYXJpYSBDcnV6IEJhcnRvbG9tZTxiPjxicj4NCkVudm95w6kgOjwvYj4g bWVyY3JlZGkgMjYgZsOpdnJpZXIgMjAxNCAxMzo1NjxiPjxicj4NCsOAIDo8L2I+IDwvZm9udD48 YSBocmVmPW1haWx0bzpkaW1lQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 IlRhaG9tYSI+PHU+ZGltZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNl PSJUYWhvbWEiPjxiPjxicj4NCk9iamV0IDo8L2I+IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5n IG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMNCmhpc3RvcnkgLSBjb25jbHVzaW9u PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQpGaW5lPC9mb250Pjxmb250IHNp emU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxi cj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj48Yj48YnI+DQpGcm9tOjwvYj4gRGlNRSBbPC9mb250PjxhIGhyZWY9Im1haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9t YSI+PHU+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNp emU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VFJPVFRJTiwgSkVBTi1K QUNRVUVTIChKRUFOLUpBQ1FVRVMpPGI+PGJyPg0KU2VudDo8L2I+IG1pw6lyY29sZXMsIDI2IGRl IGZlYnJlcm8gZGUgMjAxNCA4OjQzPGI+PGJyPg0KVG86PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWls dG86ZGltZUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1 PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48 Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRl ZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cw0KaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+PGZv bnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJy Pg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0j MDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCkhpPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNl PSJDYWxpYnJpIj48YnI+DQpSZW1vdmUg4oCcZnJvbSBub3cgb27igJ0gaXMgYWNjZXB0YWJsZSBm b3IgbWUsIGJ1dCAmbmJzcDtJIGhhdmUgYSBwcmVmZXJlbmNlDQpmb3IgdGhlIHJldmVyc2Ugd29y ZGluZyBMaW9uZWwgcHJvcG9zZXMsIHdoaWNoIGlzIHNob3J0ZXIgYW5kIGJyaW5ncyB0aGUNCmNs YXJpZmljYXRpb24gSSB3YXMgbG9va2luZyBmb3IsOjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkZvciBleGFtcGxlIGlmIGFu IE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDxicj4NCiAxMCBoYXMgYmVlbiByZWNl aXZlZCwgdGhlIHJlYWN0aW5nIG5vZGUgd2hpY2ggPGJyPg0KIHdvdWxkIG5vcm1hbGx5IHNlbmQg MTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgPGJyPg0KIHBhY2tldHMgdG8gdGhlIHJlcG9y dGluZyBub2RlLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgY29sb3I9 IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KIDwv Zm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgw IGZhY2U9IkNhbGlicmkiPjxicj4NCkJlc3QgcmVnYXJkcyA8YnI+DQogPC9mb250Pjxmb250IHNp emU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJy aSI+PGJyPg0KSkphY3F1ZXMgPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250 Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPjxicj4NCiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48 YnI+DQpEZSA6PC9iPiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0Bp ZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5tYWlsdG86 ZGltZS1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRh aG9tYSI+XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gU3RldmUgRG9ub3ZhbjxiPjxicj4NCkVudm95 w6kgOjwvYj4gbHVuZGkgMjQgZsOpdnJpZXIgMjAxNCAxNzowMDxiPjxicj4NCsOAIDo8L2I+IDwv Zm9udD48YSBocmVmPW1haWx0bzpkaW1lQGlldGYub3JnPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IlRhaG9tYSI+PHU+ZGltZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9 MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCk9iamV0IDo8L2I+IFJlOiBbRGltZV0gIzUyOiBUaHJv dHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMNCmhpc3RvcnkgLSBjb25j bHVzaW9uPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpJJ20gd2l0aCBMaW9uZWwuICZu YnNwO0kgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIHByb3Bvc2VkIHdvcmRpbmcgaXMgY29uZnVz aW5nLg0KJm5ic3A7UmVhY3Rpbmcgbm9kZXMgYWx3YXlzIG9ubHkgYXBwbHkgdGhlIHJlZHVjdGlv biBwZXJjZW50YWdlIGZvciB0aGUNCnBlcmlvZCBvZiB0aW1lIHRoYXQgdGhlIHNwZWNpZmljIG92 ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUuICZuYnNwO1RoYXQNCnBlcmlvZCBlaXRoZXIgZW5kcyB3 aGVuIGEgbmV3IG92ZXJsb2FkIHJlcG9ydCBpcyByZWNlaXZlZCBvciB3aGVuIHRoZSBvdmVybG9h ZA0KcmVwb3J0IGV4cGlyZXMuPGJyPg0KPGJyPg0KVGhhdCBzYWlkLCBJJ20gaGFwcHkgd2l0aCBq dXN0IHJlbW92aW5nIHRoZSB3b3JkcyAmcXVvdDtmcm9tIG5vIG9uJnF1b3Q7DQphcyBwcm9wb3Nl ZCBieSBMaW9uZWwgYmVsb3cuPGJyPg0KPGJyPg0KU3RldmU8L2ZvbnQ+PGZvbnQgc2l6ZT0zPjxi cj4NCjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQpPbiAy LzI0LzE0IDc6MjYgQU0sIDwvZm9udD48YSBocmVmPW1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5n ZS5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5s aW9uZWwubW9yYW5kQG9yYW5nZS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4NCndyb3RlOjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkkgZG9uJ3Qgc2VlIHRoZSBpc3N1ZSwg YXMgZXhwbGFpbmVkIGluIG15IG1haWwgYnV0IE9LIHRvIHJlbW92ZSBpdC4gPGJyPg0KIDwvZm9u dD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KSWYgJnF1b3Q7Zm9yIG5vdyZxdW90OyBpcyByZW1vdmVkLCB0aGUgcmVzdWx0aW5n IHRleHQgd291bGQgYmU6PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDtGb3IgZXhhbXBs ZSBpZiB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBzZW5kaW5nPC9mb250Pjxmb250IHNpemU9 Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsx MDAgcGFja2V0cyBwZXIgc2Vjb25kIHRvIHRoZSByZXBvcnRpbmcgbm9kZSwgdGhlbjwvZm9udD48 Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQogJm5ic3A7YSByZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2Yg MTA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PGJyPg0KICZuYnNwO3dvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rp bmcgbm9kZSBNVVNUPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDtvbmx5IHNlbmQgOTAgcGFja2V0cyBwZXIgc2Vj b25kLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk1heWJlIGl0IHdvdWxkIGJlIGV2ZW4gZWFzaWVy IHRvIHJldmVyc2UgdGhlIHNlbnRlbmNlIGFzIGZvbGxvdzo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0K PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KIEZvciBleGFtcGxlIGlmIGFuIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDxi cj4NCiAxMCBoYXMgYmVlbiByZWNlaXZlZCwgdGhlIHJlYWN0aW5nIG5vZGUgd2hpY2ggPGJyPg0K IHdvdWxkIG5vcm1hbGx5IHNlbmQgMTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgPGJyPg0K IHBhY2tldHMgdG8gdGhlIHJlcG9ydGluZyBub2RlLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCkJ1dCBJJ20gZmluZSBpZiB0aGUgaW5pdGlhbCBwcm9wb3NlZCByZXZpc2Vk IHRleHQgaXMga2VwdC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KTGlvbmVsPC9mb250Pjxmb250 IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwv Zm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PGJyPg0KRGUgOiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNl c0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1 Pm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPl0NCkRlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48YnI+DQpFbnZvecOpIDogbHVuZGkgMjQgZsOpdnJpZXIgMjAxNCAxNDoxMzwvZm9udD48Zm9u dCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCsOA IDogPC9mb250PjxhIGhyZWY9bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFz ZWQgb24gcHJldmlvdXMgaGlzdG9yeQ0KLSBjb25jbHVzaW9uPC9mb250Pjxmb250IHNpemU9Mz4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KSGVsbG8sPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSSBhZ3JlZSB3aXRoIFVscmljaCdzIHBy b3Bvc2FsPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KQ2hlZXJzPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KL01DcnV6PC9mb250Pjxmb250IHNpemU9Mz4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KRnJvbTogRGlNRSBbPC9mb250PjxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v cmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5tYWlsdG86 ZGltZS1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij5dDQpPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNo KTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxicj4NClNlbnQ6IGx1bmVzLCAyNCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDY8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+ DQpUbzogZXh0IFRST1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKTsgPC9mb250Pjxh IGhyZWY9bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0i Q291cmllciBOZXciPjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpTdWJqZWN0OiBS ZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZp b3VzDQpoaXN0b3J5IC0gY29uY2x1c2lvbjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkkgc2hhcmUg SkphY3F1ZXMgY29uY2Vybi4gUmVwbGFjaW5nICZxdW90O2Zyb20gbm93IG9uJnF1b3Q7IHdpdGgg JnF1b3Q7Zm9yDQp0aGUgcGVyaW9kIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUm cXVvdDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KaXMgbWlzbGVhZGluZy4gTWF5IGJlIGl0cyBiZXR0ZXIgdG8gc2ltcGx5 IHJlbW92ZSAmcXVvdDtmcm9tIG5vdyBvbiZxdW90Oy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBz aXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K VWxyaWNoPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7 PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KRnJvbTogRGlNRSBbPC9mb250PjxhIGhy ZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVl IGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5dDQpPbiBCZWhhbGYgT2Yg ZXh0IFRST1RUSU4sIEpFQU4tSkFDUVVFUyAoSkVBTi1KQUNRVUVTKTwvZm9udD48Zm9udCBzaXpl PTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpTZW50OiBG cmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDE0IDc6MTEgUE08L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpUbzogPC9mb250PjxhIGhy ZWY9bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291 cmllciBOZXciPjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTM+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpTdWJqZWN0OiBSZTog W0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3Vz DQpoaXN0b3J5IC0gY29uY2x1c2lvbjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNw OzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkhpIE1DcnV6LCBT dGV2ZTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkkgYWxzbyBhZ3JlZSBvbiB0aGUgJnF1b3Q7d291 bGQgc2VuZCAmcXVvdDsgaW5zdGVhZCBvZiB0aGUgJnF1b3Q7d291bGQNCmhhdmUgc2VudCZxdW90 OyAmbmJzcDtmb3Igc3VyZS4gJm5ic3A7QnV0IEkgaGF2ZSAmbmJzcDthIHNtYWxsIGNvbmNlcm4v DQpjbGFyaWZpY2F0aW9uICZuYnNwO2Fib3V0IHRoZSBTdGV2ZSBjb21tZW50IG9uICZuYnNwOyAm cXVvdDtmb3IgdGhlIHBlcmlvZA0KdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSZx dW90OyBhbmQgdGhlIGV4YW1wbGUgdG8gd2hpY2ggaXQgcmVmZXJzLjwvZm9udD48Zm9udCBzaXpl PTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250 Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48YnI+DQpEdXJpbmcgdGhlIHRpbWUgdGhlIE9MUiBpcyBhY3RpdmUsIHdoaWNoIG1heSBiZSBy YXRoZXIgbG9uZywgJm5ic3A7dGhlDQp0cmFmZmljIHRoZSByZWFjdGluZyBub2RlIHdvdWxkIHNl bmQgbWF5IGJlIDEwMCBwYWNrZXQgJm5ic3A7d2hlbiBpdCBoYXMNCmp1c3QgcmVjZWl2ZWQgdGhl IE9MUi4gQSBiaXQgbGF0ZXIsIHRoZSB0cmFmZmljIGl0IHdvdWxkIHNlbmQgY291bGQgYmUNCjEy MCAob3IgODApLCBhbmQgZnJvbSB0aGUgT0xSIGRlZmluaXRpb24sICZuYnNwOyBpdCB3b3VsZCBz ZW5kIDEyMHgwLDkNCihvciA4MCogMCw5KSBwYWNrZXRzLCBvbiAmbmJzcDt3aGljaCBJIGFncmVl LiBUaGlzIGlzIGluIGxpbmUgJm5ic3A7d2l0aA0KdGhlIGV2ZXJ5IDEwdGggcGFja2V0IGRyb3Bw aW5nICZuYnNwO29uIHdoaWNoIEkgYWxzbyBhZ3JlZS4gPGJyPg0KICZuYnNwOzxicj4NCkFzIHRo ZSB0ZXh0ICZuYnNwOyB3b3VsZCAmbmJzcDtiZSB3cml0dGVuIHdpdGggdGhlIFN0ZXZlIG1vZGlm aWNhdGlvbiAsDQp3ZSBtYXkgdW5kZXJzdGFuZCBpdCBpcyAmbmJzcDs4MCBQYWNrZXQgZHVyaW5n IGFsbCB0aGUgdGltZSAmbmJzcDt0aGUgT0xSDQppcyBhY3RpdmUuIE5vdCB5ZXQgdGhpbmsgdG8g YW4gYWx0ZXJuYXRpdmUgdGV4dCwgYnV0IGZpcnN0IHRvIHNlZSBpZiB5b3UNCmFncmVlIHdpdGgg bXkgcmVtYXJrLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkpKYWNxdWVzIDxicj4NCiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCkRlIDogRGlNRSBbPC9mb250PjxhIGhyZWY9Im1haWx0bzpk aW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJp ZXIgTmV3Ij48dT5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5dDQpEZSBsYSBwYXJ0IGRlIDwvZm9udD48YSBo cmVmPW1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+PGZvbnQgc2l6ZT0yIGNvbG9yPWJs dWUgZmFjZT0iQ291cmllciBOZXciPjx1Pmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTwvdT48L2Zv bnQ+PC9hPjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxicj4NCkVudm95w6kgOiB2ZW5kcmVkaSAyMSBmw6l2cmllciAyMDE0IDE4OjMzPC9mb250 Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0Kw4AgOiBTdGV2ZSBEb25vdmFuOyA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGltZUBpZXRmLm9y Zz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ZGltZUBpZXRm Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcg bm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5DQotIGNvbmNsdXNpb248 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48YnI+DQorMSAoaW5jbHVkaW5nIFN0ZXZlIGNvbW1lbnQpPC9mb250 Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KRGUgOiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBO ZXciPjx1Pm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPl0NCkRlIGxhIHBhcnQgZGUgU3RldmUgRG9ub3Zhbjwv Zm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pjxicj4NCkVudm95w6kgOiB2ZW5kcmVkaSAyMSBmw6l2cmllciAyMDE0IDE2OjM3PC9mb250Pjxm b250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K w4AgOiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGltZUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29s b3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ZGltZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9h Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi cj4NCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBi YXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5DQotIGNvbmNsdXNpb248L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxm b250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQpNYXJpYSBDcnV6LDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkkgc3VwcG9ydCB5b3VyIHN1 Z2dlc3RlZCBjaGFuZ2VzLiAmbmJzcDtJIGhhdmUgb25lIGZ1cnRoZXIgc3VnZ2VzdGVkIGNoYW5n ZQ0KYmVsb3cuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KU3RldmU8L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpPbiAyLzIxLzE0 IDI6NDAgQU0sIE1hcmlhIENydXogQmFydG9sb21lIHdyb3RlOjwvZm9udD48Zm9udCBzaXplPTM+ IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiM1MjogVGhyb3R0 bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3Rvcnk8L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K IDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KRm9sbG93aW5nIGFncmVlbWVudCBpcyByZWFjaGVkOjwvZm9udD48Zm9u dCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiBOb3cgKGNoYXB0ZXIgNC43KTo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogJm5ic3A7ICZuYnNwO1Ro ZSBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSBBVlAgKEFWUCBjb2RlIFRCRDgpIGlzIHR5cGUgb2YN ClVuc2lnbmVkMzI8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48YnI+DQogJm5ic3A7ICZuYnNwO2FuZCBkZXNjcmliZXMgdGhlIHBlcmNl bnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyDQppczwvZm9udD48Zm9udCBzaXpl PTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsg Jm5ic3A7cmVxdWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2Ug d291bGQNCmhhdmUgc2VudC48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogUHJvcG9zYWw6PC9mb250 Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KICZuYnNwOyBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgQVZQIChBVlAgY29kZSBUQkQ4 KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzINCiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsgYW5kIGRlc2Ny aWJlcyB0aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMNCiZu YnNwOzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiAmbmJzcDsgcmVxdWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8gd2hh dCBpdCBvdGhlcndpc2Ugd291bGQgc2VuZC4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0Oy0tLS08L2ZvbnQ+PGZvbnQgc2l6 ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9u dD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIE5vdyAoY2hhcHRlciA1LjUuMik6PC9mb250Pjxmb250 IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7SW5kaWNhdGVzIHRoYXQgdGhlIHJlcG9ydGluZyBub2RlIHVyZ2Vz IHRoZSByZWFjdGluZw0Kbm9kZSB0bzwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlZHVj ZSBpdHMgdHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2UuICZuYnNwO0Zvcg0KZXhhbXBsZSBp ZiB0aGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij48YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWFjdGluZyBub2RlIGhhcyBiZWVu IHNlbmRpbmcgMTAwIHBhY2tldHMgcGVyIHNlY29uZA0KdG8gdGhlPC9mb250Pjxmb250IHNpemU9 Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyAm bmJzcDsgJm5ic3A7cmVwb3J0aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRpb24gb2YgT0MtUmVkdWN0 aW9uLVBlcmNlbnRhZ2UNCnZhbHVlPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7b2YgMTAg d291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlDQpNVVNUIG9ubHkg c2VuZDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOzkwIHBhY2tldHMgcGVyIHNlY29uZC4g Jm5ic3A7SG93IHRoZSByZWFjdGluZyBub2RlDQphY2hpZXZlcyB0aGUgJnF1b3Q7dHJ1ZTwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi cj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO3JlZHVjdGlvbiZxdW90OyB0cmFuc2FjdGlvbnMgbGVh ZGluZyB0byB0aGUgc2VudCByZXF1ZXN0DQptZXNzYWdlcyBpcyB1cDwvZm9udD48Zm9udCBzaXpl PTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwO3RvIHRoZSBpbXBsZW1lbnRhdGlvbi4gJm5ic3A7VGhlIHJlYWN0aW5nIG5v ZGUgTUFZDQpzaW1wbHkgZHJvcCBldmVyeTwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOzEw dGggcGFja2V0IGZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljDQphcHBs aWNhdGlvbjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvZ2ljIHRyeSB0byByZWNvdmVy IGZyb20gaXQuMCAmbHQ7IHZhbHVlICZsdDsgMTAwPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAm bmJzcDtQcm9wb3NhbDo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogSW5kaWNhdGVzIHRoYXQgdGhlIHJlcG9ydGluZyBub2Rl IHVyZ2VzIHRoZSByZWFjdGluZyBub2RlIHRvIHJlZHVjZSA8YnI+DQogaXRzIHRyYWZmaWMgYnkg YSBnaXZlbiBwZXJjZW50YWdlLiBGb3IgZXhhbXBsZSBpZiB0aGU8L2ZvbnQ+PGZvbnQgc2l6ZT0z Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIHJlYWN0aW5n IG5vZGUgd291bGQgc2VuZCAxMDAgcGFja2V0cyB0byB0aGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyZsdDstLS08L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIHJlcG9ydGluZyBub2RlLCB0aGVuIGEgcmVj ZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDxicj4NCiAxMCB3b3Vs ZCBtZWFuIHRoYXQgZnJvbSBub3cgb24gdGhlIHJlYWN0aW5nIG5vZGUgTVVTVCBvbmx5IHNlbmQ8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KIDkwIHBhY2tldHMgaW5zdGVhZCBvZiAxMDAuIEhvdyB0aGUgcmVhY3Rpbmcgbm9k ZSBhY2hpZXZlcyB0aGUgJnF1b3Q7dHJ1ZQ0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0Oy0tLTwv Zm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pjxicj4NCiByZWR1Y3Rpb24mcXVvdDsgdHJhbnNhY3Rpb25zIGxlYWRpbmcgdG8gdGhlIHNlbnQg cmVxdWVzdCBtZXNzYWdlcyBpcyB1cA0KdG8gPGJyPg0KIHRoZSBpbXBsZW1lbnRhdGlvbi4gVGhl IHJlYWN0aW5nIG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5IDEwdGggPGJyPg0KIHBhY2tldCBm cm9tIGl0cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlvbiBsb2dp YyB0cnkNCjxicj4NCiB0byByZWNvdmVyIGZyb20gaXQuPC9mb250Pjxmb250IHNpemU9Mz4gPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KU1JEJmd0OyBSZXBsYWNl ICZxdW90O2Zyb20gbm93IG9uJnF1b3Q7IGluIHRoZSBhYm92ZSB3aXRoICZxdW90O2ZvciB0aGUN CnBlcmlvZCB0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlJnF1b3Q7PC9mb250Pjxm b250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K IDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7 PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9u dCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJy Pg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5i c3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+PGZvbnQgc2l6ZT0z PiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpEaU1FIG1haWxp bmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOkRpTUVAaWV0Zi5vcmc+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PkRpTUVAaWV0Zi5vcmc8L3U+ PC9mb250PjwvYT48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+ PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGltZT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+ PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD48Zm9udCBz aXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9m b250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48YnI+DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzDQpvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleg0KcmVjdSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzDQpl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9mb250Pjxmb250 IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUNCm91IGZhbHNpZmllLiBNZXJjaS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxmb250IHNp emU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZA0KaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuDQpt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KVGhhbmsgeW91LjwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4N CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5i c3A7PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcw0Kb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvZm9u dD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi cj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXoNCnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KZWxlY3Ryb25pcXVlcyBldGFudCBz dXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lDQpvdSBmYWxz aWZpZS4gTWVyY2kuPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCmluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PC9mb250Pjxmb250IHNpemU9Mz4g PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48YnI+DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3Qg bGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbg0KbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLjwvZm9udD48Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxicj4NClRoYW5rIHlvdS48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9 Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZm9udD48Zm9udCBz aXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkRpTUUg bWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xv cj1ibHVlPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86RGlNRUBpZXRmLm9yZz48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+RGlNRUBpZXRmLm9y ZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9kaW1lPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIg TmV3Ij48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L3U+PC9m b250PjwvYT48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTM+Jm5ic3A7 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQo8YnI+DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRl bmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzDQpvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jPGJyPg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleg0KcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzDQplbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPGJyPg0KT3JhbmdlIGRlY2xp bmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9y bWUNCm91IGZhbHNpZmllLiBNZXJjaS48YnI+DQo8YnI+DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+ DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kDQpkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMu PGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4NCm1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48 YnI+DQpUaGFuayB5b3UuPC9mb250Pjx0dD48Zm9udCBzaXplPTI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1FIG1haWxpbmcgbGlz dDwvZm9udD48L3R0Pjx0dD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9m b250PjwvdHQ+PGEgaHJlZj1tYWlsdG86RGlNRUBpZXRmLm9yZz48dHQ+PGZvbnQgc2l6ZT0yIGNv bG9yPWJsdWU+PHU+RGlNRUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC90dD48L2E+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vZGltZT48dHQ+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHU+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC91PjwvZm9udD48L3R0 PjwvYT48Zm9udCBzaXplPTM+PGJyPg0KPGJyPg0KPGJyPg0KPC9mb250Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTM+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4NCjwvZm9udD48L3R0PjxhIGhyZWY9bWFpbHRvOkRp TUVAaWV0Zi5vcmc+PHR0Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PkRpTUVAaWV0Zi5vcmc8 L3U+PC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTM+PGJyPg0KPC9mb250PjwvdHQ+PGEg aHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU+PHR0Pjxmb250 IHNpemU9MyBjb2xvcj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGltZTwvdT48L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KRGlNRSBtYWlsaW5nIGxpc3Q8YnI+DQpEaU1FQGlldGYu b3JnPGJyPg0KPC9mb250PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RpbWU+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RpbWU8L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQo8 L2ZvbnQ+PC90dD4NCjxicj4NCg== --=_alternative 006E9AEA85257C90_=-- From nobody Mon Mar 3 15:03:51 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4B41A0269; Mon, 3 Mar 2014 15:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFWSzd_yraki; Mon, 3 Mar 2014 15:03:41 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2F31A01D6; Mon, 3 Mar 2014 15:03:39 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-39-53150a489fbd Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6B.5B.10875.84A05135; Tue, 4 Mar 2014 00:03:36 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.02.0387.000; Tue, 4 Mar 2014 00:03:35 +0100 From: Maria Cruz Bartolome To: Janet P Gunn , Steve Donovan Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion Thread-Index: Ac8u4I7lZ6EisnBRQGeKN2pRy2ep6wAMcrsAAAQQ/wAAArURAACD12qAAAlPFjD///MvAIAAKsaA//1WeSD/+lRuMIATinWW///7SgAAAqNpAP//wbww Date: Mon, 3 Mar 2014 23:03:35 +0000 Message-ID: <087A34937E64E74E848732CFF8354B920978871D@ESESSMB101.ericsson.se> References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4326@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097848DB@ESESSMB101.ericsson.se> <421_1393248389_530B4885_421_10731_1_6B7134B31289DC4FAF731D844122B36E4BB770@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6C65.8080707@usdonovans.com> <087A34937E64E74E848732CFF8354B92097867F4@ESESSMB101.ericsson.se> <22770_1393595933_5310961D_22770_13149_1_6B7134B31289DC4FAF731D844122B36E4CF58D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5314CF70.5000704@usdonovans.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920978871DESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyM+Jvja4Hl2iwwZvHshZHpwRYzO1dwWZx 7uEXVosNTTwOLB4Xr0d5LFnyk8lj1ds+1gDmKC6blNSczLLUIn27BK6Mq6/amAs23WKtWL3n JHMD44HjrF2MnBwSAiYSrYsPs0DYYhIX7q1n62Lk4hASOMQocerFDHYIZxGjxO2FO5lAqtgE 7CQunX4BZosIeEssn/IEqJuDg1nAUaL/rRZIWFggVmLzpQ5WiJI4iabTLawgc0QEmhglbi57 yw6SYBFQkVhw6TcjSC+vgK/Erm5hiF072CTOL/gKNp9TIEDi88udYIMYga77fmoNWJxZQFzi 1pP5TBBXC0gs2XOeGcIWlXj5+B/UZ0oSjUuesELU50s8mjgfzOYVEJQ4OfMJywRG0VlIRs1C UjYLSdkssNc0Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRvbcxMyc9HLDTYzAeDu45bfu DsZT50QOMUpzsCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgTH2xM615SHt/LKC 9lX35zEzPfhQ0uwYa6GxSM63szvqxM6H37InvFj7S3d1FdfpT8/P1jsHfjErXXFr/lnzy/V2 rmarZru1P8v4tXsRp3butOK0/zUWPLEaQbYHZqfGd3NF1BXmnX/sIH/ItGjXxpNcQYY7X2jX veNSXc/tsC+5ZN0RWcesa0osxRmJhlrMRcWJAK4POHWFAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5JhK88WEALSKcb_lJKQOgCTLhl8 Cc: DiME , "dime@ietf.org" Subject: Re: [Dime] #52: Throttling not needed to be based on previous history - conclusion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 23:03:48 -0000 --_000_087A34937E64E74E848732CFF8354B920978871DESESSMB101erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gSmFuZXQsIGFsbCwNCg0KVGhlIHByZS1hZ3JlZWQgcHJvcG9zYWwgaXMgdGhlIGZvbGxv d2luZzoNCg0KTm93IChjaGFwdGVyIDQuNyk6DQogICBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRh Z2UgQVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzINCiAgIGFuZCBkZXNj cmliZXMgdGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzDQog ICByZXF1ZXN0ZWQgdG8gcmVkdWNlLCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3Vs ZCBoYXZlIHNlbnQuDQoNClByb3Bvc2FsOg0KICBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2Ug QVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzINCiAgYW5kIGRlc2NyaWJl cyB0aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMNCiAgcmVx dWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2Ugd291bGQgc2Vu ZC4NCg0KDQoNCk5vdyAoY2hhcHRlciA1LjUuMik6DQoNCiAgICBJbmRpY2F0ZXMgdGhhdCB0aGUg cmVwb3J0aW5nIG5vZGUgdXJnZXMgdGhlIHJlYWN0aW5nIG5vZGUgdG8NCg0KICAgIHJlZHVjZSBp dHMgdHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2UuICBGb3IgZXhhbXBsZSBpZiB0aGUNCg0K ICAgIHJlYWN0aW5nIG5vZGUgaGFzIGJlZW4gc2VuZGluZyAxMDAgcGFja2V0cyBwZXIgc2Vjb25k IHRvIHRoZQ0KDQogICAgcmVwb3J0aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRpb24gb2YgT0MtUmVk dWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUNCg0KICAgIG9mIDEwIHdvdWxkIG1lYW4gdGhhdCBmcm9t IG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIG9ubHkgc2VuZA0KDQogICAgOTAgcGFja2V0 cyBwZXIgc2Vjb25kLiAgSG93IHRoZSByZWFjdGluZyBub2RlIGFjaGlldmVzIHRoZSAidHJ1ZQ0K DQogICAgcmVkdWN0aW9uIiB0cmFuc2FjdGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0 IG1lc3NhZ2VzIGlzIHVwDQoNCiAgICB0byB0aGUgaW1wbGVtZW50YXRpb24uICBUaGUgcmVhY3Rp bmcgbm9kZSBNQVkgc2ltcGx5IGRyb3AgZXZlcnkNCg0KICAgIDEwdGggcGFja2V0IGZyb20gaXRz IG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9uDQoNCiAgICBsb2dp YyB0cnkgdG8gcmVjb3ZlciBmcm9tIGl0Lg0KDQoNClByb3Bvc2FsOg0KDQogICAgSW5kaWNhdGVz IHRoYXQgdGhlIHJlcG9ydGluZyBub2RlIHVyZ2VzIHRoZSByZWFjdGluZyBub2RlIHRvDQoNCiAg ICByZWR1Y2UgaXRzIHRyYWZmaWMgYnkgYSBnaXZlbiBwZXJjZW50YWdlLiBGb3IgZXhhbXBsZSBp ZiBhbg0KDQogICAgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgIDEwIGhhcyBiZWVu IHJlY2VpdmVkLA0KDQogICAgdGhlIHJlYWN0aW5nIG5vZGUgd2hpY2ggIHdvdWxkIG5vcm1hbGx5 IHNlbmQgMTAwIHJlcXVlc3RzDQoNCiAgICBNVVNUIG9ubHkgc2VuZCA5MCByZXF1ZXN0cyB0byB0 aGUgcmVwb3J0aW5nIG5vZGUuDQoNCiAgICBIb3cgdGhlIHJlYWN0aW5nIG5vZGUgYWNoaWV2ZXMg dGhlICJ0cnVlDQoNCiAgICByZWR1Y3Rpb24iIHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRoZSBz ZW50IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXANCg0KICAgIHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4g VGhlIHJlYWN0aW5nIG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5IDEwdGgNCg0KICAgcmVxdWVz dCBmcm9tIGl0cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlvbiBs b2dpYw0KDQogICB0cnkgdG8gcmVjb3ZlciBmcm9tIGl0Lg0KDQoNCkxldCBtZSBrbm93IGlmIHRo aXMgdGV4dCBjb3ZlcnMgeW91ciBjb25jZXJucy4NCkkgdG9vayBwcm9maXQgdG8gcmVwbGFjZSBw YWNrZXQgYnkgcmVxdWVzdC4NCg0KQmVzdCByZWdhcmRzDQovTUNydXoNCg0KRnJvbTogRGlNRSBb bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbmV0IFAgR3Vubg0K U2VudDogbHVuZXMsIDAzIGRlIG1hcnpvIGRlIDIwMTQgMjE6MDgNClRvOiBTdGV2ZSBEb25vdmFu DQpDYzogRGlNRTsgZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90 dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1 c2lvbg0KDQpPSywgSSBhZG1pdCB0byBiZWluZyBjb25mdXNlZC4NCg0KSW5kZXBlbmRlbnQgb2Yg dGhlIHBhY2tldHMgdnMgcmVxdWVzdHMgZGlzdGluY3Rpb24tDQoNCkFzc3VtaW5nIGEgbm9kZSBy ZWNlaXZlcyBhIG1lc3NhZ2UgcmVxdWlyaW5nIDEwJSByZWR1Y3Rpb24sIGRvZXMgdGhpcyBtZWFu DQoNCkEgLSBUaGUgbm9kZSB3aWxsIGRyb3Agb25lIG91dCBvZiBldmVyeSAxMCByZXF1ZXN0cyBp dCAid2FudHMiIHRvIHNlbmQgLCB3aGV0aGVyIGl0ICJ3YW50cyIgdG8gc2VuZCAxMCByZXF1ZXN0 cyBvciAxMDAwIHJlcXVlc3RzIHBlciB1bml0IHRpbWUuDQoNCm9yDQoNCkItIElmIGl0ICJub3Jt YWxseSIgc2VuZHMgMTAwIG1lc3NhZ2VzIHBlciB1bml0IHRpbWUsIGl0IHdpbGwgcmVzdHJpY3Qg aXRzZWxmIHRvIDkwIG1lc3NhZ2VzIHBlciB1bml0IHRpbWUsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhl ciBpdCAid2FudHMiIHRvIHNlbmQgMTAgb3IgMTAwMA0KPw0KDQoiQSIgbWFrZXMgbW9yZSBzZW5z ZSB0byBtZSwgYnV0IHRoZSBwcm9wb3NlZCB0ZXh0IChyZXBlYXRlZCBiZWxvdykgc2VlbXMgdG8g aW1wbHkgIkIiICg5MCBwYWNrZXRzIHBlciBzZWNvbmQgYmFzZWQgb24gd2hhdCBpdCAiaGFzIGJl ZW4gc2VuZGluZyIgb3IgIndvdWxkIG5vcm1hbGx5IHNlbmQiIGluZGVwZW5kZW50IG9mIHRoZSBu dW1iZXIgdGhlIG5vZGUgIndhbnRzIiB0byBzZW5kIikuDQoNCklmICJBIiBpcyBpbnRlbmRlZCwg SSBzdWdnZXN0IHJld29yZGluZyB0aGUgdGV4dCB0byBtYWtlIGl0IGNsZWFyZXINCg0KPHF1b3Rl ZCBmcm9tIGJlbG93Pg0KIEZvciBleGFtcGxlIGlmIHRoZSByZWFjdGluZyBub2RlIGhhcyBiZWVu IHNlbmRpbmcNCiAxMDAgcGFja2V0cyBwZXIgc2Vjb25kIHRvIHRoZSByZXBvcnRpbmcgbm9kZSwg dGhlbg0KIGEgcmVjZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDEw DQogd291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1QNCiBv bmx5IHNlbmQgOTAgcGFja2V0cyBwZXIgc2Vjb25kLg0KDQpNYXliZSBpdCB3b3VsZCBiZSBldmVu IGVhc2llciB0byByZXZlcnNlIHRoZSBzZW50ZW5jZSBhcyBmb2xsb3c6DQoNCkZvciBleGFtcGxl IGlmIGFuIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mDQoxMCBoYXMgYmVlbiByZWNl aXZlZCwgdGhlIHJlYWN0aW5nIG5vZGUgd2hpY2gNCndvdWxkIG5vcm1hbGx5IHNlbmQgMTAwIHBh Y2tldHMgTVVTVCBvbmx5IHNlbmQgOTANCnBhY2tldHMgdG8gdGhlIHJlcG9ydGluZyBub2RlLg0K PC9xdW90ZWQgZnJvbSBiZWxvdz4NCg0KDQpJdCBpcyBwb3NzaWJsZSB0aGF0IHlvdXIgIndvdWxk IG5vcm1hbGx5IHNlbmQiIGlzIHRoZSBzYW1lIGFzIG15ICJ3YW50cyB0byBzZW5kIiwgYnV0IHRo YXQgaXNuJ3QgdGhlIHdheSBpdCByZWFkcywgYXQgbGVhc3QgdG8gbWUuDQoNClRoYW5rcywNCg0K SmFuZXQNCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRs eSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5LiBOT1RFOiBS ZWdhcmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJp bmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8g ZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJl c3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuDQoNCg0K DQpGcm9tOiAgICAgICAgU3RldmUgRG9ub3ZhbiA8c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tPg0K VG86ICAgICAgICBkaW1lQGlldGYub3JnDQpEYXRlOiAgICAgICAgMDMvMDMvMjAxNCAwMTo1MiBQ TQ0KU3ViamVjdDogICAgICAgIFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQg dG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb24NClNlbnQgYnk6ICAg ICAgICAiRGlNRSIgPGRpbWUtYm91bmNlc0BpZXRmLm9yZz4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCg0KDQpKYW5ldCwNCg0KSSdtIG5vdCBzdXJlIHdoeSB3ZSB1c2UgdGhl IHdvcmQgcGFja2V0cy4gIEl0IHNob3VsZCBiZSByZXF1ZXN0cyBpbnN0ZWFkLiAgVGhyb3R0bGlu ZyBkb2VzIG5vdCBpbXBhY3QgcGFja2V0cyBjYXJyeWluZyBhbnN3ZXIgbWVzc2FnZXMsIGZvciBp bnN0YW5jZS4NCg0KV2hhdCBpcyBtZWFudCBpcyB0aGF0IGlmIG5vcm1hbCBoYW5kbGluZyB3b3Vs ZCBoYXZlIHJlc3VsdGVkIGluIDEwMCByZXF1ZXN0IG1lc3NhZ2VzIGJlaW5nIHNlbnQgdGhlbiBh biBvdmVybG9hZCByZXBvcnQgcmVxdWVzdGluZyBhIHJlZHVjdGlvbiBvZiAxMCUgd291bGQgcmVz dWx0IGluIDkwIHJlcXVlc3QgbWVzc2FnZXMgYmVpbmcgc2VudCBhbmQgMTAgcmVxdWVzdCBtZXNz YWdlcyBiZWluZyB0aHJvdHRsZWQuICBUaGUgbG9zcyBhbGdvcml0aG0gaXMgaW50ZW50aW9uYWxs eSBzaW1wbGUgYW5kIHN0YXRlbGVzcy4gIFRoZSBwcm9wb3NlZCBpbXBsZW1lbnRhdGlvbiBiZWlu ZyB0byBkcm9wIDEgaW4gWCBtZXNzYWdlcyB3aGVyZSBYIGlzIGNhbGN1bGF0ZWQgYmFzZWQgb24g dGhlIHJlcXVlc3RlZCBwZXJjZW50YWdlIHJlZHVjdGlvbiByZWNlaXZlZCBpbiB0aGUgb3Zlcmxv YWQgcmVwb3J0LiAgVGhpcyBpcyBtZWFudCB0byBiZSBpbmRlcGVuZGVudCBvZiBhbnkgaHlzdGVy ZXNpcyBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIGFycml2YWwgcmF0ZSBvZiBzZXJ2aWNlIHJlcXVl c3RzLg0KDQpTdGV2ZQ0KDQpPbiAzLzMvMTQgNjowOCBQTSwgSmFuZXQgUCBHdW5uIHdyb3RlOg0K SXQgc2VlbXMgdG8gbWUgdGhpcyBiZWdzIHRoZSBxdWVzdGlvbjoNCldoYXQgZG9lcyAibm9ybWFs bHkgc2VuZHMgMTAwIHBhY2tldHMiIGFjdHVhbGx5IE1FQU4/ICBIb3cgaXMgdGhlIG51bWJlciBv ZiBwYWNrZXRzIGl0ICJub3JtYWxseSBzZW5kcyIgY2FsY3VsYXRlZD8NCg0KSmFuZXQNCg0KVGhp cyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMg YnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5LiBOT1RFOiBSZWdhcmRsZXNzIG9m IGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJpbmQgQ1NDIHRvIGFu eSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3Jp dHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0 aW5nIHRoZSB1c2Ugb2YgZS1tYWlsIGZvciBzdWNoIHB1cnBvc2UuDQoNCg0KDQpGcm9tOiAgICAg ICAgPGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbT48bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jhbmdl LmNvbT4NClRvOiAgICAgICAgSm91bmkgS29yaG9uZW4gPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+ PG1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tPiwgImRpbWVAaWV0Zi5vcmciPG1haWx0bzpk aW1lQGlldGYub3JnPiA8ZGltZUBpZXRmLm9yZz48bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpEYXRl OiAgICAgICAgMDIvMjgvMjAxNCAwODo1OSBBTQ0KU3ViamVjdDogICAgICAgIFJlOiBbRGltZV0g IzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9y eSAtIGNvbmNsdXNpb24NClNlbnQgYnk6ICAgICAgICAiRGlNRSIgPGRpbWUtYm91bmNlc0BpZXRm Lm9yZz48bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZz4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQoNCg0KDQpKb3VuaSwgSSdtIGFzc3VtaW5nIHRoYXQgeW91IGFyZSBPSyB3 aXRoIHRoZSBjb25jbHVzaW9uIGdpdmVuIGhlcmUgdG9vLCByaWdodD8g4pi6DQoNCkRlIDogRGlN RSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6 IEJhcnRvbG9tZQ0KRW52b3nDqSA6IG1lcmNyZWRpIDI2IGbDqXZyaWVyIDIwMTQgMTM6NTYNCsOA IDogZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtEaW1l XSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0 b3J5IC0gY29uY2x1c2lvbg0KDQpGaW5lDQoNCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFD UVVFUykNClNlbnQ6IG1pw6lyY29sZXMsIDI2IGRlIGZlYnJlcm8gZGUgMjAxNCA4OjQzDQpUbzog ZGltZUBpZXRmLm9yZzxtYWlsdG86ZGltZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbRGltZV0g IzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9y eSAtIGNvbmNsdXNpb24NCg0KSGkNCg0KUmVtb3ZlIOKAnGZyb20gbm93IG9u4oCdIGlzIGFjY2Vw dGFibGUgZm9yIG1lLCBidXQgIEkgaGF2ZSBhIHByZWZlcmVuY2UgZm9yIHRoZSByZXZlcnNlIHdv cmRpbmcgTGlvbmVsIHByb3Bvc2VzLCB3aGljaCBpcyBzaG9ydGVyIGFuZCBicmluZ3MgdGhlIGNs YXJpZmljYXRpb24gSSB3YXMgbG9va2luZyBmb3IsOg0KRm9yIGV4YW1wbGUgaWYgYW4gT0MtUmVk dWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YNCjEwIGhhcyBiZWVuIHJlY2VpdmVkLCB0aGUgcmVh Y3Rpbmcgbm9kZSB3aGljaA0Kd291bGQgbm9ybWFsbHkgc2VuZCAxMDAgcGFja2V0cyBNVVNUIG9u bHkgc2VuZCA5MA0KcGFja2V0cyB0byB0aGUgcmVwb3J0aW5nIG5vZGUuDQoNCg0KQmVzdCByZWdh cmRzDQoNCkpKYWNxdWVzDQoNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu b3JnXSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAyNCBmw6l2 cmllciAyMDE0IDE3OjAwDQrDgCA6IGRpbWVAaWV0Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+ DQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFz ZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb24NCg0KSSdtIHdpdGggTGlvbmVsLiAg SSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUgcHJvcG9zZWQgd29yZGluZyBpcyBjb25mdXNpbmcu ICBSZWFjdGluZyBub2RlcyBhbHdheXMgb25seSBhcHBseSB0aGUgcmVkdWN0aW9uIHBlcmNlbnRh Z2UgZm9yIHRoZSBwZXJpb2Qgb2YgdGltZSB0aGF0IHRoZSBzcGVjaWZpYyBvdmVybG9hZCByZXBv cnQgaXMgYWN0aXZlLiAgVGhhdCBwZXJpb2QgZWl0aGVyIGVuZHMgd2hlbiBhIG5ldyBvdmVybG9h ZCByZXBvcnQgaXMgcmVjZWl2ZWQgb3Igd2hlbiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGV4cGlyZXMu DQoNClRoYXQgc2FpZCwgSSdtIGhhcHB5IHdpdGgganVzdCByZW1vdmluZyB0aGUgd29yZHMgImZy b20gbm8gb24iIGFzIHByb3Bvc2VkIGJ5IExpb25lbCBiZWxvdy4NCg0KU3RldmUNCg0KT24gMi8y NC8xNCA3OjI2IEFNLCBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb208bWFpbHRvOmxpb25lbC5tb3Jh bmRAb3JhbmdlLmNvbT4gd3JvdGU6DQpJIGRvbid0IHNlZSB0aGUgaXNzdWUsIGFzIGV4cGxhaW5l ZCBpbiBteSBtYWlsIGJ1dCBPSyB0byByZW1vdmUgaXQuDQoNCklmICJmb3Igbm93IiBpcyByZW1v dmVkLCB0aGUgcmVzdWx0aW5nIHRleHQgd291bGQgYmU6DQoNCiBGb3IgZXhhbXBsZSBpZiB0aGUg cmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBzZW5kaW5nDQogMTAwIHBhY2tldHMgcGVyIHNlY29uZCB0 byB0aGUgcmVwb3J0aW5nIG5vZGUsIHRoZW4NCiBhIHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24t UGVyY2VudGFnZSB2YWx1ZSBvZiAxMA0KIHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUg cmVhY3Rpbmcgbm9kZSBNVVNUDQogb25seSBzZW5kIDkwIHBhY2tldHMgcGVyIHNlY29uZC4NCg0K TWF5YmUgaXQgd291bGQgYmUgZXZlbiBlYXNpZXIgdG8gcmV2ZXJzZSB0aGUgc2VudGVuY2UgYXMg Zm9sbG93Og0KDQpGb3IgZXhhbXBsZSBpZiBhbiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1 ZSBvZg0KMTAgaGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGluZyBub2RlIHdoaWNoDQp3b3Vs ZCBub3JtYWxseSBzZW5kIDEwMCBwYWNrZXRzIE1VU1Qgb25seSBzZW5kIDkwDQpwYWNrZXRzIHRv IHRoZSByZXBvcnRpbmcgbm9kZS4NCg0KDQpCdXQgSSdtIGZpbmUgaWYgdGhlIGluaXRpYWwgcHJv cG9zZWQgcmV2aXNlZCB0ZXh0IGlzIGtlcHQuDQoNCkxpb25lbA0KDQpEZSA6IERpTUUgW21haWx0 bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTWFyaWEgQ3J1eiBCYXJ0b2xv bWUNCkVudm95w6kgOiBsdW5kaSAyNCBmw6l2cmllciAyMDE0IDE0OjEzDQrDgCA6IGRpbWVAaWV0 Zi5vcmc8bWFpbHRvOmRpbWVAaWV0Zi5vcmc+DQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJv dHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNs dXNpb24NCg0KSGVsbG8sDQoNCkkgYWdyZWUgd2l0aCBVbHJpY2gncyBwcm9wb3NhbA0KQ2hlZXJz DQovTUNydXoNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkNClNlbnQ6IGx1bmVzLCAy NCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDYNClRvOiBleHQgVFJPVFRJTiwgSkVBTi1KQUNRVUVT IChKRUFOLUpBQ1FVRVMpOyBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBv biBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbg0KDQpJIHNoYXJlIEpKYWNxdWVzIGNvbmNl cm4uIFJlcGxhY2luZyAiZnJvbSBub3cgb24iIHdpdGggImZvciB0aGUgcGVyaW9kIHRoYXQgdGhl IG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUiDQppcyBtaXNsZWFkaW5nLiBNYXkgYmUgaXRzIGJl dHRlciB0byBzaW1wbHkgcmVtb3ZlICJmcm9tIG5vdyBvbiIuDQoNClVscmljaA0KDQoNCg0KDQoN CkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBl eHQgVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpDQpTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDIxLCAyMDE0IDc6MTEgUE0NClRvOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0 byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbg0KDQpIaSBNQ3J1eiwg U3RldmUNCg0KSSBhbHNvIGFncmVlIG9uIHRoZSAid291bGQgc2VuZCAiIGluc3RlYWQgb2YgdGhl ICJ3b3VsZCBoYXZlIHNlbnQiICBmb3Igc3VyZS4gIEJ1dCBJIGhhdmUgIGEgc21hbGwgY29uY2Vy bi8gY2xhcmlmaWNhdGlvbiAgYWJvdXQgdGhlIFN0ZXZlIGNvbW1lbnQgb24gICAiZm9yIHRoZSBw ZXJpb2QgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZSIgYW5kIHRoZSBleGFtcGxl IHRvIHdoaWNoIGl0IHJlZmVycy4NCg0KRHVyaW5nIHRoZSB0aW1lIHRoZSBPTFIgaXMgYWN0aXZl LCB3aGljaCBtYXkgYmUgcmF0aGVyIGxvbmcsICB0aGUgdHJhZmZpYyB0aGUgcmVhY3Rpbmcgbm9k ZSB3b3VsZCBzZW5kIG1heSBiZSAxMDAgcGFja2V0ICB3aGVuIGl0IGhhcyBqdXN0IHJlY2VpdmVk IHRoZSBPTFIuIEEgYml0IGxhdGVyLCB0aGUgdHJhZmZpYyBpdCB3b3VsZCBzZW5kIGNvdWxkIGJl IDEyMCAob3IgODApLCBhbmQgZnJvbSB0aGUgT0xSIGRlZmluaXRpb24sICAgaXQgd291bGQgc2Vu ZCAxMjB4MCw5IChvciA4MCogMCw5KSBwYWNrZXRzLCBvbiAgd2hpY2ggSSBhZ3JlZS4gVGhpcyBp cyBpbiBsaW5lICB3aXRoIHRoZSBldmVyeSAxMHRoIHBhY2tldCBkcm9wcGluZyAgb24gd2hpY2gg SSBhbHNvIGFncmVlLg0KDQpBcyB0aGUgdGV4dCAgIHdvdWxkICBiZSB3cml0dGVuIHdpdGggdGhl IFN0ZXZlIG1vZGlmaWNhdGlvbiAsIHdlIG1heSB1bmRlcnN0YW5kIGl0IGlzICA4MCBQYWNrZXQg ZHVyaW5nIGFsbCB0aGUgdGltZSAgdGhlIE9MUiBpcyBhY3RpdmUuIE5vdCB5ZXQgdGhpbmsgdG8g YW4gYWx0ZXJuYXRpdmUgdGV4dCwgYnV0IGZpcnN0IHRvIHNlZSBpZiB5b3UgYWdyZWUgd2l0aCBt eSByZW1hcmsuDQoNCkpKYWNxdWVzDQoNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbTxtYWlsdG86 bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPg0KRW52b3nDqSA6IHZlbmRyZWRpIDIxIGbDqXZyaWVy IDIwMTQgMTg6MzMNCsOAIDogU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9yZzxtYWlsdG86ZGlt ZUBpZXRmLm9yZz4NCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRl ZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbg0KDQorMSAoaW5j bHVkaW5nIFN0ZXZlIGNvbW1lbnQpDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0Bp ZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBTdGV2ZSBEb25vdmFuDQpFbnZvecOpIDogdmVuZHJlZGkg MjEgZsOpdnJpZXIgMjAxNCAxNjozNw0Kw4AgOiBkaW1lQGlldGYub3JnPG1haWx0bzpkaW1lQGll dGYub3JnPg0KT2JqZXQgOiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRv IGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uDQoNCk1hcmlhIENydXos DQoNCkkgc3VwcG9ydCB5b3VyIHN1Z2dlc3RlZCBjaGFuZ2VzLiAgSSBoYXZlIG9uZSBmdXJ0aGVy IHN1Z2dlc3RlZCBjaGFuZ2UgYmVsb3cuDQoNClN0ZXZlDQpPbiAyLzIxLzE0IDI6NDAgQU0sIE1h cmlhIENydXogQmFydG9sb21lIHdyb3RlOg0KIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8g YmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeQ0KDQpGb2xsb3dpbmcgYWdyZWVtZW50IGlzIHJl YWNoZWQ6DQoNCk5vdyAoY2hhcHRlciA0LjcpOg0KICAgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50 YWdlIEFWUCAoQVZQIGNvZGUgVEJEOCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyDQogICBhbmQgZGVz Y3JpYmVzIHRoZSBwZXJjZW50YWdlIG9mIHRoZSB0cmFmZmljIHRoYXQgdGhlIHNlbmRlciBpcw0K ICAgcmVxdWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2Ugd291 bGQgaGF2ZSBzZW50Lg0KDQpQcm9wb3NhbDoNCiAgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdl IEFWUCAoQVZQIGNvZGUgVEJEOCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyDQogIGFuZCBkZXNjcmli ZXMgdGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzDQogIHJl cXVlc3RlZCB0byByZWR1Y2UsIGNvbXBhcmVkIHRvIHdoYXQgaXQgb3RoZXJ3aXNlIHdvdWxkIHNl bmQuICAgICAgICAgICAgICAgICAgPC0tLS0NCg0KDQpOb3cgKGNoYXB0ZXIgNS41LjIpOg0KICAg ICBJbmRpY2F0ZXMgdGhhdCB0aGUgcmVwb3J0aW5nIG5vZGUgdXJnZXMgdGhlIHJlYWN0aW5nIG5v ZGUgdG8NCiAgICAgcmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2VudGFnZS4gIEZv ciBleGFtcGxlIGlmIHRoZQ0KICAgICByZWFjdGluZyBub2RlIGhhcyBiZWVuIHNlbmRpbmcgMTAw IHBhY2tldHMgcGVyIHNlY29uZCB0byB0aGUNCiAgICAgcmVwb3J0aW5nIG5vZGUsIHRoZW4gYSBy ZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUNCiAgICAgb2YgMTAgd291 bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1Qgb25seSBzZW5k DQogICAgIDkwIHBhY2tldHMgcGVyIHNlY29uZC4gIEhvdyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hp ZXZlcyB0aGUgInRydWUNCiAgICAgcmVkdWN0aW9uIiB0cmFuc2FjdGlvbnMgbGVhZGluZyB0byB0 aGUgc2VudCByZXF1ZXN0IG1lc3NhZ2VzIGlzIHVwDQogICAgIHRvIHRoZSBpbXBsZW1lbnRhdGlv bi4gIFRoZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeQ0KICAgICAxMHRoIHBh Y2tldCBmcm9tIGl0cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlv bg0KICAgICBsb2dpYyB0cnkgdG8gcmVjb3ZlciBmcm9tIGl0LjAgPCB2YWx1ZSA8IDEwMA0KDQog UHJvcG9zYWw6DQpJbmRpY2F0ZXMgdGhhdCB0aGUgcmVwb3J0aW5nIG5vZGUgdXJnZXMgdGhlIHJl YWN0aW5nIG5vZGUgdG8gcmVkdWNlDQppdHMgdHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2Uu IEZvciBleGFtcGxlIGlmIHRoZQ0KcmVhY3Rpbmcgbm9kZSB3b3VsZCBzZW5kIDEwMCBwYWNrZXRz IHRvIHRoZSAgICAgICAgICAgICAgICAgICAgICAgICAgPC0tLQ0KcmVwb3J0aW5nIG5vZGUsIHRo ZW4gYSByZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YNCjEwIHdv dWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIG9ubHkgc2Vu ZA0KOTAgcGFja2V0cyBpbnN0ZWFkIG9mIDEwMC4gSG93IHRoZSByZWFjdGluZyBub2RlIGFjaGll dmVzIHRoZSAidHJ1ZSAgICAgICA8LS0tDQpyZWR1Y3Rpb24iIHRyYW5zYWN0aW9ucyBsZWFkaW5n IHRvIHRoZSBzZW50IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXAgdG8NCnRoZSBpbXBsZW1lbnRhdGlv bi4gVGhlIHJlYWN0aW5nIG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5IDEwdGgNCnBhY2tldCBm cm9tIGl0cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlvbiBsb2dp YyB0cnkNCnRvIHJlY292ZXIgZnJvbSBpdC4NClNSRD4gUmVwbGFjZSAiZnJvbSBub3cgb24iIGlu IHRoZSBhYm92ZSB3aXRoICJmb3IgdGhlIHBlcmlvZCB0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQg aXMgYWN0aXZlIg0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmc8bWFpbHRv OkRpTUVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp bWUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0K cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KVGhhbmsgeW91Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVu aXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5l IGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2Fu cyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwg dmV1aWxsZXogbGUgc2lnbmFsZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3Rl ZCBieSBsYXc7DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsgeW91Lg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnPG1h aWx0bzpEaU1FQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaW1lDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmc8bWFpbHRvOkRpTUVAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBs aXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2RpbWUNCg== --_000_087A34937E64E74E848732CFF8354B920978871DESESSMB101erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYu TXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi UGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2Vy aWYiOw0KCWNvbG9yOmJsYWNrO30NCnR0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1s aW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4w cHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8gSmFuZXQsIGFs bCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoZSBwcmUtYWdyZWVkIHByb3Bvc2FsIGlzIHRoZSBmb2xsb3dpbmc6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Tm93IChj aGFwdGVyIDQuNyk6DQo8YnI+DQombmJzcDsgJm5ic3A7VGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50 YWdlIEFWUCAoQVZQIGNvZGUgVEJEOCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyIDxicj4NCiZuYnNw OyAmbmJzcDthbmQgZGVzY3JpYmVzIHRoZSBwZXJjZW50YWdlIG9mIHRoZSB0cmFmZmljIHRoYXQg dGhlIHNlbmRlciBpcyA8YnI+DQombmJzcDsgJm5ic3A7cmVxdWVzdGVkIHRvIHJlZHVjZSwgY29t cGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2UgPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+d291bGQg aGF2ZSBzZW50PC9zcGFuPi4NCjxicj4NCiZuYnNwOzxicj4NClByb3Bvc2FsOiA8YnI+DQombmJz cDsgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIEFWUCAoQVZQIGNvZGUgVEJEOCkgaXMgdHlw ZSBvZiBVbnNpZ25lZDMyICZuYnNwOyA8YnI+DQombmJzcDsgYW5kIGRlc2NyaWJlcyB0aGUgcGVy Y2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMgJm5ic3A7IDxicj4NCiZu YnNwOyByZXF1ZXN0ZWQgdG8gcmVkdWNlLCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSA8 c3BhbiBzdHlsZT0iY29sb3I6cmVkIj53b3VsZCBzZW5kPC9zcGFuPi48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi PiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQo8YnI+DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Ob3cgKGNoYXB0ZXIgNS41LjIpOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEluZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9k ZSB0bzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHJlZHVjZSBpdHMgdHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2UuJm5ic3A7IDxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPg0KRm9yIGV4YW1wbGUgaWYgdGhlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJlYWN0aW5nIG5vZGUgaGFzIGJlZW4gc2VuZGluZyAxMDAgcGFj a2V0cyBwZXIgc2Vjb25kIHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyBy ZXBvcnRpbmcgbm9kZSwgdGhlbiBhIHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFn ZSB2YWx1ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjpyZWQiPiZuYnNwOyZuYnNwOyZuYnNwOyBvZiAxMCB3b3VsZCBtZWFu IHRoYXQgZnJvbSBub3cgb24gdGhlIHJlYWN0aW5nIG5vZGUgTVVTVCBvbmx5IHNlbmQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29s b3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsgOTAgcGFja2V0cyBwZXIgc2Vjb25kPC9zcGFuPi4m bmJzcDsgSG93IHRoZSByZWFjdGluZyBub2RlIGFjaGlldmVzIHRoZSAmcXVvdDt0cnVlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgcmVk dWN0aW9uJnF1b3Q7IHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRoZSBzZW50IHJlcXVlc3QgbWVz c2FnZXMgaXMgdXA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNw OyZuYnNwOyZuYnNwOyB0byB0aGUgaW1wbGVtZW50YXRpb24uJm5ic3A7IFRoZSByZWFjdGluZyBu b2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwdGggcGFja2V0IGZyb20gaXRzIG91dHB1dCBx dWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbG9naWMgdHJ5IHRvIHJlY292 ZXIgZnJvbSBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5Qcm9wb3NhbDo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyAmbmJzcDtJbmRpY2F0ZXMgdGhh dCB0aGUgcmVwb3J0aW5nIG5vZGUgdXJnZXMgdGhlIHJlYWN0aW5nIG5vZGUgdG88bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyAmbmJzcDsmbmJzcDtyZWR1Y2Ug aXRzIHRyYWZmaWMgYnkgYSBnaXZlbiBwZXJjZW50YWdlPHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+ Lg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPkZvciBleGFtcGxlIGlmIGFuIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFs dWUgb2YgJm5ic3A7MTAgaGFzIGJlZW4gcmVjZWl2ZWQsIDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt0aGUgcmVhY3Rpbmcgbm9kZSB3aGljaCAmbmJzcDt3b3VsZCBub3JtYWxs eSBzZW5kIDEwMCA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDcw QzAiPnJlcXVlc3RzIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVk Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7TVVTVCBvbmx5IHNlbmQgOTAg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA3MEMwIj5yZXF1ZXN0 cyA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+dG8gdGhlIHJl cG9ydGluZyBub2RlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IEhvdyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hpZXZlcyB0aGUgJnF1b3Q7dHJ1ZSA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O3JlZHVjdGlvbiZxdW90OyB0cmFuc2FjdGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0 IG1lc3NhZ2VzIGlzIHVwDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3RvIHRoZSBpbXBsZW1lbnRhdGlvbi4gVGhlIHJlYWN0 aW5nIG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5IDEwdGgNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDcwQzAiPnJlcXVlc3QgPC9zcGFuPmZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRo ZSBnZW5lcmljIGFwcGxpY2F0aW9uIGxvZ2ljDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyZuYnNwOyZuYnNwO3RyeSB0byByZWNvdmVyIGZyb20gaXQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5MZXQgbWUga25vdyBpZiB0aGlz IHRleHQgY292ZXJzIHlvdXIgY29uY2VybnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgdG9vayBwcm9maXQgdG8gcmVwbGFjZSBwYWNrZXQgYnkgcmVxdWVzdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJl c3QgcmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4vTUNydXo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IERpTUUgW21haWx0bzpkaW1lLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbmV0IFAgR3Vubjxicj4NCjxiPlNl bnQ6PC9iPiBsdW5lcywgMDMgZGUgbWFyem8gZGUgMjAxNCAyMTowODxicj4NCjxiPlRvOjwvYj4g U3RldmUgRG9ub3Zhbjxicj4NCjxiPkNjOjwvYj4gRGlNRTsgZGltZUBpZXRmLm9yZzxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJl IGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5PSywgSSBhZG1pdCB0byBi ZWluZyBjb25mdXNlZC48L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5JbmRlcGVuZGVudCBvZiB0aGUgcGFja2V0cyB2cyByZXF1ZXN0cyBkaXN0aW5jdGlvbi08 L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Bc3N1bWluZyBh IG5vZGUgcmVjZWl2ZXMgYSBtZXNzYWdlIHJlcXVpcmluZyAxMCUgcmVkdWN0aW9uLCBkb2VzIHRo aXMgbWVhbjwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkEg LSBUaGUgbm9kZSB3aWxsIGRyb3Agb25lIG91dCBvZiBldmVyeSAxMCByZXF1ZXN0cyBpdCAmcXVv dDt3YW50cyZxdW90OyB0byBzZW5kICwgd2hldGhlciBpdCAmcXVvdDt3YW50cyZxdW90OyB0byBz ZW5kIDEwIHJlcXVlc3RzIG9yIDEwMDAgcmVxdWVzdHMgcGVyIHVuaXQgdGltZS48L3NwYW4+DQo8 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5vciA8L3NwYW4+PGJyPg0KPGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Qi0gSWYgaXQgJnF1b3Q7bm9ybWFsbHkmcXVv dDsgc2VuZHMgMTAwIG1lc3NhZ2VzIHBlciB1bml0IHRpbWUsIGl0IHdpbGwgcmVzdHJpY3QgaXRz ZWxmIHRvIDkwIG1lc3NhZ2VzIHBlciB1bml0IHRpbWUsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBp dCAmcXVvdDt3YW50cyZxdW90OyB0byBzZW5kIDEwIG9yIDEwMDA8L3NwYW4+DQo8YnI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4/PC9zcGFuPiA8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mcXVvdDtBJnF1b3Q7IG1ha2VzIG1vcmUgc2Vuc2UgdG8gbWUsIGJ1dCB0 aGUgcHJvcG9zZWQgdGV4dCAocmVwZWF0ZWQgYmVsb3cpIHNlZW1zIHRvIGltcGx5ICZxdW90O0Im cXVvdDsgKDkwIHBhY2tldHMgcGVyIHNlY29uZCBiYXNlZCBvbiB3aGF0IGl0ICZxdW90O2hhcyBi ZWVuIHNlbmRpbmcmcXVvdDsgb3IgJnF1b3Q7d291bGQgbm9ybWFsbHkgc2VuZCZxdW90OyBpbmRl cGVuZGVudCBvZiB0aGUgbnVtYmVyDQogdGhlIG5vZGUgJnF1b3Q7d2FudHMmcXVvdDsgdG8gc2Vu ZCZxdW90OykuPC9zcGFuPiA8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5J ZiAmcXVvdDtBJnF1b3Q7IGlzIGludGVuZGVkLCBJIHN1Z2dlc3QgcmV3b3JkaW5nIHRoZSB0ZXh0 IHRvIG1ha2UgaXQgY2xlYXJlcjwvc3Bhbj4NCjxicj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbHQ7cXVv dGVkIGZyb20gYmVsb3cmZ3Q7PGJyPg0KJm5ic3A7Rm9yIGV4YW1wbGUgaWYgdGhlIHJlYWN0aW5n IG5vZGUgPGI+aGFzIGJlZW4gc2VuZGluZzwvYj48L3NwYW4+PGI+IDwvYj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGJyPg0KJm5ic3A7MTAwIHBhY2tldHMgcGVyIHNlY29uZDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiB0 byB0aGUgcmVwb3J0aW5nIG5vZGUsIHRoZW48L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KJm5ic3A7 YSByZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgMTA8L3NwYW4+ IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4NCjxicj4NCiZuYnNwO3dvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUg cmVhY3Rpbmcgbm9kZSBNVVNUPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQombmJzcDtvbmx5IHNl bmQ8Yj4gOTAgcGFja2V0cyBwZXIgc2Vjb25kPC9iPi48L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4N Cjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KTWF5YmUgaXQgd291bGQgYmUgZXZlbiBlYXNp ZXIgdG8gcmV2ZXJzZSB0aGUgc2VudGVuY2UgYXMgZm9sbG93Ojwvc3Bhbj4gPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0K PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpGb3IgZXhhbXBsZSBpZiBhbiBPQy1S ZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSBvZiA8YnI+DQoxMCBoYXMgYmVlbiByZWNlaXZlZCwg dGhlIHJlYWN0aW5nIG5vZGUgd2hpY2ggPGJyPg0Kd291bGQgbm9ybWFsbHkgc2VuZCAxMDAgcGFj a2V0cyBNVVNUIG9ubHkgc2VuZCA5MCA8YnI+DQpwYWNrZXRzIHRvIHRoZSByZXBvcnRpbmcgbm9k ZS48L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCiZsdDsvcXVvdGVkIGZyb20gYmVsb3cmZ3Q7PC9z cGFuPiA8YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JdCBpcyBw b3NzaWJsZSB0aGF0IHlvdXIgJnF1b3Q7d291bGQgbm9ybWFsbHkgc2VuZCZxdW90OyBpcyB0aGUg c2FtZSBhcyBteSAmcXVvdDt3YW50cyB0byBzZW5kJnF1b3Q7LCBidXQgdGhhdCBpc24ndCB0aGUg d2F5IGl0IHJlYWRzLCBhdCBsZWFzdCB0byBtZS48L3NwYW4+DQo8YnI+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGFua3MsPC9zcGFuPiA8YnI+DQo8YnI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5KYW5ldDxicj4NCjxicj4NClRoaXMgaXMgYSBQUklWQVRFIG1lc3Nh Z2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUg d2l0aG91dCBjb3B5aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlz dGFrZSBpbiBkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlzIGUtbWFp bCBzaGFsbCBub3Qgb3BlcmF0ZSB0byBiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29u dHJhY3QNCiB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbiBhZ3JlZW1lbnQgb3Ig Z292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2YgZS1t YWlsIGZvciBzdWNoIHB1cnBvc2UuPC9zcGFuPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPkZyb206ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0ZXZlIERvbm92 YW4gJmx0O3NyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbSZndDs8L3NwYW4+DQo8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+VG86ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRpbWVAaWV0Zi5vcmc8L3Nw YW4+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+RGF0ZTog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+MDMvMDMvMjAxNCAwMTo1MiBQTTwvc3Bhbj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojNUY1RjVGIj5TdWJqZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SZTogW0RpbWVdICM1MjogVGhyb3R0bGlu ZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9u PC9zcGFuPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPlNl bnQgYnk6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZxdW90O0RpTUUmcXVvdDsgJmx0O2RpbWUtYm91bmNlc0BpZXRmLm9yZyZndDs8 L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAw JSIgbm9zaGFkZT0iIiBzdHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCkphbmV0LDxicj4NCjxi cj4NCkknbSBub3Qgc3VyZSB3aHkgd2UgdXNlIHRoZSB3b3JkIHBhY2tldHMuICZuYnNwO0l0IHNo b3VsZCBiZSByZXF1ZXN0cyBpbnN0ZWFkLiAmbmJzcDtUaHJvdHRsaW5nIGRvZXMgbm90IGltcGFj dCBwYWNrZXRzIGNhcnJ5aW5nIGFuc3dlciBtZXNzYWdlcywgZm9yIGluc3RhbmNlLjxicj4NCjxi cj4NCldoYXQgaXMgbWVhbnQgaXMgdGhhdCBpZiBub3JtYWwgaGFuZGxpbmcgd291bGQgaGF2ZSBy ZXN1bHRlZCBpbiAxMDAgcmVxdWVzdCBtZXNzYWdlcyBiZWluZyBzZW50IHRoZW4gYW4gb3Zlcmxv YWQgcmVwb3J0IHJlcXVlc3RpbmcgYSByZWR1Y3Rpb24gb2YgMTAlIHdvdWxkIHJlc3VsdCBpbiA5 MCByZXF1ZXN0IG1lc3NhZ2VzIGJlaW5nIHNlbnQgYW5kIDEwIHJlcXVlc3QgbWVzc2FnZXMgYmVp bmcgdGhyb3R0bGVkLiAmbmJzcDtUaGUgbG9zcyBhbGdvcml0aG0NCiBpcyBpbnRlbnRpb25hbGx5 IHNpbXBsZSBhbmQgc3RhdGVsZXNzLiAmbmJzcDtUaGUgcHJvcG9zZWQgaW1wbGVtZW50YXRpb24g YmVpbmcgdG8gZHJvcCAxIGluIFggbWVzc2FnZXMgd2hlcmUgWCBpcyBjYWxjdWxhdGVkIGJhc2Vk IG9uIHRoZSByZXF1ZXN0ZWQgcGVyY2VudGFnZSByZWR1Y3Rpb24gcmVjZWl2ZWQgaW4gdGhlIG92 ZXJsb2FkIHJlcG9ydC4gJm5ic3A7VGhpcyBpcyBtZWFudCB0byBiZSBpbmRlcGVuZGVudCBvZiBh bnkgaHlzdGVyZXNpcyBhbmQgaW5kZXBlbmRlbnQNCiBvZiB0aGUgYXJyaXZhbCByYXRlIG9mIHNl cnZpY2UgcmVxdWVzdHMuIDxicj4NCjxicj4NClN0ZXZlPGJyPg0KPGJyPg0KT24gMy8zLzE0IDY6 MDggUE0sIEphbmV0IFAgR3VubiB3cm90ZTogPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+SXQgc2VlbXMgdG8gbWUgdGhpcyBiZWdzIHRoZSBxdWVzdGlvbjo8L3NwYW4+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpXaGF0IGRvZXMgJnF1b3Q7bm9ybWFsbHkgc2VuZHMg MTAwIHBhY2tldHMmcXVvdDsgYWN0dWFsbHkgTUVBTj8gJm5ic3A7SG93IGlzIHRoZSBudW1iZXIg b2YgcGFja2V0cyBpdCAmcXVvdDtub3JtYWxseSBzZW5kcyZxdW90OyBjYWxjdWxhdGVkPzwvc3Bh bj4NCjxicj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCkphbmV0PGJyPg0KPGJy Pg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZp c2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5LiBOT1RFOiBSZWdhcmRs ZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvIGJpbmQgQ1ND IHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdA0KIHVubGVzcyBwdXJzdWFudCB0byBleHBs aWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5 IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS48L3NwYW4+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+ PGJyPg0KRnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jmx0O2xpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSZndDs8L3NwYW4+PC9hPg0KPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM1RjVGNUYiPjxicj4NClRvOiAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Kb3VuaSBLb3Job25lbg0K PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZsdDtqb3VuaS5ub3NwYW1AZ21haWwuY29tJmd0Ozwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4sDQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRpbWVA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JnF1b3Q7ZGltZUBpZXRmLm9yZyZx dW90Ozwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4NCjwvc3Bhbj48YSBocmVm PSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbHQ7ZGlt ZUBpZXRmLm9yZyZndDs8L3NwYW4+PC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM1RjVGNUYiPjxicj4NCkRhdGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjAyLzI4LzIwMTQgMDg6NTkgQU08L3NwYW4+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzVGNUY1RiI+PGJyPg0KU3ViamVjdDogJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UmU6 IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91 cyBoaXN0b3J5IC0gY29uY2x1c2lvbjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojNUY1RjVGIj48YnI+DQpTZW50IGJ5OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mcXVvdDtEaU1FJnF1b3Q7DQo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbHQ7ZGltZS1ib3VuY2VzQGlldGYub3JnJmd0Ozwvc3Bhbj48L2E+DQo8bzpwPjwv bzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRl eHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIzIiB3aWR0aD0iMTAwJSIgbm9zaGFkZT0iIiBz dHlsZT0iY29sb3I6I0EwQTBBMCIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxicj4NCkpvdW5pLCBJJ20gYXNz dW1pbmcgdGhhdCB5b3UgYXJlIE9LIHdpdGggdGhlIGNvbmNsdXNpb24gZ2l2ZW4gaGVyZSB0b28s IHJpZ2h0PyA8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTpXaW5nZGluZ3M7Y29sb3I6IzAwNDA4MCI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzAwNDA4MCI+DQo8YnI+DQo8L3NwYW4+Jm5ic3A7PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPjxicj4NCkRlIDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gRGlNRSBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v cmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu b3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+RGUgbGEgcGFy dCBkZTwvYj4gTWFyaWEgQ3J1eiBCYXJ0b2xvbWU8Yj48YnI+DQpFbnZvecOpIDo8L2I+IG1lcmNy ZWRpIDI2IGbDqXZyaWVyIDIwMTQgMTM6NTY8Yj48YnI+DQrDgCA6PC9iPiA8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kaW1l QGlldGYub3JnPC9zcGFuPjwvYT48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K T2JqZXQgOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBSZTogW0RpbWVd ICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3Rv cnkgLSBjb25jbHVzaW9uPC9zcGFuPg0KPGJyPg0KJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxicj4NCkZpbmU8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj4NCjxicj4NCjwvc3Bhbj4mbmJzcDs8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KRnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gRGlNRSBbPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5tYWlsdG86ZGltZS1ib3VuY2Vz QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5UUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUyk8Yj48YnI+ DQpTZW50OjwvYj4gbWnDqXJjb2xlcywgMjYgZGUgZmVicmVybyBkZSAyMDE0IDg6NDM8Yj48YnI+ DQpUbzo8L2I+IDwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPmRpbWVAaWV0Zi5vcmc8L3NwYW4+PC9hPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQpTdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJl IGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uPC9zcGFuPg0KPGJyPg0KJm5i c3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxicj4NCkhpPC9z cGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzAwNDA4MCI+DQo8YnI+DQo8 L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAiPjxi cj4NClJlbW92ZSDigJxmcm9tIG5vdyBvbuKAnSBpcyBhY2NlcHRhYmxlIGZvciBtZSwgYnV0ICZu YnNwO0kgaGF2ZSBhIHByZWZlcmVuY2UgZm9yIHRoZSByZXZlcnNlIHdvcmRpbmcgTGlvbmVsIHBy b3Bvc2VzLCB3aGljaCBpcyBzaG9ydGVyIGFuZCBicmluZ3MgdGhlIGNsYXJpZmljYXRpb24gSSB3 YXMgbG9va2luZyBmb3IsOjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpGb3IgZXhhbXBsZSBpZiBh biBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSBvZiA8YnI+DQoxMCBoYXMgYmVlbiByZWNl aXZlZCwgdGhlIHJlYWN0aW5nIG5vZGUgd2hpY2ggPGJyPg0Kd291bGQgbm9ybWFsbHkgc2VuZCAx MDAgcGFja2V0cyBNVVNUIG9ubHkgc2VuZCA5MCA8YnI+DQpwYWNrZXRzIHRvIHRoZSByZXBvcnRp bmcgbm9kZS48L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgw Ij4NCjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzAwNDA4MCI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMDA0MDgwIj48YnI+DQpCZXN0IHJlZ2FyZHMgPGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA0MDgwIj48YnI+DQpKSmFjcXVlcyA8YnI+ DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDQwODAi Pjxicj4NCjwvc3Bhbj4mbmJzcDs8Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0K RGUgOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBEaU1FIFs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5dDQo8Yj5EZSBsYSBwYXJ0IGRlPC9iPiBTdGV2ZSBEb25vdmFu PGI+PGJyPg0KRW52b3nDqSA6PC9iPiBsdW5kaSAyNCBmw6l2cmllciAyMDE0IDE3OjAwPGI+PGJy Pg0Kw4AgOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+ZGltZUBpZXRmLm9yZzwvc3Bhbj48L2E+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPjxicj4NCk9iamV0IDo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBi ZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbjwvc3Bhbj4NCjxicj4NCiZu YnNwOzxicj4NCkknbSB3aXRoIExpb25lbC4gJm5ic3A7SSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0 aGUgcHJvcG9zZWQgd29yZGluZyBpcyBjb25mdXNpbmcuICZuYnNwO1JlYWN0aW5nIG5vZGVzIGFs d2F5cyBvbmx5IGFwcGx5IHRoZSByZWR1Y3Rpb24gcGVyY2VudGFnZSBmb3IgdGhlIHBlcmlvZCBv ZiB0aW1lIHRoYXQgdGhlIHNwZWNpZmljIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUuICZuYnNw O1RoYXQgcGVyaW9kIGVpdGhlciBlbmRzIHdoZW4gYSBuZXcgb3ZlcmxvYWQgcmVwb3J0IGlzDQog cmVjZWl2ZWQgb3Igd2hlbiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGV4cGlyZXMuPGJyPg0KPGJyPg0K VGhhdCBzYWlkLCBJJ20gaGFwcHkgd2l0aCBqdXN0IHJlbW92aW5nIHRoZSB3b3JkcyAmcXVvdDtm cm9tIG5vIG9uJnF1b3Q7IGFzIHByb3Bvc2VkIGJ5IExpb25lbCBiZWxvdy48YnI+DQo8YnI+DQpT dGV2ZTxicj4NCjxicj4NCk9uIDIvMjQvMTQgNzoyNiBBTSwgPGEgaHJlZj0ibWFpbHRvOmxpb25l bC5tb3JhbmRAb3JhbmdlLmNvbSI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9hPiB3cm90ZToN CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48YnI+DQpJIGRvbid0IHNlZSB0aGUgaXNzdWUsIGFzIGV4cGxhaW5lZCBpbiBt eSBtYWlsIGJ1dCBPSyB0byByZW1vdmUgaXQuIDxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGJyPg0KSWYgJnF1b3Q7Zm9yIG5vdyZxdW90OyBpcyByZW1vdmVkLCB0aGUgcmVzdWx0aW5nIHRl eHQgd291bGQgYmU6PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCiZuYnNwO0ZvciBleGFtcGxlIGlmIHRoZSByZWFjdGluZyBub2RlIGhhcyBiZWVu IHNlbmRpbmc8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCiZuYnNwOzEwMCBwYWNrZXRzIHBlciBz ZWNvbmQgdG8gdGhlIHJlcG9ydGluZyBub2RlLCB0aGVuPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+ DQombmJzcDthIHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSBvZiAx MDwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7d291bGQgbWVhbiB0aGF0IGZyb20gbm93 IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1Q8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCiZuYnNw O29ubHkgc2VuZCA5MCBwYWNrZXRzIHBlciBzZWNvbmQuPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+ DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCk1heWJlIGl0IHdvdWxkIGJlIGV2ZW4gZWFz aWVyIHRvIHJldmVyc2UgdGhlIHNlbnRlbmNlIGFzIGZvbGxvdzo8L3NwYW4+IDxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4N Cjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KRm9yIGV4YW1wbGUgaWYgYW4gT0Mt UmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgPGJyPg0KMTAgaGFzIGJlZW4gcmVjZWl2ZWQs IHRoZSByZWFjdGluZyBub2RlIHdoaWNoIDxicj4NCndvdWxkIG5vcm1hbGx5IHNlbmQgMTAwIHBh Y2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgPGJyPg0KcGFja2V0cyB0byB0aGUgcmVwb3J0aW5nIG5v ZGUuPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4N Cjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KQnV0IEknbSBmaW5lIGlmIHRoZSBpbml0aWFs IHByb3Bvc2VkIHJldmlzZWQgdGV4dCBpcyBrZXB0Ljwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0K PC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpMaW9uZWw8L3NwYW4+IDxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+ DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkRlIDogRGlNRSBbPC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5tYWlsdG86ZGltZS1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+XSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENy dXogQmFydG9sb21lPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkVudm95w6kgOiBsdW5kaSAyNCBm w6l2cmllciAyMDE0IDE0OjEzPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQrDgCA6IDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmRpbWVAaWV0Zi5vcmc8L3Nw YW4+PC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxicj4NCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxp bmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lv bjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkhl bGxvLDwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K SSBhZ3JlZSB3aXRoIFVscmljaCdzIHByb3Bvc2FsPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQpD aGVlcnM8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQovTUNydXo8L3NwYW4+IDxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+ DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkZyb206IERpTUUgWzwvc3Bhbj48YSBocmVm PSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bWFpbHRvOmRpbWUtYm91 bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl0gT24gQmVoYWxmIE9mIFdpZWhlLCBV bHJpY2ggKE5TTiAtIERFL011bmljaCk8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KU2VudDogbHVu ZXMsIDI0IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo0Njwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0K VG86IGV4dCBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUyk7IDwvc3Bhbj48YSBo cmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmRpbWVAaWV0Zi5vcmc8L3NwYW4+ PC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NClN1YmplY3Q6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5n IG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb248 L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpJIHNo YXJlIEpKYWNxdWVzIGNvbmNlcm4uIFJlcGxhY2luZyAmcXVvdDtmcm9tIG5vdyBvbiZxdW90OyB3 aXRoICZxdW90O2ZvciB0aGUgcGVyaW9kIHRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3Rp dmUmcXVvdDs8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KaXMgbWlzbGVhZGluZy4gTWF5IGJlIGl0 cyBiZXR0ZXIgdG8gc2ltcGx5IHJlbW92ZSAmcXVvdDtmcm9tIG5vdyBvbiZxdW90Oy48L3NwYW4+ IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4NCjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KVWxyaWNoPC9z cGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+ Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFu PiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkZyb206 IERpTUUgWzwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl0g T24gQmVoYWxmIE9mIGV4dCBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUyk8L3Nw YW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PGJyPg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyMSwgMjAxNCA3OjEx IFBNPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQpUbzogPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpk aW1lQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ZGltZUBpZXRmLm9yZzwvc3Bhbj48L2E+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PGJyPg0KU3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0 byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbjwvc3Bhbj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkhpIE1DcnV6LCBTdGV2ZTwv c3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KSSBhbHNv IGFncmVlIG9uIHRoZSAmcXVvdDt3b3VsZCBzZW5kICZxdW90OyBpbnN0ZWFkIG9mIHRoZSAmcXVv dDt3b3VsZCBoYXZlIHNlbnQmcXVvdDsgJm5ic3A7Zm9yIHN1cmUuICZuYnNwO0J1dCBJIGhhdmUg Jm5ic3A7YSBzbWFsbCBjb25jZXJuLyBjbGFyaWZpY2F0aW9uICZuYnNwO2Fib3V0IHRoZSBTdGV2 ZSBjb21tZW50IG9uICZuYnNwOyAmcXVvdDtmb3IgdGhlIHBlcmlvZCB0aGF0IHRoZSBvdmVybG9h ZCByZXBvcnQgaXMgYWN0aXZlJnF1b3Q7IGFuZCB0aGUgZXhhbXBsZSB0byB3aGljaCBpdCByZWZl cnMuPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0K RHVyaW5nIHRoZSB0aW1lIHRoZSBPTFIgaXMgYWN0aXZlLCB3aGljaCBtYXkgYmUgcmF0aGVyIGxv bmcsICZuYnNwO3RoZSB0cmFmZmljIHRoZSByZWFjdGluZyBub2RlIHdvdWxkIHNlbmQgbWF5IGJl IDEwMCBwYWNrZXQgJm5ic3A7d2hlbiBpdCBoYXMganVzdCByZWNlaXZlZCB0aGUgT0xSLiBBIGJp dCBsYXRlciwgdGhlIHRyYWZmaWMgaXQgd291bGQgc2VuZCBjb3VsZCBiZSAxMjAgKG9yIDgwKSwg YW5kIGZyb20gdGhlIE9MUiBkZWZpbml0aW9uLCAmbmJzcDsgaXQgd291bGQNCiBzZW5kIDEyMHgw LDkgKG9yIDgwKiAwLDkpIHBhY2tldHMsIG9uICZuYnNwO3doaWNoIEkgYWdyZWUuIFRoaXMgaXMg aW4gbGluZSAmbmJzcDt3aXRoIHRoZSBldmVyeSAxMHRoIHBhY2tldCBkcm9wcGluZyAmbmJzcDtv biB3aGljaCBJIGFsc28gYWdyZWUuDQo8YnI+DQombmJzcDs8YnI+DQpBcyB0aGUgdGV4dCAmbmJz cDsgd291bGQgJm5ic3A7YmUgd3JpdHRlbiB3aXRoIHRoZSBTdGV2ZSBtb2RpZmljYXRpb24gLCB3 ZSBtYXkgdW5kZXJzdGFuZCBpdCBpcyAmbmJzcDs4MCBQYWNrZXQgZHVyaW5nIGFsbCB0aGUgdGlt ZSAmbmJzcDt0aGUgT0xSIGlzIGFjdGl2ZS4gTm90IHlldCB0aGluayB0byBhbiBhbHRlcm5hdGl2 ZSB0ZXh0LCBidXQgZmlyc3QgdG8gc2VlIGlmIHlvdSBhZ3JlZSB3aXRoIG15IHJlbWFyay48L3Nw YW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpKSmFjcXVl cyA8YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PGJyPg0KRGUgOiBEaU1FIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij5dIERlIGxhIHBhcnQgZGUNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bGlvbmVs Lm1vcmFuZEBvcmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tPC9z cGFuPjwvYT4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpFbnZvecOpIDogdmVuZHJlZGkgMjEgZsOpdnJpZXIg MjAxNCAxODozMzwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0Kw4AgOiBTdGV2ZSBEb25vdmFuOyA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmRpbWVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5kaW1lQGlldGYu b3JnPC9zcGFuPjwvYT4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBU aHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNv bmNsdXNpb248L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQomIzQzOzEgKGluY2x1ZGluZyBTdGV2ZSBjb21tZW50KTwvc3Bhbj4gPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0K PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpEZSA6IERpTUUgWzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bWFpbHRvOmRpbWUt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPl0gRGUgbGEgcGFydCBkZSBTdGV2 ZSBEb25vdmFuPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkVudm95w6kgOiB2ZW5kcmVkaSAyMSBm w6l2cmllciAyMDE0IDE2OjM3PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQrDgCA6IDwvc3Bhbj48 YSBocmVmPSJtYWlsdG86ZGltZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPmRpbWVAaWV0Zi5vcmc8L3Nw YW4+PC9hPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxicj4NCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxp bmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lv bjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCk1h cmlhIENydXosPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 YnI+DQpJIHN1cHBvcnQgeW91ciBzdWdnZXN0ZWQgY2hhbmdlcy4gJm5ic3A7SSBoYXZlIG9uZSBm dXJ0aGVyIHN1Z2dlc3RlZCBjaGFuZ2UgYmVsb3cuPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwv c3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KU3RldmU8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpP biAyLzIxLzE0IDI6NDAgQU0sIE1hcmlhIENydXogQmFydG9sb21lIHdyb3RlOjwvc3Bhbj4gPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPg0KPGJyPg0KIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24g cHJldmlvdXMgaGlzdG9yeTwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KPC9zcGFuPiZuYnNwOzxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YnI+DQpGb2xsb3dpbmcgYWdyZWVtZW50IGlzIHJlYWNoZWQ6PC9zcGFuPiA8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+DQo8YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCk5vdyAoY2hhcHRlciA0 LjcpOjwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSBPQy1SZWR1Y3Rp b24tUGVyY2VudGFnZSBBVlAgKEFWUCBjb2RlIFRCRDgpIGlzIHR5cGUgb2YgVW5zaWduZWQzMjwv c3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwO2FuZCBkZXNjcmliZXMgdGhlIHBl cmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzPC9zcGFuPiA8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7cmVxdWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8g d2hhdCBpdCBvdGhlcndpc2Ugd291bGQgaGF2ZSBzZW50Ljwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJy Pg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpQcm9wb3NhbDo8L3NwYW4+IDxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQombmJzcDsgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIEFWUCAoQVZQIGNvZGUg VEJEOCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyICZuYnNwOzwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJy Pg0KJm5ic3A7IGFuZCBkZXNjcmliZXMgdGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhh dCB0aGUgc2VuZGVyIGlzICZuYnNwOzwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7IHJl cXVlc3RlZCB0byByZWR1Y2UsIGNvbXBhcmVkIHRvIHdoYXQgaXQgb3RoZXJ3aXNlIHdvdWxkIHNl bmQuICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7Jmx0Oy0tLS08L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCk5vdyAoY2hhcHRlciA1 LjUuMik6PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO0luZGlj YXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9kZSB0bzwv c3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWR1Y2UgaXRzIHRy YWZmaWMgYnkgYSBnaXZlbiBwZXJjZW50YWdlLiAmbmJzcDtGb3IgZXhhbXBsZSBpZiB0aGU8L3Nw YW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7cmVhY3Rpbmcgbm9kZSBo YXMgYmVlbiBzZW5kaW5nIDEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8gdGhlPC9zcGFuPiA8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO3JlcG9ydGluZyBub2RlLCB0aGVuIGEg cmVjZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlPC9zcGFuPiA8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwO29mIDEwIHdvdWxkIG1lYW4gdGhhdCBmcm9t IG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIG9ubHkgc2VuZDwvc3Bhbj4gPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDs5MCBwYWNrZXRzIHBlciBzZWNvbmQuICZuYnNw O0hvdyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hpZXZlcyB0aGUgJnF1b3Q7dHJ1ZTwvc3Bhbj4gPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtyZWR1Y3Rpb24mcXVvdDsgdHJhbnNh Y3Rpb25zIGxlYWRpbmcgdG8gdGhlIHNlbnQgcmVxdWVzdCBtZXNzYWdlcyBpcyB1cDwvc3Bhbj4g PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDt0byB0aGUgaW1wbGVtZW50YXRp b24uICZuYnNwO1RoZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeTwvc3Bhbj4g PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsxMHRoIHBhY2tldCBmcm9tIGl0 cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlvbjwvc3Bhbj4gPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2dpYyB0cnkgdG8gcmVjb3ZlciBm cm9tIGl0LjAgJmx0OyB2YWx1ZSAmbHQ7IDEwMDwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KPC9z cGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQombmJzcDtQcm9wb3NhbDo8L3NwYW4+IDxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQpJbmRpY2F0ZXMgdGhhdCB0aGUgcmVwb3J0aW5nIG5vZGUgdXJnZXMgdGhlIHJlYWN0 aW5nIG5vZGUgdG8gcmVkdWNlIDxicj4NCml0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2VudGFn ZS4gRm9yIGV4YW1wbGUgaWYgdGhlPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQpyZWFjdGluZyBu b2RlIHdvdWxkIHNlbmQgMTAwIHBhY2tldHMgdG8gdGhlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyZsdDstLS08L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCnJlcG9ydGluZyBub2Rl LCB0aGVuIGEgcmVjZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDxi cj4NCjEwIHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNU IG9ubHkgc2VuZDwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPGJyPg0KOTAgcGFja2V0cyBpbnN0ZWFkIG9m IDEwMC4gSG93IHRoZSByZWFjdGluZyBub2RlIGFjaGlldmVzIHRoZSAmcXVvdDt0cnVlICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZsdDstLS08L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KcmVkdWN0aW9u JnF1b3Q7IHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRoZSBzZW50IHJlcXVlc3QgbWVzc2FnZXMg aXMgdXAgdG8gPGJyPg0KdGhlIGltcGxlbWVudGF0aW9uLiBUaGUgcmVhY3Rpbmcgbm9kZSBNQVkg c2ltcGx5IGRyb3AgZXZlcnkgMTB0aCA8YnI+DQpwYWNrZXQgZnJvbSBpdHMgb3V0cHV0IHF1ZXVl IGFuZCBsZXQgdGhlIGdlbmVyaWMgYXBwbGljYXRpb24gbG9naWMgdHJ5IDxicj4NCnRvIHJlY292 ZXIgZnJvbSBpdC48L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NClNSRCZndDsgUmVwbGFjZSAmcXVv dDtmcm9tIG5vdyBvbiZxdW90OyBpbiB0aGUgYWJvdmUgd2l0aCAmcXVvdDtmb3IgdGhlIHBlcmlv ZCB0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlJnF1b3Q7PC9zcGFuPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4N CkRpTUUgbWFpbGluZyBsaXN0PC9zcGFuPiA8dT48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+PGJy Pg0KPC9zcGFuPjwvdT48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPkRp TUVAaWV0Zi5vcmc8L3NwYW4+PC9hPg0KPHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4N Cjwvc3Bhbj48L3U+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9kaW1lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9k aW1lPC9zcGFuPjwvYT4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxi cj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCkNlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRp ZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvc3Bhbj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwvc3Bhbj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YnI+DQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9zcGFuPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3NwYW4+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+PGJyPg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQpJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L3NwYW4+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+PGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpUaGFuayB5b3UuPC9zcGFuPiA8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCjwvc3Bhbj4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KQ2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDsiPjxicj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPC9zcGFuPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDsiPjxicj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YnI+DQpUaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozwvc3Bhbj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4NCjxicj4NCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvc3Bhbj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48YnI+DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NClRoYW5rIHlvdS48L3NwYW4+IDxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij48YnI+DQo8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+DQo8YnI+DQpEaU1F IG1haWxpbmcgbGlzdDwvc3Bhbj4gPHU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPjxicj4NCjwv c3Bhbj48L3U+PGEgaHJlZj0ibWFpbHRvOkRpTUVAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5EaU1FQGll dGYub3JnPC9zcGFuPjwvYT4NCjx1PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8L3Nw YW4+PC91PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll ciBOZXcmcXVvdDsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwv c3Bhbj48L2E+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPC9zcGFuPiZuYnNwOzxicj4NCiZuYnNwOzxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQo8YnI+DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVn aWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8YnI+DQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPGJyPg0KT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxicj4NCjxicj4NClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PGJyPg0KdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u PGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuPGJyPg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Ljxicj4NClRoYW5rIHlvdS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PGJyPg0KPHR0Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPC90dD48YnI+DQo8dHQ+RGlNRSBtYWlsaW5nIGxp c3Q8L3R0Pjx1PjxzcGFuIHN0eWxlPSJjb2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91Pjwvc3Bh bj48YSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5EaU1FQGlldGYub3JnPC9zcGFuPjwvdHQ+PC9hPjx1PjxzcGFuIHN0eWxlPSJj b2xvcjpibHVlIj48YnI+DQo8L3NwYW4+PC91PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZGltZSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L3NwYW4+PC90dD48 L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHR0Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPC90dD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPjxicj4NCjx0dD5EaU1FIG1haWxpbmcgbGlzdDwvdHQ+PGJyPg0K PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpEaU1FQGlldGYub3JnIj48dHQ+RGlNRUBpZXRmLm9yZzwv dHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGltZSI+PHR0Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZTwv dHQ+PC9hPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PGJyPg0KPC9zcGFuPjxicj4NCjx0dD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PC90dD48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+PGJyPg0KPHR0PkRpTUUgbWFpbGluZyBsaXN0PC90dD48YnI+DQo8dHQ+RGlNRUBp ZXRmLm9yZzwvdHQ+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZGltZSI+PHR0PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L3NwYW4+PC90dD48L2E+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_087A34937E64E74E848732CFF8354B920978871DESESSMB101erics_-- From nobody Tue Mar 4 03:22:41 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02071A0709 for ; Tue, 4 Mar 2014 03:22:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaFDHFrtVDkC for ; Tue, 4 Mar 2014 03:22:31 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5491A06E5 for ; Tue, 4 Mar 2014 03:22:30 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s24BMKhI032164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 12:22:20 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s24BMJJS000796 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 12:22:20 +0100 Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Mar 2014 12:22:18 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 12:22:18 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , ext Jouni Korhonen Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EvEWgP4lzthw/EteSAD4lZZwkA== Date: Tue, 4 Mar 2014 11:22:18 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-intra.net> <5314C842.5040105@usdonovans.com> In-Reply-To: <5314C842.5040105@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B54C4DEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 33820 X-purgate-ID: 151667::1393932141-00003660-C616E854/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/23QS60-gl_slFnE6Hna79FDtx9I Cc: Ben Campbell , "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:22:38 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B54C4DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, I'm trying to understand the principles. Is it so that we have two usecases= for OC-Supported-Features AVP in an answer message: a) if the answer does not contain an OLR then OC-Supported-Features contain= s all features the reporting node supports (or all features the reporting n= ode and the reacting node commonly support (what would be the difference fr= om the reacting node's point of view?)) b) if the answer contains an OLR then the OC-Supported-Features contains th= e selected features (selected from the set of features advertised in the re= quest); any inconsistency (e.g. more than one abatement alogorithm; somethi= ng is selected that was not advertised) would result in ignoring the OLR. For b), if the OLR is a replay, I guess the selected features in OC-Support= ed-Features must also not change (and should be ignored together with the O= LR). Ulrich From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Monday, March 03, 2014 7:22 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen Cc: ext Askerup, Anders; Ben Campbell; dime@ietf.org list Subject: Re: [Dime] Issue#30 status Inline... On 3/3/14 1:56 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Steve, but (ad 2.) how would (implementers of) the reacting node know whether e.g. bit= 5 of the OC-Feature-Vector will be allocated to an "abatement algorithm" o= r to something else? SRD> A node that doesn't understand the meaning of a bit presumably should = ignore that bit. In addition, I believe we have it defined that the report= ing node selects from the abatement algorithms in the OC-Supported-Features= AVP received from the reacting node. Ad 5. Would it be ok to say: 5. When receiving an answer that does not contain an OC-OLR, the reacting n= ode which supports only OLR_DEFAULT_ALGO and no other feature can safely ig= nore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be = interpreted/ignored based on information received in OC-Supported-Features)= . This may be different for reacting nodes which support other features tha= n just OLR_DEFAULT_ALGO. SRD> I ok with this if we remove the parenthetical statement. Ulrich -----Original Message----- From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Monday, March 03, 2014 2:26 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen Cc: ext Askerup, Anders; Ben Campbell; dime@ietf.org = list Subject: Re: [Dime] Issue#30 status Ulrich, I think you mean "abatement algorithm" below when you say feature. There will be cases when it is valid to indicate support multiple features. Support for the loss algorithm and agent overload is an example. It is not valid for the reporting node to indicate support for two abatement algorithms. See more below. Steve On 3/3/14, 12:51 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Thank you for the clarification. It seems the proposed principles are: 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an a= nswer message that corresponds to a request which contained an OC-Supported= -Features AVP. 2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message w= hen 2a) There was no OC-Supported-Features AVP in the answer 2b) The OC-Supported-Features AVP in the answer indicated support of more= than one supported feature 2c) The OC-Supported-Features AVP in the answer indicated support of less= than one supported feature 2d) The OC-Supported-Features AVP in the answer indicated support of exac= tly one feature, but that one is not supported by the reacting node. SRD> The above three should say abatement algorithm instead of feature. 3. Reacting nodes MUST interpret a received OC-OLR in the context of the se= lected feature as received within the OC-Supported-Features AVP. 4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in ans= wers (from a destination) may or may not do proactive throttling towards th= at destination. 5. When receiving an answer that does not contain an OC-OLR, the reacting n= ode can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR w= hich needs to be interpreted/ignored based on information received in OC-Su= pported-Features). SRD> This should be modified with a note saying that this can and likely will change when the protocol is extended. Maybe this would be in an extensibility section. Is this agreeable? Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] Sent: Monday, March 03, 2014 12:21 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list Subject: Re: [Dime] Issue#30 status On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Jouni, Is this your proposal or your decision? as none of these moving parts can be nailed down. My proposal here ^^^^^^^^^^^^ Anyway, what is the expected behaviour of the reacting node (that supports = only OLR_DEFAULT_ALGO) when receiving an answer that contains a) OLR but no Supported-Features Ehh.. if we agree that OC-Suppoted-Feature is in every answer message this would be an error case (misbehaving reporting node). My proposal would be reporting node to discard the OC-OLR. b) Supported Features but no OLR Reporting node has nothing to report except that it states it supports DOIC. No chance in the current state, if there is one. c) OLR and Supported Features Is the information received in Supported-Features in the answer something t= hat needs to be taken into account when sending subsequent requests (i.e. d= o less proactive throttling), or something that needs to be taken into acco= unt when interpreting the OLR received in the same answer? Depends on the abatement algorithm or other future features. In the context of this I-D there is no such dependency since we got only one algorithm which is simple request-reply nature. What if the received Supported-Features in the answer does not indicate OL= R_DEFAULT_ALGO? Then the OC-OLR must include abatement information that matches with the algorithm/feature indicated in the OC-Supported-Features. Sending an empty OC-Supported-Features in not allowed. What if the received Supported-Features in the answer indicates support of = something different than OLR_DEFAULT_ALGO? Same as above. It is a valid use case (for future deployments) that a network absolutely wants to use some other algorithm than the default. Then announcing the default is no use. Our protocol needs to be flexible enough to allow such policy decision. What if the received Supported Features in the answer indicates support of = OLR_DEFAULT_ALGO and support of something else? This is something that is open but as I tried to drive at the beginning the OC-Supported-Features in an answer names a single selected abatement algorithm. - Jouni Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] Sent: Friday, February 28, 2014 2:49 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list Subject: Re: [Dime] Issue#30 status Right. We are going back and forth and continue to do that as long as none of these moving parts can be nailed down. My proposal here is that we simply agree now that OC-Supported-Features is in every answer message. Period. Get one corner nailed down. The rest of the fixing inconsistencies and missing/excess parts listed below then need to be done according to the above decision. - JOuni On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" wrote: Anders, Yes, if we conclude that there is a requirement for OC-Supported-Features t= o be sent in answers, then it should be included in every answer. However, = I still don't see that requirement. In addition we would need some text spe= cifying the expected behaviour of the reacting node when receiving OC-Suppo= rted-Features in an answer, keeping in mind that the reacting node cannot k= now whether it was the server or an agent that inserted the OC-Supported-Fe= ature, and whether or not a subsequent request will be routed via that node= . Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Askerup, Anders Sent: Thursday, February 27, 2014 6:14 PM To: Ben Campbell; Steve Donovan Cc: dime@ietf.org list Subject: Re: [Dime] Issue#30 status I also agree that including OC-Supported-Features in every answer is prefer= able. In addition to mirroring Requests, it is in-line with how Supported-F= eatures are managed in at least some 3GPP interfaces as well. /Anders -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Wednesday, February 26, 2014 9:19 AM To: Steve Donovan Cc: dime@ietf.org list Subject: Re: [Dime] Issue#30 status On Feb 26, 2014, at 9:14 AM, Steve Donovan wrote: SRD> We don't have consensus yet, but if we agree on the need for reacting = nodes to know whether there is support for DOIC in the Diameter network the= n I think the requirement would be similar to how we are handling overload = reports. The reporting node MUST ensure that all reacting nodes receive th= e OC-Supported-Features AVP. This can be done by including the AVP in all = answer messages or it can be done by remembering to whom the AVP has been s= ent. Given the trivial nature of sending and reading OC-Supported-Features, I th= ink we should put it in every answer. This mirrors the way we handle it in = requests. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B54C4DEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

I’m = trying to understand the principles. Is it so that we have two usecases for= OC-Supported-Features AVP in an answer message:

a) if the = answer does not contain an OLR then OC-Supported-Features contains all feat= ures the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference = from the reacting node’s point of view?))

b) if the = answer contains an OLR then the OC-Supported-Features contains the selected= features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; = something is selected that was not advertised) would result in ignoring the= OLR.

 = ;

For b), if= the OLR is a replay, I guess the selected features in OC-Supported-Feature= s must also not change (and should be ignored together with the OLR).

 = ;

Ulrich

 = ;

 = ;

 = ;

From:= ext Steve Donovan [= mailto:srdonovan@usdonovans.com]
Sent: Monday, March 03, 2014 7:22 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen
Cc: ext Askerup, Anders; Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

 

Inline...<= /p>

On 3/3/14 1:56 PM, Wiehe, Ulrich (NSN - DE/Munich) w= rote:

Steve,
 
but
 
(ad 2.) how would (implementers of) the reacting node know whether e.g=
. bit 5 of the OC-Feature-Vector will be allocated to an "abatement al=
gorithm" or to something else?

SRD> A node that doesn't understand the meaning o= f a bit presumably should ignore that bit.  In addition, I believe we = have it defined that the reporting node selects from the abatement algorith= ms in the OC-Supported-Features AVP received from the reacting node. 

 
 
Ad 5. Would it be ok to say:
5. When receiving an answer that does not contain an OC-OLR, the react=
ing node which supports only OLR_DEFAULT_ALGO and no other feature can safe=
ly ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs t=
o be interpreted/ignored based on information received in OC-Supported-Feat=
ures). This may be different for reacting nodes which support other feature=
s than just OLR_DEFAULT_ALGO.

SRD> I ok with this if we remove the parenthetica= l statement.

 
 
Ulrich
 
 
 
-----Original Message-----
From: ext Steve Donovan [m=
ailto:srdonovan@usdonovans.com] 
Sent: Monday, March 03, 2014 2:26 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen
Cc: ext Askerup, Anders; Ben Campbell; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status
 
Ulrich,
 
I think you mean "abatement algorithm" below when you say fe=
ature.
 
There will be cases when it is valid to indicate support multiple 
features.  Support for the loss algorithm and agent overload is a=
n 
example.  It is not valid for the reporting node to indicate supp=
ort for 
two abatement algorithms.
 
See more below.
 
Steve
 
On 3/3/14, 12:51 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:=
Thank you for the clarification.
It seems the proposed principles are:
 
1. Reporting nodes MUST always include an OC-Supported-Features AVP to=
 an answer message that corresponds to a request which contained an OC-Supp=
orted-Features AVP.
 
2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer mess=
age when
  2a) There was no OC-Supported-Features AVP in the answer
  2b) The OC-Supported-Features AVP in the answer indicated suppo=
rt of more than one supported feature
  2c) The OC-Supported-Features AVP in the answer indicated suppo=
rt of less than one supported feature
  2d) The OC-Supported-Features AVP in the answer indicated suppo=
rt of exactly one feature, but that one is not supported by the reacting no=
de.
SRD> The above three should say abatement algorithm instead of feat=
ure.
 
3. Reacting nodes MUST interpret a received OC-OLR in the context of t=
he selected feature as received within the OC-Supported-Features AVP.<=
/o:p>
 
4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features i=
n answers (from a destination) may or may not do proactive throttling towar=
ds that destination.
 
5. When receiving an answer that does not contain an OC-OLR, the react=
ing node can safely ignore an OC-Supported-Features AVP (as there is no OC-=
OLR which needs to be interpreted/ignored based on information received in =
OC-Supported-Features).
SRD> This should be modified with a note saying that this can and l=
ikely 
will change when the protocol is extended.  Maybe this would be i=
n an 
extensibility section.
 
Is this agreeable?
 
Ulrich
 
-----Original Message-----
From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com]
Sent: Monday, March 03, 2014 12:21 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status
 
 
On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; <ulrich.wiehe@nsn.com>=
 wrote:
 
Jouni,
 
Is this your proposal or your decision?
as none of these moving parts can be nailed down. My proposal here
           &nbs=
p;            &=
nbsp;           &nbs=
p;            &=
nbsp;   ^^^^^^^^^^^^
Anyway, what is the expected behaviour of the reacting node (that supp=
orts only OLR_DEFAULT_ALGO) when receiving an answer that contains
a) OLR but no Supported-Features
Ehh.. if we agree that OC-Suppoted-Feature is in every answer message<=
o:p>
this would be an error case (misbehaving reporting node). My proposal<=
o:p>
would be reporting node to discard the OC-OLR.
 
b) Supported Features but no OLR
Reporting node has nothing to report except that it states it supports=
DOIC. No chance in the current state, if there is one.
 
c) OLR and Supported Features
 
Is the information received in Supported-Features in the answer someth=
ing that needs to be taken into account when sending subsequent requests (i=
.e. do less proactive throttling), or something that needs to be taken into=
 account when interpreting the OLR received in the same answer?<=
/pre>
Depends on the abatement algorithm or other future features. In the
context of this I-D there is no such dependency since we got only=
one algorithm which is simple request-reply nature.
 
What if the received Supported-Features in the answer  does not i=
ndicate OLR_DEFAULT_ALGO?
Then the OC-OLR must include abatement information that matches with t=
he
algorithm/feature indicated in the OC-Supported-Features. Sending an e=
mpty
OC-Supported-Features in not allowed.
 
What if the received Supported-Features in the answer indicates suppor=
t of something different than OLR_DEFAULT_ALGO?
Same as above. It is a valid use case (for future deployments) that a<=
o:p>
network absolutely wants to use some other algorithm than the default.=
Then announcing the default is no use. Our protocol needs to be flexib=
le
enough to allow such policy decision.
 
What if the received Supported Features in the answer indicates suppor=
t of OLR_DEFAULT_ALGO and support of something else?
This is something that is open but as I tried to drive at the beginnin=
g
the OC-Supported-Features in an answer names a single selected abateme=
nt
algorithm.
 
- Jouni
 
 
 
Ulrich
 
 
-----Original Message-----
From: ext Jouni Korhonen [ma=
ilto:jouni.nospam@gmail.com]
Sent: Friday, February 28, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status
 
 
<as a chair>
 
Right. We are going back and forth and continue to do that as long
as none of these moving parts can be nailed down. My proposal here
is that we simply agree now that OC-Supported-Features is in every
answer message. Period. Get one corner nailed down.
 
The rest of the fixing inconsistencies and missing/excess parts
listed below then need to be done according to the above decision.
 
- JOuni
 
 
On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)&quo=
t; <ulrich.wiehe@nsn.com>=
 wrote:
 
Anders,
 
Yes, if we conclude that there is a requirement for OC-Supported-Featu=
res to be sent in answers, then it should be included in every answer. Howe=
ver, I still don't see that requirement. In addition we would need some tex=
t specifying the expected behaviour of the reacting node when receiving OC-=
Supported-Features in an answer, keeping in mind that the reacting node can=
not know whether it was the server or an agent that inserted the OC-Support=
ed-Feature, and whether or not a subsequent request will be routed via that=
 node.
 
Ulrich
 
-----Original Message-----
From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext Askerup, Anders
Sent: Thursday, February 27, 2014 6:14 PM
To: Ben Campbell; Steve Donovan
Cc: dime@ietf.org list=
Subject: Re: [Dime] Issue#30 status
 
I also agree that including OC-Supported-Features in every answer is p=
referable. In addition to mirroring Requests, it is in-line with how Suppor=
ted-Features are managed in at least some 3GPP interfaces as well.
 
/Anders
 
-----Original Message-----
From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Ben Campbell
Sent: Wednesday, February 26, 2014 9:19 AM
To: Steve Donovan
Cc: dime@ietf.org list=
Subject: Re: [Dime] Issue#30 status
 
 
On Feb 26, 2014, at 9:14 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
 
SRD> We don't have consensus yet, but if we agree on the need for r=
eacting nodes to know whether there is support for DOIC in the Diameter net=
work then I think the requirement would be similar to how we are handling o=
verload reports.  The reporting node MUST ensure that all reacting nod=
es receive the OC-Supported-Features AVP.  This can be done by includi=
ng the AVP in all answer messages or it can be done by remembering to whom =
the AVP has been sent.
Given the trivial nature of sending and reading OC-Supported-Features,=
 I think we should put it in every answer. This mirrors the way we handle i=
t in requests.
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
 
_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime
 
 
 

 

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B54C4DEMUMBX014nsnin_-- From nobody Tue Mar 4 03:34:11 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77481A0747 for ; Tue, 4 Mar 2014 03:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z0tAsgUKyQM2 for ; Tue, 4 Mar 2014 03:34:08 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id F226B1A074B for ; Tue, 4 Mar 2014 03:34:07 -0800 (PST) Received: from dhcp-bfe5.meeting.ietf.org (dhcp-bfe5.meeting.ietf.org [31.133.191.229]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s24BXqAn095817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 4 Mar 2014 05:33:54 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> Date: Tue, 4 Mar 2014 11:33:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AeG2GwORdzQqVaPMJuUCxntfjCI Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:34:09 -0000 On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Steve, > I=92m trying to understand the principles. Is it so that we have two = usecases for OC-Supported-Features AVP in an answer message: > a) if the answer does not contain an OLR then OC-Supported-Features = contains all features the reporting node supports (or all features the = reporting node and the reacting node commonly support (what would be the = difference from the reacting node=92s point of view?)) > b) if the answer contains an OLR then the OC-Supported-Features = contains the selected features (selected from the set of features = advertised in the request); any inconsistency (e.g. more than one = abatement alogorithm; something is selected that was not advertised) = would result in ignoring the OLR. IMO, OC-Supported-Features should be treated as a) in all cases. If we = need information about the specific selections made for a particular = OLR, that info belongs in the OLR. > =20 > For b), if the OLR is a replay, I guess the selected features in = OC-Supported-Features must also not change (and should be ignored = together with the OLR). That would be mostly irrelevant if the we put OLR selections in the OLR, = so long as the generally advertised features in OC-Supported-Features do = not change in a way that makes the OLR no longer valid. > =20 > Ulrich From nobody Tue Mar 4 03:43:45 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AABE1A0034 for ; Tue, 4 Mar 2014 03:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTqZul-JUjRp for ; Tue, 4 Mar 2014 03:43:42 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9C31A0721 for ; Tue, 4 Mar 2014 03:43:42 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s24BhY7R024385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 12:43:34 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s24BhXTE003701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 12:43:33 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 12:43:33 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Ben Campbell Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EvEWgP4lzthw/EteSAD4lZZwkPErMq2A4lZTnEA= Date: Tue, 4 Mar 2014 11:43:32 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B54E2@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530BA7B6.9020405@usdonovans.com> <8E282417-E73C-4896-BDC0-37B24E709D4B@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B48BB@DEMUMBX014.nsn-intra.net> <530DDF7B.6070801@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A05@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> In-Reply-To: <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1807 X-purgate-ID: 151667::1393933414-00005322-7E01EF8B/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Sr2GJqxaLvBcQzsdfmRA0sWCGSc Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:43:44 -0000 I agree with Ben But then again: which purpose does OC-Supported-Features I answer serve? Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Tuesday, March 04, 2014 12:34 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.o= rg list Subject: Re: [Dime] Issue#30 status On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > Steve, > I'm trying to understand the principles. Is it so that we have two usecas= es for OC-Supported-Features AVP in an answer message: > a) if the answer does not contain an OLR then OC-Supported-Features conta= ins all features the reporting node supports (or all features the reporting= node and the reacting node commonly support (what would be the difference = from the reacting node's point of view?)) > b) if the answer contains an OLR then the OC-Supported-Features contains = the selected features (selected from the set of features advertised in the = request); any inconsistency (e.g. more than one abatement alogorithm; somet= hing is selected that was not advertised) would result in ignoring the OLR. IMO, OC-Supported-Features should be treated as a) in all cases. If we need= information about the specific selections made for a particular OLR, that = info belongs in the OLR. > =20 > For b), if the OLR is a replay, I guess the selected features in OC-Suppo= rted-Features must also not change (and should be ignored together with the= OLR). That would be mostly irrelevant if the we put OLR selections in the OLR, so= long as the generally advertised features in OC-Supported-Features do not = change in a way that makes the OLR no longer valid. > =20 > Ulrich From nobody Tue Mar 4 03:53:38 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04F621A0726 for ; Tue, 4 Mar 2014 03:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PzVJg6619znU for ; Tue, 4 Mar 2014 03:53:32 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id BCB881A021F for ; Tue, 4 Mar 2014 03:53:32 -0800 (PST) Received: from [130.129.63.247] (port=54152 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKnuW-0003OS-Kc; Tue, 04 Mar 2014 03:53:29 -0800 Message-ID: <5315BEB1.4080109@usdonovans.com> Date: Tue, 04 Mar 2014 11:53:21 +0000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Ben Campbell References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54E2@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B54E2@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------040307000707010107060300" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IUXUF2_sZ43xoo_WWC9QIzAhU-g Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 11:53:34 -0000 This is a multi-part message in MIME format. --------------040307000707010107060300 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It serves to tell the reacting node that the reporting node supports DOIC, the features that the two nodes have in common and the abatement algorithm that the reporting node will be using. I agree that capability exchange should be kept separate from overload reports. We don't, however, have consensus on this point. Steve On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > I agree with Ben > > But then again: which purpose does OC-Supported-Features I answer serve? > Ulrich > > -----Original Message----- > From: ext Ben Campbell [mailto:ben@nostrum.com] > Sent: Tuesday, March 04, 2014 12:34 PM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list > Subject: Re: [Dime] Issue#30 status > > > On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > >> Steve, >> I'm trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message: >> a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node's point of view?)) >> b) if the answer contains an OLR then the OC-Supported-Features contains the selected features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; something is selected that was not advertised) would result in ignoring the OLR. > IMO, OC-Supported-Features should be treated as a) in all cases. If we need information about the specific selections made for a particular OLR, that info belongs in the OLR. > >> >> For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR). > That would be mostly irrelevant if the we put OLR selections in the OLR, so long as the generally advertised features in OC-Supported-Features do not change in a way that makes the OLR no longer valid. > >> >> Ulrich > --------------040307000707010107060300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit It serves to tell the reacting node that the reporting node supports DOIC, the features that the two nodes have in common and the abatement algorithm that the reporting node will be using.

I agree that capability exchange should be kept separate from overload reports.  We don't, however, have consensus on this point.

Steve

On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
I agree with Ben

But then again: which purpose does OC-Supported-Features I answer serve?
Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Tuesday, March 04, 2014 12:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

Steve,
I'm trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message:
a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node's point of view?))
b) if the answer contains an OLR then the OC-Supported-Features contains the selected features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; something is selected that was not advertised) would result in ignoring the OLR.
IMO, OC-Supported-Features should be treated as a) in all cases. If we need information about the specific selections made for a particular OLR, that info belongs in the OLR.

 
For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR).
That would be mostly irrelevant if the we put OLR selections in the OLR, so long as the generally advertised features in OC-Supported-Features do not change in a way that makes the OLR no longer valid.

 
Ulrich


--------------040307000707010107060300-- From nobody Tue Mar 4 04:06:26 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02871A0763 for ; Tue, 4 Mar 2014 04:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRWPQNAJioJZ for ; Tue, 4 Mar 2014 04:06:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id AA4271A0762 for ; Tue, 4 Mar 2014 04:06:21 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s24C6DQc002823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 13:06:13 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s24C600A024773 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 13:06:12 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 4 Mar 2014 13:06:10 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 13:06:10 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , ext Ben Campbell Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EvEWgP4lzthw/EteSAD4lZZwkPErMq2A4lZTnEDErLODgIlZVFNQ Date: Tue, 4 Mar 2014 12:06:09 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B5519@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530DE76A.1030305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B4A31@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54E2@DEMUMBX014.nsn-intra.net> <5315BEB1.4080109@usdonovans.com> In-Reply-To: <5315BEB1.4080109@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5519DEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 10882 X-purgate-ID: 151667::1393934774-00003660-12969D48/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2pC81_8EjYxxfA1pqQCHW-TmbvQ Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 12:06:25 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5519DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Tuesday, March 04, 2014 12:53 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list Subject: Re: [Dime] Issue#30 status It serves to tell the reacting node that the reporting node supports DOIC, = the features that the two nodes have in common and the abatement algorithm = that the reporting node will be using. ...so that the the reacting = node can - based on that information - do what? I agree that capability exchange should be kept separate from overload repo= rts. We don't, however, have consensus on this point.Is it only Jo= uni who wants this dependency? Steve On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: I agree with Ben But then again: which purpose does OC-Supported-Features I answer serve? Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com] Sent: Tuesday, March 04, 2014 12:34 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.o= rg list Subject: Re: [Dime] Issue#30 status On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Steve, I'm trying to understand the principles. Is it so that we have two usecases= for OC-Supported-Features AVP in an answer message: a) if the answer does not contain an OLR then OC-Supported-Features contain= s all features the reporting node supports (or all features the reporting n= ode and the reacting node commonly support (what would be the difference fr= om the reacting node's point of view?)) b) if the answer contains an OLR then the OC-Supported-Features contains th= e selected features (selected from the set of features advertised in the re= quest); any inconsistency (e.g. more than one abatement alogorithm; somethi= ng is selected that was not advertised) would result in ignoring the OLR. IMO, OC-Supported-Features should be treated as a) in all cases. If we need= information about the specific selections made for a particular OLR, that = info belongs in the OLR. For b), if the OLR is a replay, I guess the selected features in OC-Support= ed-Features must also not change (and should be ignored together with the O= LR). That would be mostly irrelevant if the we put OLR selections in the OLR, so= long as the generally advertised features in OC-Supported-Features do not = change in a way that makes the OLR no longer valid. Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5519DEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 <= /p>

From:= ext Steve Donovan [= mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 04, 2014 12:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

 

= It serves to tell the reacting node that the reporting node supports DOIC, = the features that the two nodes have in common and the abatement algorithm = that the reporting node will be using. <Ulrich>…so that the the reacting node can – based on th= at information – do what?</Ulrich>

I agree that capability exchange should be kept separate from overload repo= rts.  We don't, however, have consensus on this point.
<Ulrich>Is it only Jouni wh= o wants this  dependency?</Ulrich>

Steve

On 3/4/14 11:43 AM, Wiehe, Ulri= ch (NSN - DE/Munich) wrote:

I agree with Ben
 
But then again: which purpose does OC-Supported-F=
eatures I answer serve?
Ulrich
 
-----Original Message-----
From: ext Ben Campbell [mailto:ben@=
nostrum.com] 
Sent: Tuesday, March 04, 2014 12:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status
 
 
On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
 
Steve,
I'm trying to understand the principles. Is it so that we have two use=
cases for OC-Supported-Features AVP in an answer message:
a) if the answer does not contain an OLR then OC-Supported-Features co=
ntains all features the reporting node supports (or all features the report=
ing node and the reacting node commonly support (what would be the differen=
ce from the reacting node's point of view?))
b) if the answer contains an OLR then the OC-Supported-Features contai=
ns the selected features (selected from the set of features advertised in t=
he request); any inconsistency (e.g. more than one abatement alogorithm; so=
mething is selected that was not advertised) would result in ignoring the O=
LR.
 
IMO, OC-Supported-Features should be treated as a) in all cases. If we=
 need information about the specific selections made for a particular OLR, =
that info belongs in the OLR.
 
 
For b), if the OLR is a replay, I guess the selected features in OC-Su=
pported-Features must also not change (and should be ignored together with =
the OLR).
 
That would be mostly irrelevant if the we put OLR selections in the OL=
R, so long as the generally advertised features in OC-Supported-Features do=
 not change in a way that makes the OLR no longer valid.
 
 
Ulrich
 
 

 

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5519DEMUMBX014nsnin_-- From nobody Tue Mar 4 05:19:57 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BE41A0193 for ; Tue, 4 Mar 2014 05:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcHbcuaYHglk for ; Tue, 4 Mar 2014 05:19:51 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 323C21A01A7 for ; Tue, 4 Mar 2014 05:19:47 -0800 (PST) Received: from [130.129.63.247] (port=54219 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKpG0-0002wQ-NP; Tue, 04 Mar 2014 05:19:42 -0800 Message-ID: <5315D2E9.2050205@usdonovans.com> Date: Tue, 04 Mar 2014 13:19:37 +0000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Ben Campbell References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54E2@DEMUMBX014.nsn-intra.net> <5315BEB1.4080109@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B5519@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B5519@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------020203090308050303090205" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/BfIke4WpILuBr8liNUrGdkaLlS4 Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 13:19:54 -0000 This is a multi-part message in MIME format. --------------020203090308050303090205 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich, We've already discussed this. I understand that you don't think that the OC-Supported-Features AVP should be required in all answer messages. Others of us think that it should be. We can't make progress if we have to re-debate every point multiple times. I suggest that we follow Jouni's guidance made a few emails back and move on. Steve On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > > > > > *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* Tuesday, March 04, 2014 12:53 PM > *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell > *Cc:* ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list > *Subject:* Re: [Dime] Issue#30 status > > > > It serves to tell the reacting node that the reporting node supports > DOIC, the features that the two nodes have in common and the abatement > algorithm that the reporting node will be using.*/...so that > the the reacting node can -- based on that information -- do > what?/* > > I agree that capability exchange should be kept separate from overload > reports. We don't, however, have consensus on this point.*/Is > it only Jouni who wants this dependency?/* > > Steve > > On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > I agree with Ben > > > > But then again: which purpose does OC-Supported-Features I answer serve? > > Ulrich > > > > -----Original Message----- > > From: ext Ben Campbell [mailto:ben@nostrum.com] > > Sent: Tuesday, March 04, 2014 12:34 PM > > To: Wiehe, Ulrich (NSN - DE/Munich) > > Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list > > Subject: Re: [Dime] Issue#30 status > > > > > > On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > > > Steve, > > I'm trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message: > > a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node's point of view?)) > > b) if the answer contains an OLR then the OC-Supported-Features contains the selected features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; something is selected that was not advertised) would result in ignoring the OLR. > > > > IMO, OC-Supported-Features should be treated as a) in all cases. If we need information about the specific selections made for a particular OLR, that info belongs in the OLR. > > > > > > For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR). > > > > That would be mostly irrelevant if the we put OLR selections in the OLR, so long as the generally advertised features in OC-Supported-Features do not change in a way that makes the OLR no longer valid. > > > > > > Ulrich > > > > > > > --------------020203090308050303090205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich,

We've already discussed this.

I understand that you don't think that the OC-Supported-Features AVP should be required in all answer messages.

Others of us think that it should be.  We can't make progress if we have to re-debate every point multiple times.

I suggest that we follow Jouni's guidance made a few emails back and move on.

Steve

On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

 

 

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 04, 2014 12:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

 

It serves to tell the reacting node that the reporting node supports DOIC, the features that the two nodes have in common and the abatement algorithm that the reporting node will be using. <Ulrich>…so that the the reacting node can – based on that information – do what?</Ulrich>

I agree that capability exchange should be kept separate from overload reports.  We don't, however, have consensus on this point.
<Ulrich>Is it only Jouni who wants this  dependency?</Ulrich>

Steve

On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I agree with Ben
 
But then again: which purpose does OC-Supported-Features I answer serve?
Ulrich
 
-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Tuesday, March 04, 2014 12:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status
 
 
On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
 
Steve,
I'm trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message:
a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node's point of view?))
b) if the answer contains an OLR then the OC-Supported-Features contains the selected features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; something is selected that was not advertised) would result in ignoring the OLR.
 
IMO, OC-Supported-Features should be treated as a) in all cases. If we need information about the specific selections made for a particular OLR, that info belongs in the OLR.
 
 
For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR).
 
That would be mostly irrelevant if the we put OLR selections in the OLR, so long as the generally advertised features in OC-Supported-Features do not change in a way that makes the OLR no longer valid.
 
 
Ulrich
 
 

 


--------------020203090308050303090205-- From nobody Tue Mar 4 05:35:00 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FE4B1A017F for ; Tue, 4 Mar 2014 05:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOJSrHH8bTED for ; Tue, 4 Mar 2014 05:34:41 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF131A0170 for ; Tue, 4 Mar 2014 05:34:39 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s24DYXbd028860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 4 Mar 2014 07:34:35 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s24DYXRc003207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Mar 2014 14:34:33 +0100 Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 14:34:33 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "dime@ietf.org" Thread-Topic: [Dime] Issue#35 conclusion Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0A= Date: Tue, 4 Mar 2014 13:34:31 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209787161@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2@DEMUMBX014.nsn-intra.net> <530F9BC3.1010003@usdonovans.com> In-Reply-To: <530F9BC3.1010003@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266D671FR712WXCHMBA12z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8mQcXVCPXrpLdXOMmVpvEdlR5DY Subject: Re: [Dime] Issue#35 conclusion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 13:34:57 -0000 --_000_E194C2E18676714DACA9C3A2516265D20266D671FR712WXCHMBA12z_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all Hereafter several points about some collateral consequences of the Ticket = #35 proposal 1) Besides the commented point 3, I have a similar comment for point = 1. I have a client A with a per client type (0) active OLR having a high r= eduction % (90%) , then the DA receives an OLR client (1) to update % for = all nodes with a small % (10%). According to rule 1 , client A has now 10= % reduction: this will create a burst of traffic. I assume that very so= on after it will receive a new OLR type (0) with 90% but this rule is som= ething creating transient traffic bursts in an overload situation which i= s not our aim. So, we may modify the rule 1 eg by stating "A fresh OLR of = type (1) makes all old type (1) OLRs invalid and leave unchanged clients w= ith a OLR type(0)". But not sure the story is finished., if later the speci= fic peak vanishes and the server wants to handle client A as other nodes, = what does the server do? Due to my new rule, server sending an OLR type (1= ) does not solve this point, but we would like to avoid a server to continu= e to send OLR type (0),to this client as there is no more specificity - We may use the validity period of 0, but it means no more over= load - the other way is first to use a OLR type(0) with short validity= expiration period (and a value of 10% to align)) and to add a new rule: "= if an OLR(0) expires for a client, , and if an OLR type (1) exist for other= clients, the OLR type(1) applies to this client. 2) A clarification if I have the right understanding When DA receives the first OLR type (1) with a new seq number in an answer = to a client A , this OLR type (1) immediately applies to all nodes (apart t= hose with a OLR type(0) active, cf above), taking into account that DA will= then receives other answers to client B, C... with the same OLR type (1) = and the same seq number should be the same, as long as there is no modif br= ought to OLR type(1). May be also some text to avoid misunderstanding would= be need to avoid a wrong seq numbr handling Do you agree? 3) Another point: when I consider the target network in the future whe= re there are only DOIC clients, why to continue to send a mandatory OLR whi= ch shall always be ignored.... I would prefer to have no such OLR at all,= meaning to introduce a non mandatory OLR AVP with a default value when no = present. As in the target network, the Host OLR is per client, default val= ue would be (0). Views? 4) Regarding DOIC association, here we have an information (OLR with t= ype (1) exchanged inside a DOIC association that applies to many DOIC ass= ociations. It is possible but it should be highlighted . 5) I also saw Mcruz had a preferencee for another OLR type and not a n= ew AVP, have we concluded on this . What are your views? These are not blocking points, there is always some so= lution by adding new rules. Nevertheless I am always cautious when a new AV= P is introduced, as it always creates new combinational cases, that we have= to analyse . So is this optimization actually needed. If yes, we need to a= dd the right rules to avoid unexpected situations and misunderstanding Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 27 f=E9vrier 2014 21:11 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion I think if you change number three to the following then it works better. 3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for the c= lient to which the answer message is being routed. The agent shall apply t= he OLR or type (0) for traffic from that client. The old OLR of type (1) co= ntinues to apply for all clients that do not have a "per client" overload r= eport. I think it is important for a reporting node to be able to start with an "a= ll clients" overload report and then transition to "per client" reports for= chatty clients. Steve On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Dear MCruz, certainly a valid point. I don't have a strong view but I wanted to avoid t= he mixture to keep things simple. Maybe we should forbid the change from 1 to 0 during an ongoing overload. Anyway, I don't think this is a blocking point for the proposal to add the = new AVP. Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Thursday, February 27, 2014 5:13 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Dear Ulrich, Being: (0) OLR per client (1) OLR for all clients Some comments on the interactions you mentioned: 1. A fresh OLR of type (1) makes all old OLRs of any type invalid 2. A fresh OLR of type (0) makes an old OLR of type (0) bound to the s= ame client invalid 3. A fresh OLR of type (0) makes an old OLR of type (1) invalid I do not think 3) is right. Why an OLR per one specific client shall invali= date OLRs for rest of clients? This will imply that rest of clients will no= t have any overload mitigation on until they receive a new value of (1), or= (0) for each of them. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: mi=E9rcoles, 26 de febrero de 2014 12:23 To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi JJacques, thank you for the summary. I think it does not matter whether we call A) "OLR per client" the base solution and "OLR for all clients" the opt= imization or B) "OLR for all clients" the base solution and "OLR per client" the (3GP= P) extension as long as we cover both. I don't think there are impacts on sequence number handling, report types o= r DOIC associations. My proposal then is to add a new mandatory AVP of type enumerated to OC-OLR= with values (0) OLR per client (1) OLR for all clients Reporting nodes that better like A) could allways send (0) unless they supp= ort the "optimization" and want to use it; Reporting nodes that better like B) could allways send (1) unless they supp= ort the "(3GPP) extension" and want to use it. Clients can safely ignore the new AVP. Agents taking the role of the reacting node on behalf of a client must do t= he binding when receiving (0). We also need to say something on interactions e.g.: A fresh OLR of type (1) makes all old OLRs of any type invalid A fresh OLR of type (0) makes an old OLR of type (0) bound to the same clie= nt invalid A fresh OLR of type (0) makes an old OLR of type (1) invalid (i.e. change of type is allowed, mixture is not allowed) Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA= CQUES (JEAN-JACQUES) Sent: Wednesday, February 26, 2014 8:07 AM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi Steve, MCruz and all On my side, I agree with Lionel. I have not the same reading of the draft where I have not found the Stev= e's default case. I agree with Lionel that the OLR for a DOIC association relates to this DOI= C association and the OLR can be different for another DOIC association. = The basic (or "default") principle is that each DOIC association has its "o= wn life". Then, a server (local policy) can decide to send the same OLR to all its= clients (so for all its DOIC associations) , or it can define particular = OLR values for certain clients. Another interest is that when the server wants to update the OLR values = towards clients, it is not obliged to send the new values simultaneously= to all the clients : it may (local server policy) progressively change = the value over a certain duration to minimize sharp transitions. So for DOIC supporting clients, the current text allows these possibilities= , and in particular it satisfies the 3GGP client mitigation requirement. A second step is to address DAs supporting non DOIC clients. Over time, we= may expect that clients will be more and more DOIC supporting; so, this is= the main target. DAs with non DOIC client would be more for a transition= (to be considered nevertheless and which may be long). The current text says that DA is acting on behalf of "A" client; so princip= le with host OLR per DOIC association also applies, and there is no differ= ence for the server, as this does not make a difference between a DOIC sup= porting client and a DA supporting non DOIC clients. Nevertheless, and here I come to Steve's point, this has a cost implying = the DA to manage OLRs per client. Steve introduces an optimization where i= n fact a set of clients are considered for me as a pool regarding DOIC whe= re only one OLR applies and where throttling applies to the requests of t= his pool of clients. I am not against to optimization process but this = pool concept is new and needs some further study. First about the concept o= f DOIC association which evolves , as now linked to a pool . There was a MCruz remark about sequence number, a new AVP or a new report = type. I see that we may have to review the processing of the seq number = handling as also dependent of the new AVP or the OLR type; so a "collate= ral " effect of the optimization. I would also think that, instead of intro= ducing a single node indication in the OLR (AVP or report type) , it should= be a global indication as the optimization is to support a global DOIC a= ssociation. To also see if there are not other collateral effects to analy= ze. Ulrich also mentioned that for realm OLRs we may also have a different re= alm OLR sent to different clients, so this is the same principle as Lionel= for a realm OLR per DOIC association, on which I agree. The current text due to the DOIC association principle, allows this realm = OLR per DOIC association for both DOIC supporting clients and DAs acting= on behalf of A client. Then I expect Steve to do the same remark, with th= e same reason to have an optimization where all clients receives the s= ame realm OLR, but to also see the collateral effects. As a conclusion, I think we should remain with the current text as the base= line, following the DOIC association principle that Lionel mentions, and af= ter more investigation to assess the optimization for host and realm OLRs= with DA supporting non DOIC, this optimization being optional. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 25 f=E9vrier 2014 10:09 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Yes, I agree with Steve. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 24 de febrero de 2014 20:24 To: lionel.morand@orange.com; dime@ietf.or= g Subject: Re: [Dime] Issue#35 conclusion Lionel, The question is whether the reporting node is sending the overload report p= er client or it is sending a global overload report that applies to all cli= ents. I still believe that the default behavior of a reporting node will be to ha= ve a single overload reduction value for the application and that that over= load reduction value will apply to all clients. If this is the case then t= here is little benefit (and significant overhead) to requiring an agent to = maintain state per non-supporting client. I also agree that there is value to the reporting node being able to have a= different reduction value for specific reacting nodes. If this is the cas= e then the reporting node should indicate that it only applies to the origi= n-host in the request and only then should agents be required to maintain s= tate for the non-supporting client. Steve On 2/24/14 12:57 PM, lionel.morand@orange.com wrote: I really don't understand but it is not the first time :) What about the DOIC association? What about my assumption about agent maint= aining overload control state for non-DOIC enabled client? So for me, the proposal from Ulrich is a clarification on the agent behavio= r that was implicit if you consider the comments above. For me, the option for the server is only to send a specific OLR for a spec= ific client. So over two different DOIC association with the same server/re= porting node, you can have two different OLRs. But it does not change the way the OLR is handled by reacting nodes. Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 24 f=E9vrier 2014 19:50 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Maria Cruz, To the degree possible we should minimize the per application overload logi= c required. To this end, it would be better to have this as part of the ba= se specification, as it is likely that most/all applications will want the = same behavior. Whether a reporting node uses per Origin-Host reports is an implementation = detail of the reporting node. How reacting nodes respond to per Origin-Hos= t reports should be specified in a common way. Steve On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote: Hello again, I forgot to mention something else in this thread, that I already mentioned= in related thread #56. This is all in order to take into account 3GPP requirement on overload miti= gation differentiation per client. But this is a server option: TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio= ns to decide when and whether overload mitigation differentiation per clien= t is used". Therefore, we can even consider this new OLR out of the base draft, and be = considered by 3GPP applications when required. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: lunes, 24 de febrero de 2014 19:19 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Steve, all, I agree with Steve. However, I would like to share one concern. We need to avoid that existing = (if any) host OLR ("all-client") in the reacting node is replaced by new ho= st OLR (per client). Host OLR (per client) with the new AVP requires that the server uses a new = sequence number, but existing host OLR (all) shall not be replaced, on the = contrary both Host OLR (all) and new Host OLR (per client) should remain. In order to achieve this, it could be more convenient to use a dedicated OL= R type (host per client), instead of a new AVP. Let me know your opinions. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 24 de febrero de 2014 16:56 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Adding an AVP to indicate that a report applies just to the Origin-Host in = the request is not just an optimization for agents. It had been my assumption all along that the default behavior of a reportin= g node (server) would be to report a single overload value to all reacting = nodes, be they clients or agents. If this is the default behavior then it = would be best to have the default, implicit, meaning of an overload report = to be "applies to all reacting nodes". The real value of this new feature = is to allow a server to further throttle a specific, overly active, reactin= g node when then global reduction percentage doesn't do the job. In addition, if the normal case is that reporting nodes have a single globa= l reduction percentage then requiring agents to bind an overload report to = each non supporting clients pushes a lot of extra work on agents when it ad= ds no value. My proposal is the following: - Add an optional AVP (call it something like Single-Node???) to overload r= eports that indicate when an overload report applies to a specific reacting= node. - Absence of the AVP indicates that the report applies to all reacting node= s (clients and agents acting on behalf of non-DOIC clients). - Reporting nodes should only include the Single-Node AVP if the overload r= eport contents are different from the global overload report. - DOIC-supporting agents receiving an OLR without the Single-Node AVP must = do the following: - For transactions from DOIC-supporting clients the agent must not act on= the OLR. - For transactions from non-DOIC-supporting clients the agent must apply = the OLR to traffic from the set of non supporting clients. This implies t= hat when making throttling decisions, the agent does not differentiate whic= h non supporting client originated the request. - DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr= ansaction originated by a non supporting client must bind that OLR to that = single client. Note that the agent behavior is currently something that is missing from th= e -01 version of the draft. We will need something like this wording indep= endent of the resolution of this issue. Steve On 2/24/14 8:06 AM, lionel.morand@orange.com wrote: Is it implicit? If the agent detects that a client is not supporting DOIC, this agent will = have to store the corresponding overload control state on behalf of this cl= ient and only this client (saying that other clients may support DOIC). I'm= assuming then that any agent will have to store somewhere the origin-host = of this client. And therefore, I don't see what would be the added-value of= this AVP saying that this OLR is only for this client. Even if this AVP is present, it would not preclude a reporting node to alwa= ys put this AVP in every answer, even if the OLR is the same for all the cl= ients. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lundi 24 f=E9vrier 2014 14:27 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Hello Ulrich, I haven't proposed to limit this to host type OLR, I just wanted to clarify= if this is what JJ got in mind. I agree it could be done as you explained in the example below, but the ope= n question is whether it is better to add an AVP when OLR is just meant for= one single client, or on the contrary the agent _always_ need to bind OLR = to one specific client, even if the server simply requires same OLR for any= client. I think having a new AVP simplifies agent behavior. Best regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: lunes, 24 de febrero de 2014 14:19 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] Issue#35 conclusion Hi MCruz, there is no reason to limit this to host type OLRs. If we have an agent A that is configured to take the role of the reporting = node for realm-type reports for realm R, A could receive host type OLRs fro= m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc= tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)= ; A then would aggregate these info and return realm type OLRs to C1 reques= ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct= ion of traffic from C2 to R. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Monday, February 24, 2014 2:02 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hello JJ and all, As per email thread, the latest proposal is: "When an agent takes the role of a reacting node, the agent needs to bind a= received OLR to the origin host of the client that initiated the request w= hich corresponds to the answer containing the OLR." An Ulrich comments on this: "This would cover not only the case where an agent takes the role of the re= acting node on behalf of a (or several) non supporting client, but also the= case where an agent is configured to take the role of a reporting node (fo= r realm-type reports) towards the client and at the same time the role of a= reacting node towards the server." Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: lunes, 24 de febrero de 2014 13:43 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi Mcruz and all I think that you are mixing the case of the DA that is the "reporting" nod= e which wants to indicate a realm OLR to clients, and for which will use va= rious (non standardized ) ways to determine among which it can reuse the Ho= st-OLR AVPs received from various servers. But in this case, clients receiv= ing realm OLRs are supporting DOIC. Here I understand the on going discussion is about the DA behavior when c= lients is not supporting DOIC and to reuse the Host-OLR received for one cl= ient for other clients . For me I remain on my previous mail, with a baseline solution. We may alwa= ys study new extensions, optimizations, but priority should be on the basel= ine. Best regards Jacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome= Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Hello all, Not sure we all have the same understanding here. Let me try to explain my concerns. The original 3GPP requirement we want to cover is the need for a server to = reduce traffic for one specific client, i.e. traffic identified by "Origin-= Host" in the request. Then, two options are under analysis about whether or not the OLR in the se= rver answer shall be marked: a) OLR does not need to include anything else Receiver of the answer (and O= LR) is the client that sends the request, identified by "Origin-Host" in th= e request. Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti= on is performed and requirement fulfilled. But, when an agent is acting on behalf of a client as the reacting node, th= en the "Origin-Host" identifies final client, but not the reacting node. Then, this is why the proposal is to add following clarification about agen= t behavior (possible clause 5.5): "When an agent takes the role of a reacting node, the agent needs to bind a= received OLR to the origin host of the client that initiated the request w= hich corresponds to the answer containing the OLR." But this will imply that _always_ the reacting node applies this OLR to one= specific client, what is not what we need to achieve. How will this impact the case where the agent is providing access to a Real= m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll= owing example: - C1 sends a Realm request via Agent, that finally reaches S1 - S1 answers with OLR (Host:50%). - Agent is acting as reacting node on behalf of C1, if it considers this OL= R only bind to C1... then... should it consider S1-OLR only as relevant for= requests coming from C1? Should agent do not use this S1-OLR to calculate = aggregated Realm overload? In my opinion, in this case it does not make sense to consider OLR was only= meant to C1. And this problem could be solved adding explicit information,= as in b) below. b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H= ost" in the request) from which traffic reduction shall apply. With this new AVP, reacting node will easy be able to identify when OLR sha= ll be applied to any client or just to the Origin-Host identified by new AV= P. Let me know your opinions please Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: lunes, 24 de febrero de 2014 12:28 To: ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Steve, please see inline. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Friday, February 21, 2014 4:53 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Ulrich, I have a couple of concerns with this approach, as currently outlined. First, how do we handle the case where there are multiple DOIC supporting a= gents between the non supporting client and the reporting node. This, I gu= ess, is a general question, not just applying to this proposal. I suggest = we capture in the agent behavior section that is currently missing wording = indicating that the first supporting agent that receives the request must b= e the reacting node for that non-supporting client. Subsequent DOIC suppor= ting agents must not be the reacting node for the non-supporting client. I fully agree We need to think through the ramifications of having multiple agents being = the reacting node for the same non supporting clients, as this could easily= happen in networks where multiple agents are involved in a single transact= ion. On the surface it doesn't seem to be an issue for the loss algorithm,= but this might not be the case with other algorithms. I agree that this is not an issue for loss; it is an issue e.g. for= rate (i.e. for draft-donovan-dime-doc-rate-control) My other concern is that this puts a lot of extra onus on the agent even fo= r the case where the reporting node does not want to differentiate overload= reports. I agree To this end I suggest we add an indication in the OLR marking the reports t= hat are specific to just the Origin-Host in the request. Absence of the "s= ingle-client-only" AVP would mean that the report applies to all clients. = Presence of the AVP would indicate that the OLR applies to the Origin-Host. I understand that the proposal is an optimization for agents. There= fore the semantics of the marking should be reverse: unmarked OLRs are clie= nt specific, marked OLRs indicate that the reporting node does not want to = differentiate, and therefore allow agents not to do the binding to the clie= nt. Steve On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Ben, the proposed conclusion was based on comments received so far (from Lionel,= Nirav, Steve, MCruz, JJ). Now you seem to address two points: a) There is no dependency to DOIC support of the client. To address this I would like to propose rewording of the clarifying text fo= r 5.5. as follows: When an agent takes the role of a reacting node, the agent needs to bind a = received OLR to the origin host of the client that initiated the request wh= ich corresponds to the answer containing the OLR. This would cover not only the case where an agent takes the role of the rea= cting node on behalf of a (or several) non supporting client, but also the = case where an agent is configured to take the role of a reporting node (for= realm-type reports) towards the client and at the same time the role of a = reacting node towards the server. b) There is no binding of the OLR to the orig-host of the client Here I dis= agree. We have the 3GPP requirement to allow requesting different amount of= reduction from different clients, and I think we have 3 options: 1. ignore the 3GPP requirement 2. introduce new report types as originally proposed in #35 3. introduce th= e binding between OLR and orig-host of the client. So far I understood that people favoured option 3. See also inline. Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com] Sent: Thursday, February 20, 2014 11:55 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: #35: additional report types are proposed Dear all, I believe we can conclude, not to add additional report types. However, we = agreed to add clarifying text to clause 5.5 as follows: When an agent received an OLR in response to a request initiated by a clien= t not supporting DOIC, this agent needs to bind the received OLR to the ori= gin-host of the client. I do not agree. You proposal implies that the server's OLR only applies to that client. exactly, that was the intention If there's an intervening= DOIC agent, then the agent, not the client, is the reacting node from the = server's perspective. the server's perspective is agnostic. The server does not know whe= ther it's the client or an agent on the path that takes the role of the rea= cting node But, short of adding an origin-host type, nothing bind= s the OLR to a particular client, regardless of DOIC support at the clients= . the binding is always there, regardless of DOIC support at the cli= ent Whether or not the client also supports DOIC doesn't change that. For DOIC= -supporting clients, the agent has the additional option of reducing traffi= c by asking the clients to reduce traffic (making them reacting nodes from = the perspective of the _agent_, but not the server.) It doesn't have that = option for non-DOIC clients. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_E194C2E18676714DACA9C3A2516265D20266D671FR712WXCHMBA12z_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all<= /p>

 <= /p>

Hereafter several points =  about some collateral consequences of the Ticket #35 proposal

 <= /p>

1)  &= nbsp;   Besides the comme= nted  point 3, I have a similar comment for point 1. I have a client A= with a per client type  (0) active OLR having a high reduction % (90%) , then the  DA receives an OLR client (1) to update % for all= nodes with a small % (10%). According to  rule 1 , client A has now&n= bsp; 10% reduction:  this will create  a burst of traffic. &= nbsp; I assume that very soon after  it will receive  a new OLR t= ype (0) with 90% but this rule is something creating transient  traffic&n= bsp; bursts in an overload situation which is not our aim. So, we may modif= y the rule 1 eg by stating  “A fresh OLR of type (1) makes all old type (1) OLRs  invalid and leave = unchanged clients with a OLR type(0)”. But not sure the story is fini= shed., if later the specific peak vanishes and the server wants to handle c= lient A as other nodes,  what does the server do? Due to my new rule, server  sending an OLR type (1) does not solv= e this point, but we would like to avoid a server to continue to send OLR t= ype (0),to this client as there is no more specificity

-      =     We may use  = the validity period of 0, but  it means no more overload

-      =     the other way is = first  to use a OLR type(0) with short validity expiration period (and= a value of 10% to align)) and to add a new  rule: “if an OLR(0) expires for a client, , and if an OLR type (1) exist for other clients, th= e OLR type(1) applies to this client.   

 <= /p>

 

2)  &= nbsp;   A clarification i= f I have the right understanding

When DA receives the firs= t OLR type (1) with a new seq number in an answer to a client A , this OLR = type (1) immediately applies to all nodes (apart those with a OLR type(0) active, cf above), taking into account that DA will then rec= eives  other answers to client B, C… with the same OLR type (1) = and the same seq number should be the same, as long as there is no modif br= ought to OLR type(1). May be also some text to avoid misunderstanding would be need to avoid a wrong seq numbr handlin= g  Do you agree?

 <= /p>

3)  &= nbsp;   Another point: wh= en I consider the target network in the future where there are only DOIC cl= ients, why to continue to send a mandatory OLR which  shall always be ignored…. I would prefer to have  no such OLR a= t all, meaning to introduce a non mandatory OLR AVP with a default value wh= en no present. As in the target network, the Host OLR is  per client, = default value would be (0). Views?

 <= /p>

4)  &= nbsp;   Regarding DOIC as= sociation, here we have an information (OLR with type (1)  exchanged i= nside  a DOIC association that applies to many DOIC associations. = ; It is possible but it should be highlighted .

 <= /p>

5)  &= nbsp;   I also saw Mcruz = had a preferencee for another OLR type and not a new AVP, have  we con= cluded on this .

 <= /p>

What are your views? Thes= e are not blocking points, there is always some solution by adding new rule= s. Nevertheless I am always cautious when a new AVP is introduced, as it always creates new combinational cases, that we have to analyse . So= is this optimization actually needed. If yes, we need to add the right rul= es to avoid unexpected  situations and  misunderstanding

 <= /p>

Best regards<= o:p>

 

JJacques

 

 

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 27 f=E9vrier 2014 21:11
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

 

I think if you change= number three to the following then it works better.

  3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for = the client to which the answer message is being routed.  The agent sha= ll apply the OLR or type (0) for traffic from that client. The old OLR of t= ype (1) continues to apply for all clients that do not have a "per client" overload report.

I think it is important for a reporting node to be able to start with an &q= uot;all clients" overload report and then transition to "per clie= nt" reports for chatty clients.

Steve

On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN - DE/Munich)= wrote:

Dear MCruz,

 <= /p>

certainly a valid point. = I don’t have a strong view but I wanted to avoid the mixture to keep = things simple.

Maybe we should forbid th= e change from 1 to 0 during an ongoing overload.

 <= /p>

Anyway, I don’t thi= nk this is a blocking point for the proposal to add the new AVP.

 <= /p>

Best regards<= /o:p>

Ulrich<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Thursday, February 27, 2014 5:13 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Dear Ulrich,<= /o:p>

 <= /p>

Being:<= /p>

(0)   OLR per client

(1)   OLR for all clients

 <= /p>

Some comments on the inte= ractions you mentioned:

1.      A fresh OLR of type (1) = makes all old OLRs of any type invalid

2.      A fresh OLR of type (0) = makes an old OLR of type (0) bound to the same client invalid

3.      A fresh OLR of type (0) = makes an old OLR of type (1) invalid

 <= /p>

I do not think 3) is righ= t. Why an OLR per one specific client shall invalidate OLRs for rest of cli= ents? This will imply that rest of clients will not have any overload mitigation on until they receive a new value of (1), or (0) f= or each of them.

 <= /p>

Best regards<= /o:p>

/MCruz<= /p>

 <= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: mi=E9rcoles, 26 de febrero de 2014 12:23
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Hi JJacques,

 <= /p>

thank you for the summary= .

 <= /p>

I think it does not matte= r whether we call

A)     “OLR per cli= ent” the base solution and “OLR for all clients” the opti= mization or

B)    “OLR for all clien= ts” the base solution and “OLR per client” the (3GPP) ext= ension

as long as we cover both.=

 <= /p>

I don’t think there= are impacts on sequence number handling, report types or DOIC associations= .

 <= /p>

My proposal then is to ad= d a new mandatory AVP of type enumerated to OC-OLR with values<= /o:p>

(0)   OLR per client

(1)   OLR for all clients

 <= /p>

Reporting nodes that bett= er like A) could allways send (0) unless they support the “optimizati= on” and want to use it;

Reporting nodes that bett= er like B) could allways send (1) unless they support the “(3GPP) ext= ension” and want to use it.

Clients can safely ignore= the new AVP.

Agents taking the role of= the reacting node on behalf of a client must do the binding when receiving= (0).

 <= /p>

We also need to say somet= hing on interactions e.g.:

A fresh OLR of type (1) m= akes all old OLRs of any type invalid

A fresh OLR of type (0) m= akes an old OLR of type (0) bound to the same client invalid

A fresh OLR of type (0) m= akes an old OLR of type (1) invalid

 <= /p>

(i.e. change of type is a= llowed, mixture is not allowed)

 <= /p>

Ulrich<= /p>

 <= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, February 26, 2014 8:07 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Hi Steve, MCruz and all

 <= /p>

On my side,  I agree= with Lionel.

 <= /p>

I  have not the &nbs= p;same reading of the draft where I have  not found the Steve’s = default case.

I agree with Lionel that = the OLR for a DOIC association relates to this DOIC association  and t= he OLR can be different  for another DOIC association. The basic (or “default”) principle is that each DOIC association has its= “own life”.

 <= /p>

Then,  a server (loc= al policy) can decide  to send  the same OLR to all its clients (= so for all its DOIC associations) , or it can define  particular OLR v= alues for   certain clients.

Another  interest &n= bsp;is that  when the server wants to update the OLR values towards &n= bsp;clients, it is  not obliged to send the new values  simultane= ously  to all the clients : it may  (local server policy) progressively  chang= e  the  value  over a certain duration  to minimize &nb= sp;sharp transitions.

 <= /p>

So for DOIC supporting cl= ients, the current text allows these possibilities, and in particular it sa= tisfies the 3GGP client mitigation requirement.

 <= /p>

A second step is to addre= ss DAs supporting non DOIC clients. Over time,  we may expect that cli= ents will be more and more DOIC supporting; so, this is the main target. DAs with non DOIC client would be more for   a transitio= n (to be considered  nevertheless and which may be long).<= /o:p>

 <= /p>

The current text says tha= t DA is acting on behalf of “A” client; so principle  with= host OLR per DOIC association also applies, and there is no difference for the server, as this does not make a difference  between a DOIC suppor= ting client and a DA supporting non DOIC clients.

Nevertheless, and here I = come to Steve’s point,   this has a cost implying the DA to= manage OLRs per client. Steve  introduces an optimization where in fa= ct a set of clients are considered for me as a pool regarding  DOIC wher= e only one OLR applies and where throttling  applies  to the requ= ests of this  pool of clients.  I am not against to optimization = process   but this pool concept is new and needs some further study. First about the concept of DOIC association which evolves , as now = linked to a pool .

 <= /p>

There was a MCruz remark = about sequence number, a new AVP or a  new report type.  I see th= at  we may have to review  the processing of the seq number  = ;handling as also dependent of the new AVP or the OLR type; so   a “= collateral “ effect of the optimization. I would also think that, ins= tead of introducing a single node indication in the OLR (AVP or report type= ) , it should be a global indication as the optimization   is to support a global DOIC association.  To also see if = there are not other collateral effects to analyze.

 <= /p>

Ulrich  also mention= ed that for realm OLRs we may also have  a different realm  OLR s= ent to different clients, so this is the same principle as Lionel  for  a realm OLR per DOIC association, on which I agree.

 <= /p>

The current text due to t= he DOIC association principle,  allows this realm OLR per DOIC associa= tion for both  DOIC  supporting clients and  DAs acting on b= ehalf of A client. Then I expect Steve  to do the same remark, with the sam= e reason  to have  an optimization  where all clients receiv= es  the  same realm OLR, but to also see the collateral effects.

 <= /p>

As a conclusion, I think = we should remain with the current text as the baseline, following the DOIC = association principle that Lionel mentions, and after more investigation to assess the  optimization  for host and realm OL= Rs with DA supporting non DOIC,  this optimization being optional.

 <= /p>

Best regards<= /span>

 =

JJacques

 =

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 f=E9vrier 2014 10:09
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion
=

 

Yes, I agree with Steve.<= /span>

 <= /p>

Best regards<= /o:p>

/MCruz<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange= .com; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Lionel,

The question is whether the reporting node is sending the overload report p= er client or it is sending a global overload report that applies to all cli= ents. 

I still believe that the default behavior of a reporting node will be to ha= ve a single overload reduction value for the application and that that over= load reduction value will apply to all clients.  If this is the case t= hen there is little benefit (and significant overhead) to requiring an agent to maintain state per non-supporting clien= t.

I also agree that there is value to the reporting node being able to have a= different reduction value for specific reacting nodes.  If this is th= e case then the reporting node should indicate that it only applies to the = origin-host in the request and only then should agents be required to maintain state for the non-supporting client.=

Steve

On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:

I really don't understand= but it is not the first time J

 <= /p>

What about the DOIC assoc= iation? What about my assumption about agent maintaining overload control s= tate for non-DOIC enabled client?

So for me, the proposal f= rom Ulrich is a clarification on the agent behavior that was implicit if yo= u consider the comments above.

 <= /p>

For me, the option for th= e server is only to send a specific OLR for a specific client. So over two = different DOIC association with the same server/reporting node, you can have two different OLRs.

But it does not change th= e way the OLR is handled by reacting nodes.

 <= /p>

Lionel=

 =

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 :
dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion
=

 

Maria Cruz,

To the degree possible we should minimize the per application overload logi= c required.  To this end, it would be better to have this as part of t= he base specification, as it is likely that most/all applications will want= the same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation = detail of the reporting node.  How reacting nodes respond to per Origi= n-Host reports should be specified in a common way.

Steve

On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:

Hello= again,

 = ;

I for= got to mention something else in this thread, that I already mentioned in r= elated thread #56.

 = ;

This = is all in order to take into account 3GPP requirement on overload mitigatio= n differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It= may be up to the server/agent implementations to decide when and whether o= verload mitigation differentiation per client is used".

 

Therefore, we can even consider this= new OLR out of the base draft, and be considered by 3GPP applications when= required.

 

Best regards

/MCruz

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Steve, all,


I agree with Steve.

 <= /p>

However, I would like to = share one concern. We need to avoid that existing (if any) host OLR (“= ;all-client”) in the reacting node is replaced by new host OLR (per client).

Host OLR (per client) wit= h the new AVP requires that the server uses a new sequence number, but exis= ting host OLR (all) shall not be replaced, on the contrary both Host OLR (all) and new Host OLR (per client) should remain.

In order to achieve this,= it could be more convenient to use a dedicated OLR type (host per client),= instead of a new AVP.

 <= /p>

Let me know your opinions= .

Best regards<= /o:p>

/MCruz<= /p>

 <= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Adding an AVP to indi= cate that a report applies just to the Origin-Host in the request is not ju= st an optimization for agents.

It had been my assumption all along that the default behavior of a reportin= g node (server) would be to report a single overload value to all reacting = nodes, be they clients or agents.  If this is the default behavior the= n it would be best to have the default, implicit, meaning of an overload report to be "applies to all reactin= g nodes".  The real value of this new feature is to allow a serve= r to further throttle a specific, overly active, reacting node when then gl= obal reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa= l reduction percentage then requiring agents to bind an overload report to = each non supporting clients pushes a lot of extra work on agents when it ad= ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r= eports that indicate when an overload report applies to a specific reacting= node.

- Absence of the AVP indicates that the report applies to all reacting node= s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r= eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must = do the following:
  - For transactions from DOIC-supporting clients the agent must not a= ct on the OLR.
  - For transactions from non-DOIC-supporting clients the agent must a= pply the OLR to traffic from the set of non supporting clients.   This= implies that when making throttling decisions, the agent does not differen= tiate which non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr= ansaction originated by a non supporting client must bind that OLR to that = single client.

Note that the agent behavior is currently something that is missing from th= e -01 version of the draft.  We will need something like this wording = independent of the resolution of this issue.

Steve

On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

I=
s it implicit? 
&=
nbsp;
I=
f the agent detects that a client is not supporting DOIC, this agent will h=
ave to store the corresponding overload control state on behalf of this cli=
ent and only this client (saying that other clients may support DOIC). I'm =
assuming then that any agent will have to store somewhere the origin-host o=
f this client. And therefore, I don't see what would be the added-value of =
this AVP saying that this OLR is only for this client.
&=
nbsp;
E=
ven if this AVP is present, it would not preclude a reporting node to alway=
s put this AVP in every answer, even if the OLR is the same for all the cli=
ents.
&=
nbsp;
Regards,
 
Lionel
 
-----Message d'origine-----<=
/span>
De : DiME [mailto:dime-bounces@ietf.org] De la par=
t de Maria Cruz Bartolome
Envoy=E9 : lundi 24 f=E9vrier 2014 14:27
=C0 : d=
ime@ietf.org
O=
bjet : Re: [Dime] Issue#35 conclusion
&=
nbsp;
H=
ello Ulrich,
&=
nbsp;
I=
 haven't proposed to limit this to host type OLR, I just wanted to clarify =
if this is what JJ got in mind.
&=
nbsp;
I=
 agree it could be done as you explained in the example below, but the open=
 question is whether it is better to add an AVP when OLR is just meant for =
one single client, or on the contrary the agent _always_ need to bind OLR t=
o one specific client, even if the server simply requires same OLR for any =
client. 
&=
nbsp;
I=
 think having a new AVP simplifies agent behavior.
&=
nbsp;
B=
est regards
/=
MCruz
&=
nbsp;
-=
----Original Message-----
F=
rom: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: lunes, 24 de febrero de 2014 14:19
T=
o: Maria Cruz Bartolome; dime@ietf.org=
S=
ubject: RE: [Dime] Issue#35 conclusion
&=
nbsp;
H=
i MCruz,
t=
here is no reason to limit this to host type OLRs.
&=
nbsp;
I=
f we have an agent A that is configured to take the role of the reporting n=
ode for realm-type reports for realm R, A could receive host type OLRs from=
 servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduct=
ion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2);=
 A then would aggregate these info and return realm type OLRs to C1 request=
ing 20% reduction of traffic from C1 to R, and to C2 requesting 30% reducti=
on of traffic from C2 to R.
&=
nbsp;
B=
est regards
U=
lrich
&=
nbsp;
-=
----Original Message-----
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Maria Cruz Bartolome
S=
ent: Monday, February 24, 2014 2:02 PM
T=
o: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
H=
ello JJ and all,
&=
nbsp;
A=
s per email thread, the latest proposal is:
&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR." 
&=
nbsp;
A=
n Ulrich comments on this:
&=
quot;This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server."
&=
nbsp;
I=
s your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
B=
est regards
/=
MCruz
&=
nbsp;
-=
----Original Message-----
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
T=
o: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
H=
i Mcruz and all
&=
nbsp;
I=
 think that you are  mixing the case of the DA that is the "repor=
ting" node which wants to indicate a realm OLR to clients, and for whi=
ch will use various (non standardized ) ways to determine among which it ca=
n reuse the Host-OLR AVPs received from various servers. But in this case, =
clients receiving realm OLRs are supporting DOIC. 
H=
ere I understand the on going  discussion is about the DA behavior whe=
n  clients is not supporting DOIC and to reuse the Host-OLR received f=
or one client for other clients  .
&=
nbsp;
F=
or me I remain on  my previous mail, with a baseline solution. We may =
always study new extensions, optimizations, but priority should be on the b=
aseline.
&=
nbsp;
Best regards
 
Jacques 
 
   
 
-----Message d'origine-----<=
/span>
De : DiME [mailto:dime-bounces@ietf.org] De la par=
t de Maria Cruz Bartolome Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0=
 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion
 
H=
ello all,
&=
nbsp;
N=
ot sure we all have the same understanding here.
L=
et me try to explain my concerns.
&=
nbsp;
T=
he original 3GPP requirement we want to cover is the need for a server to r=
educe traffic for one specific client, i.e. traffic identified by "Ori=
gin-Host" in the request.
T=
hen, two options are under analysis about whether or not the OLR in the ser=
ver answer shall be marked:
&=
nbsp;
a=
) OLR does not need to include anything else Receiver of the answer (and OL=
R) is the client that sends the request, identified by "Origin-Host&qu=
ot; in the request.
T=
hen, as long as the reacting node=3D=3D"Origin-Host", the expecte=
d reduction is performed and requirement fulfilled.
B=
ut, when an agent is acting on behalf of a client as the reacting node, the=
n the "Origin-Host" identifies final client, but not the reacting=
 node.
T=
hen, this is why the proposal is to add following clarification about agent=
 behavior (possible clause 5.5):
&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR."
B=
ut this will imply that _always_ the reacting node applies this OLR to one =
specific client, what is not what we need to achieve.
H=
ow will this impact the case where the agent is providing access to a Realm=
? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider f=
ollowing example:
-=
 C1 sends a Realm request via Agent, that finally reaches S1
-=
 S1 answers with OLR (Host:50%).
-=
 Agent is acting as reacting node on behalf of C1, if it considers this OLR=
 only bind to C1... then... should it consider S1-OLR only as relevant for =
requests coming from C1? Should agent do not use this S1-OLR to calculate a=
ggregated Realm overload?
I=
n my opinion, in this case it does not make sense to consider OLR was only =
meant to C1. And this problem could be solved adding explicit information, =
as in b) below.
&=
nbsp;
b=
) OLR needs to be extended (new AVP) that identifies the client ("Orig=
in-Host" in the request) from which traffic reduction shall apply.
W=
ith this new AVP, reacting node will easy be able to identify when OLR shal=
l be applied to any client or just to the Origin-Host identified by new AVP=
.
&=
nbsp;
L=
et me know your opinions please
B=
est regards
/=
MCruz
&=
nbsp;
&=
nbsp;
&=
nbsp;
-=
----Original Message-----
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
T=
o: ext Steve Donovan; dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
S=
teve,
&=
nbsp;
p=
lease see inline.
&=
nbsp;
U=
lrich
&=
nbsp;
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Steve Donovan
S=
ent: Friday, February 21, 2014 4:53 PM
T=
o: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
U=
lrich,
&=
nbsp;
I=
 have a couple of concerns with this approach, as currently outlined. =
 
&=
nbsp;
F=
irst, how do we handle the case where there are multiple DOIC supporting ag=
ents between the non supporting client and the reporting node.  This, =
I guess, is a general question, not just applying to this proposal.  I=
 suggest we capture in the agent behavior section that is currently missing=
 wording indicating that the first supporting agent that receives the reque=
st must be the reacting node for that non-supporting client.  Subseque=
nt DOIC supporting agents must not be the reacting node for the non-support=
ing client.
&=
lt;Ulrich>I fully agree</Ulrich>
&=
nbsp;
&=
nbsp;
W=
e need to think through the ramifications of having multiple agents being t=
he reacting node for the same non supporting clients, as this could easily =
happen in networks where multiple agents are involved in a single transacti=
on.  On the surface it doesn't seem to be an issue for the loss algori=
thm, but this might not be the case with other algorithms.
&=
lt;Ulrich>I agree that this is not an issue for loss; it is an issue e.g=
. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>
&=
nbsp;
M=
y other concern is that this puts a lot of extra onus on the agent even for=
 the case where the reporting node does not want to differentiate overload =
reports.
&=
lt;Ulrich> I agree </Ulrich>
T=
o this end I suggest we add an indication in the OLR marking the reports th=
at are specific to just the Origin-Host in the request.  Absence of th=
e "single-client-only" AVP would mean that the report applies to =
all clients.  Presence of the AVP would indicate that the OLR applies =
to the Origin-Host.
&=
lt;Ulrich>I understand that the proposal is an optimization for agents. =
Therefore the semantics of the marking should be reverse: unmarked OLRs are=
 client specific, marked OLRs indicate that the reporting node does not wan=
t to differentiate, and therefore allow agents not to do the binding to the=
 client.</Ulrich>     
&=
nbsp;
S=
teve
O=
n 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:=
B=
en,
&=
nbsp;
t=
he proposed conclusion was based on comments received so far (from Lionel, =
Nirav, Steve, MCruz, JJ). 
N=
ow you seem to address two points:
a=
) There is no dependency to DOIC support of the client.
T=
o address this I would like to propose rewording of the clarifying text for=
 5.5. as follows:
&=
nbsp;
W=
hen an agent takes the role of a reacting node, the agent needs to bind a r=
eceived OLR to the origin host of the client that initiated the request whi=
ch corresponds to the answer containing the OLR. 
&=
nbsp;
T=
his would cover not only the case where an agent takes the role of the reac=
ting node on behalf of a (or several) non supporting client, but also the c=
ase where an agent is configured to take the role of a reporting node (for =
realm-type reports) towards the client and at the same time the role of a r=
eacting node towards the server.
&=
nbsp;
b=
) There is no binding of the OLR to the orig-host of the client Here I disa=
gree. We have the 3GPP requirement to allow requesting different amount of =
reduction from different clients, and I think we have 3 options:
1=
. ignore the 3GPP requirement
2=
. introduce new report types as originally proposed in #35 3. introduce the=
 binding between OLR and orig-host of the client.
&=
nbsp;
S=
o far I understood that people favoured option 3.
&=
nbsp;
S=
ee also inline.
&=
nbsp;
U=
lrich
&=
nbsp;
&=
nbsp;
&=
nbsp;
-=
----Original Message-----
F=
rom: ext Ben Campbell [mailto:ben@nostru=
m.com]
S=
ent: Thursday, February 20, 2014 11:55 PM
T=
o: Wiehe, Ulrich (NSN - DE/Munich)
C=
c: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
&=
nbsp;
O=
n Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
&=
nbsp;
#=
35: additional report types are proposed
 =
D=
ear all,
 =
I=
 believe we can conclude, not to add additional report types. However, we a=
greed to add clarifying text to clause 5.5 as follows:
 =
W=
hen an agent received an OLR in response to a request initiated by a client=
 not supporting DOIC, this agent needs to bind the received OLR to the orig=
in-host of the client.
&=
nbsp;
I=
 do not agree.
&=
nbsp;
Y=
ou proposal implies that the server's OLR only applies to that client.
&=
lt;Ulrich>exactly, that was the intention</Ulrich>  If there'=
s an intervening DOIC agent, then the agent, not the client, is the reactin=
g node from the server's perspective.
&=
lt;Ulrich> the server's perspective is agnostic. The server does not kno=
w whether it's the client or an agent on the path that takes the role of th=
e reacting node</Ulrich>  But, short of adding an origin-host ty=
pe, nothing binds the OLR to a particular client, regardless of DOIC suppor=
t at the clients.
&=
lt;Ulrich> the binding is always there, regardless of DOIC support at th=
e client</Ulrich>
&=
nbsp;
 =
Whether or not the client also supports DOIC doesn't change that. For DOIC-=
supporting clients, the agent has the additional option of reducing traffic=
 by asking the clients to reduce traffic (making them reacting nodes from t=
he perspective of the _agent_, but not the server.)  It doesn't have t=
hat option for non-DOIC clients.
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_______________________________________________
DiME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
/span>
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">htt=
ps://www.ietf.org/mailman/listinfo/dime=
 
________________________________________________________________=
_________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;

 




_______________________________________________
DiME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
/span>
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">htt=
ps://www.ietf.org/mailman/listinfo/dime=

 

________________________________________________________________=
_________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.

 




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime

 

--_000_E194C2E18676714DACA9C3A2516265D20266D671FR712WXCHMBA12z_-- From nobody Tue Mar 4 06:58:36 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223441A0125 for ; Tue, 4 Mar 2014 06:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoZWZ0QsFB_I for ; Tue, 4 Mar 2014 06:58:30 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE9B1A00B9 for ; Tue, 4 Mar 2014 06:58:29 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s24EwKCD025234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 15:58:21 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s24EwK0Z002234 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 15:58:20 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Tue, 4 Mar 2014 15:58:20 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: ext Steve Donovan , ext Ben Campbell Thread-Topic: [Dime] Issue#30 status Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EvEWgP4lzthw/EteSAD4lZZwkPErMq2A4lZTnEDErLODgIlZVFNQkrKjP4ClZTCjoA== Date: Tue, 4 Mar 2014 14:58:18 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <530E04E2.2070405@usdonovans.com> <1A8ECF14-0E9E-41BE-B627-1CE58C0701AA@nostrum.com> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54E2@DEMUMBX014.nsn-intra.net> <5315BEB1.4080109@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B5519@DEMUMBX014.nsn-intra.net> <5315D2E9.2050205@usdonovans.com> In-Reply-To: <5315D2E9.2050205@usdonovans.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.100] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B559FDEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 17371 X-purgate-ID: 151667::1393945101-00003660-7757FF8B/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qPoOSdJfwaZrqsCCpDGm9-6xoUs Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 14:58:34 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B559FDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Steve, I m trying to progress this. As you say we don't have consensus on the question whether capability exch= ange should be kept separate from overload reports or not. Let's focus on this issue. Once this issue is resolved we will know whether a) OC-Supported-Features conveys the selected features and is used together= with the OLR to interprete the meaning of the OLR, or b) OC-Supported-Features conveys the supported features (and would be sent = for information, the reason being just because people decided so) Ulrich From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Tuesday, March 04, 2014 2:20 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list Subject: Re: [Dime] Issue#30 status Ulrich, We've already discussed this. I understand that you don't think that the OC-Supported-Features AVP should= be required in all answer messages. Others of us think that it should be. We can't make progress if we have to= re-debate every point multiple times. I suggest that we follow Jouni's guidance made a few emails back and move o= n. Steve On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: From: ext Steve Donovan [mailto:srdonovan@usdonovans.com] Sent: Tuesday, March 04, 2014 12:53 PM To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list Subject: Re: [Dime] Issue#30 status It serves to tell the reacting node that the reporting node supports DOIC, = the features that the two nodes have in common and the abatement algorithm = that the reporting node will be using. ...so that the the reacting = node can - based on that information - do what? I agree that capability exchange should be kept separate from overload repo= rts. We don't, however, have consensus on this point.Is it only Jo= uni who wants this dependency? Steve On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: I agree with Ben But then again: which purpose does OC-Supported-Features I answer serve? Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com] Sent: Tuesday, March 04, 2014 12:34 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.o= rg list Subject: Re: [Dime] Issue#30 status On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Steve, I'm trying to understand the principles. Is it so that we have two usecases= for OC-Supported-Features AVP in an answer message: a) if the answer does not contain an OLR then OC-Supported-Features contain= s all features the reporting node supports (or all features the reporting n= ode and the reacting node commonly support (what would be the difference fr= om the reacting node's point of view?)) b) if the answer contains an OLR then the OC-Supported-Features contains th= e selected features (selected from the set of features advertised in the re= quest); any inconsistency (e.g. more than one abatement alogorithm; somethi= ng is selected that was not advertised) would result in ignoring the OLR. IMO, OC-Supported-Features should be treated as a) in all cases. If we need= information about the specific selections made for a particular OLR, that = info belongs in the OLR. For b), if the OLR is a replay, I guess the selected features in OC-Support= ed-Features must also not change (and should be ignored together with the O= LR). That would be mostly irrelevant if the we put OLR selections in the OLR, so= long as the generally advertised features in OC-Supported-Features do not = change in a way that makes the OLR no longer valid. Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D9000668151B559FDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

I m trying= to progress this.

 = ;

As you say= we don’t have consensus on the question  whether capability exc= hange should be kept separate from overload reports or not.

 = ;

Let’= s focus on this issue.

 = ;

Once this = issue is resolved we will know whether

a) OC-Supp= orted-Features conveys the selected features and is used together with the = OLR to interprete the meaning of the OLR, or

b) OC-Supp= orted-Features conveys the supported features (and would be sent for inform= ation, the reason being just because people decided so)

 = ;

Ulrich

 = ;

 = ;

 = ;

 = ;

 = ;

From:= ext Steve Donovan [= mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 04, 2014 2:20 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

 

Ulrich,

We've already discussed this.

I understand that you don't think that the OC-Supported-Features AVP should= be required in all answer messages.

Others of us think that it should be.  We can't make progress if we ha= ve to re-debate every point multiple times.

I suggest that we follow Jouni's guidance made a few emails back and move o= n.

Steve

On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) = wrote:

 <= /p>

 <= /p>

From:= ext Steve Donovan [= mailto:srdonovan@usdonovans.com= ]
Sent: Tuesday, March 04, 2014 12:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

 

= It serves to tell the reacting node that the reporting node supports DOIC, = the features that the two nodes have in common and the abatement algorithm = that the reporting node will be using. <Ulrich>…so that the the reacting node can – based on th= at information – do what?</Ulrich>

I agree that capability exchange should be kept separate from overload repo= rts.  We don't, however, have consensus on this point.
<Ulrich>Is it only Jouni wh= o wants this  dependency?</Ulrich>

Steve

On 3/4/14 11:43 AM, Wiehe, Ulri= ch (NSN - DE/Munich) wrote:

I agree with Ben
 
But then again: which purpose does OC-Supported-F=
eatures I answer serve?
Ulrich
 
-----Original Message-----
From: ext Ben Campbell [mailto:ben@=
nostrum.com] 
Sent: Tuesday, March 04, 2014 12:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status
 
 
On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
 
Steve,
I'm trying to understand the principles. Is it so that we have two use=
cases for OC-Supported-Features AVP in an answer message:
a) if the answer does not contain an OLR then OC-Supported-Features co=
ntains all features the reporting node supports (or all features the report=
ing node and the reacting node commonly support (what would be the differen=
ce from the reacting node's point of view?))
b) if the answer contains an OLR then the OC-Supported-Features contai=
ns the selected features (selected from the set of features advertised in t=
he request); any inconsistency (e.g. more than one abatement alogorithm; so=
mething is selected that was not advertised) would result in ignoring the O=
LR.
 
IMO, OC-Supported-Features should be treated as a) in all cases. If we=
 need information about the specific selections made for a particular OLR, =
that info belongs in the OLR.
 
 
For b), if the OLR is a replay, I guess the selected features in OC-Su=
pported-Features must also not change (and should be ignored together with =
the OLR).
 
That would be mostly irrelevant if the we put OLR selections in the OL=
R, so long as the generally advertised features in OC-Supported-Features do=
 not change in a way that makes the OLR no longer valid.
 
 
Ulrich
 
 

 

 

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B559FDEMUMBX014nsnin_-- From nobody Tue Mar 4 07:44:05 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB29A1A00F5 for ; Tue, 4 Mar 2014 07:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id epEin1YLL3Fa for ; Tue, 4 Mar 2014 07:43:55 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 4406D1A0117 for ; Tue, 4 Mar 2014 07:43:55 -0800 (PST) Received: from [130.129.63.247] (port=54548 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WKrVR-0002Z1-1O; Tue, 04 Mar 2014 07:43:50 -0800 Message-ID: <5315F4B0.9010902@usdonovans.com> Date: Tue, 04 Mar 2014 15:43:44 +0000 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Ben Campbell References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@DEMUMBX014.nsn-intra.net> <602542051F40544EB188D494F506C24947930EA5@G9W0747.americas.hpqcorp.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B4D91@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B510E@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D9000668151B5166@DEMUMBX014.nsn-intra.net> <531482DB.4030609@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B51BE@DEMUMBX014.nsn-in! tra.net> <5314C842.5040105@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54C4@DEMUMBX014.nsn-intra.net> <7DD3A8C9-0610-4C40-87AF-A16559A1AA93@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B54E2@DEMUMBX014.nsn-intra.net> <5315BEB1.4080109@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B5519@DEMUMBX014.nsn-intra.net> <5315D2E9.2050205@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------010104010008090605060804" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Archived-At: http://mailarchive.ietf.org/arch/msg/dime/znFWOiO5WGFfT3wdaaXmHnMVj80 Cc: "dime@ietf.org list" Subject: Re: [Dime] Issue#30 status X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:43:59 -0000 This is a multi-part message in MIME format. --------------010104010008090605060804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich, I don't see that the two questions overlap. If we go with a) then the OC-Supported-Features could only be required in answers with an OC-OLR AVP. This by itself would not be the reason for OC-Supported-Features to be included in all messages, which is the proposal. In addition, the reason is not "just because people decided too". The reasons, as previously discussed, are: 1) To be consistent with the pattern already established for feature capabilities negotiation. 2) As part of the extensibility design, as we know of cases where reacting nodes will need to understand the abatement algorithm in advance. 3) As a tool for reacting nodes to handle situations where there are no DOIC capable nodes. I believe there is also fourth reason I've come across as I have been thinking about the definition of overload endpoints. The case where some servers support DOIC and some servers do not support DOIC. In this scenario, agents will be expected to take on the roll of the reporting node for non supporting servers. For the servers that support DOIC the server will be the reporting node. The agent needs the OC-Supported-Features AVP to be able to determine which set of servers support DOIC and which do not. Steve On 3/4/14 2:58 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > Steve, > > I m trying to progress this. > > > > As you say we don't have consensus on the question whether capability > exchange should be kept separate from overload reports or not. > > > > Let's focus on this issue. > > > > Once this issue is resolved we will know whether > > a) OC-Supported-Features conveys the selected features and is used > together with the OLR to interprete the meaning of the OLR, or > > b) OC-Supported-Features conveys the supported features (and would be > sent for information, the reason being just because people decided so) > > > > Ulrich > > > > > > > > > > > > *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* Tuesday, March 04, 2014 2:20 PM > *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell > *Cc:* ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list > *Subject:* Re: [Dime] Issue#30 status > > > > Ulrich, > > We've already discussed this. > > I understand that you don't think that the OC-Supported-Features AVP > should be required in all answer messages. > > Others of us think that it should be. We can't make progress if we > have to re-debate every point multiple times. > > I suggest that we follow Jouni's guidance made a few emails back and > move on. > > Steve > > On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > > > > > *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com] > *Sent:* Tuesday, March 04, 2014 12:53 PM > *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell > *Cc:* ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org > list > *Subject:* Re: [Dime] Issue#30 status > > > > It serves to tell the reacting node that the reporting node > supports DOIC, the features that the two nodes have in common and > the abatement algorithm that the reporting node will be > using.*/...so that the the reacting node can -- based on > that information -- do what?/* > > I agree that capability exchange should be kept separate from > overload reports. We don't, however, have consensus on this > point.*/Is it only Jouni who wants this > dependency?/* > > Steve > > On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > I agree with Ben > > > > But then again: which purpose does OC-Supported-Features I answer serve? > > Ulrich > > > > -----Original Message----- > > From: ext Ben Campbell [mailto:ben@nostrum.com] > > Sent: Tuesday, March 04, 2014 12:34 PM > > To: Wiehe, Ulrich (NSN - DE/Munich) > > Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list > > Subject: Re: [Dime] Issue#30 status > > > > > > On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: > > > > Steve, > > I'm trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message: > > a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node's point of view?)) > > b) if the answer contains an OLR then the OC-Supported-Features contains the selected features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; something is selected that was not advertised) would result in ignoring the OLR. > > > > IMO, OC-Supported-Features should be treated as a) in all cases. If we need information about the specific selections made for a particular OLR, that info belongs in the OLR. > > > > > > For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR). > > > > That would be mostly irrelevant if the we put OLR selections in the OLR, so long as the generally advertised features in OC-Supported-Features do not change in a way that makes the OLR no longer valid. > > > > > > Ulrich > > > > > > > > > --------------010104010008090605060804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ulrich,

I don't see that the two questions overlap.  If we go with a) then the OC-Supported-Features could only be required in answers with an OC-OLR AVP.  This by itself would not be the reason for OC-Supported-Features to be included in all messages, which is the proposal.

In addition, the reason is not "just because people decided too".  The reasons, as previously discussed, are:

1) To be consistent with the pattern already established for feature capabilities negotiation.
2) As part of the extensibility design, as we know of cases where reacting nodes will need to understand the abatement algorithm in advance.
3) As a tool for reacting nodes to handle situations where there are no DOIC capable nodes.

I believe there is also fourth reason I've come across as I have been thinking about the definition of overload endpoints.

The case where some servers support DOIC and some servers do not support DOIC.  In this scenario, agents will be expected to take on the roll of the reporting node for non supporting servers.  For the servers that support DOIC the server will be the reporting node.  The agent needs the OC-Supported-Features AVP to be able to determine which set of servers support DOIC and which do not.

Steve

On 3/4/14 2:58 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Steve,

I m trying to progress this.

 

As you say we don’t have consensus on the question  whether capability exchange should be kept separate from overload reports or not.

 

Let’s focus on this issue.

 

Once this issue is resolved we will know whether

a) OC-Supported-Features conveys the selected features and is used together with the OLR to interprete the meaning of the OLR, or

b) OC-Supported-Features conveys the supported features (and would be sent for information, the reason being just because people decided so)

 

Ulrich

 

 

 

 

 

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 04, 2014 2:20 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

 

Ulrich,

We've already discussed this.

I understand that you don't think that the OC-Supported-Features AVP should be required in all answer messages.

Others of us think that it should be.  We can't make progress if we have to re-debate every point multiple times.

I suggest that we follow Jouni's guidance made a few emails back and move on.

Steve

On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

 

 

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 04, 2014 12:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status

 

It serves to tell the reacting node that the reporting node supports DOIC, the features that the two nodes have in common and the abatement algorithm that the reporting node will be using. <Ulrich>…so that the the reacting node can – based on that information – do what?</Ulrich>

I agree that capability exchange should be kept separate from overload reports.  We don't, however, have consensus on this point.
<Ulrich>Is it only Jouni who wants this  dependency?</Ulrich>

Steve

On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

I agree with Ben
 
But then again: which purpose does OC-Supported-Features I answer serve?
Ulrich
 
-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Tuesday, March 04, 2014 12:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status
 
 
On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
 
Steve,
I'm trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message:
a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node's point of view?))
b) if the answer contains an OLR then the OC-Supported-Features contains the selected features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; something is selected that was not advertised) would result in ignoring the OLR.
 
IMO, OC-Supported-Features should be treated as a) in all cases. If we need information about the specific selections made for a particular OLR, that info belongs in the OLR.
 
 
For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR).
 
That would be mostly irrelevant if the we put OLR selections in the OLR, so long as the generally advertised features in OC-Supported-Features do not change in a way that makes the OLR no longer valid.
 
 
Ulrich
 
 

 

 


--------------010104010008090605060804-- From nobody Tue Mar 4 07:44:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E5C1A01C5 for ; Tue, 4 Mar 2014 07:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJGtWqgCNdpn for ; Tue, 4 Mar 2014 07:44:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 83E691A00F5 for ; Tue, 4 Mar 2014 07:44:26 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-04-5315f4d69a93 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8B.2D.23809.6D4F5135; Tue, 4 Mar 2014 16:44:22 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Tue, 4 Mar 2014 16:44:21 +0100 From: Maria Cruz Bartolome To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" Thread-Topic: [Dime] Issue#35 conclusion Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0D/9p5E0A== Date: Tue, 4 Mar 2014 15:44:20 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209789198@ESESSMB101.ericsson.se> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209787161@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2@DEMUMBX014.nsn-intra.net> <530F9BC3.1010003@usdonovans.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209789198ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvje61L6LBBpO6VS3m9q5gs9h0fh2L A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4MpoPXeAueDUCc6Kc1caGRsY+zZzdDFyckgI mEhsmzWJDcIWk7hwbz2QzcUhJHCIUaJ/2mRmCGcRo8SrM3fAqtgE7CQunX7BBGKLCJRLbG0+ wQJiCwuoS9z5foEVIq4h0fjmEztIs4jAOUaJp8vnADVzcLAIqEj8Xm8MUsMr4Csx+ds/JogF tzgkVj3dxwyS4BSIlbi+HWIZI9BJ30+tAVvGLCAucevJfCaIUwUkluw5zwxhi0q8fPyPFcJW klh7eDsLRH2+xOH2mewQywQlTs58wjKBUWQWklGzkJTNQlIGEdeTuDF1ChuErS2xbOFrZghb V2LGv0MsyOILGNlXMbLnJmbmpJcbbWIExtDBLb9VdzDeOSdyiFGag0VJnPfDW+cgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYwMlZLFc2O08h9NPv/SN6KotME7x5P3qUtCSrV42A/xh9P/ /95xMeFl4+y98QcFC9d+PrlLPsfC74lmlHwzwxHO+7/W86ev8DD7w/zm155Ls9bVb6vuXhG+ vdXzb3tl397l7KJnT/dO2/XxfuXpIO3vdUUTPYRNdkfveWQd8qCg0qx5QcupQ1+UWIozEg21 mIuKEwEKSoA+bwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DGalJjr9YrQH5Z4EwRSt6EJ46WY Subject: Re: [Dime] Issue#35 conclusion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:44:47 -0000 --_000_087A34937E64E74E848732CFF8354B9209789198ESESSMB101erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello JJ, Interesting analysis. In relation to points 2 and 4, now we have uniqueness of Sequence Number de= fined as: "The sequence number is only required to be unique between two overload control endpoints" If we keep this, it means that for each endpoint (i.e. for each answer to c= lients B, C...) sequence number may be different, and if the answer is mean= t for "all-clients", then reacting node will need to read every new answer = (that corresponds to a request from a different client), even if OLR is not= modified. I presume this is acceptable, since default case is meant to be = "one-client", what fits our endpoint definition. About 1, I think that if we define that both "one-client" and "all-client" = reports can coexist, and if so "one-client" takes precedence over "all-clie= nt" it solves the issue you highlighted. About 3, I agree that taking into account endpoint definition, default valu= e is "per client". I would agree on your proposal. About 5, having new report types or new AVP, I think requires same cases to= be studied. I cannot see a clear advantage of one of them over the other. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: martes, 04 de marzo de 2014 14:35 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi all Hereafter several points about some collateral consequences of the Ticket = #35 proposal 1) Besides the commented point 3, I have a similar comment for point = 1. I have a client A with a per client type (0) active OLR having a high r= eduction % (90%) , then the DA receives an OLR client (1) to update % for = all nodes with a small % (10%). According to rule 1 , client A has now 10= % reduction: this will create a burst of traffic. I assume that very so= on after it will receive a new OLR type (0) with 90% but this rule is som= ething creating transient traffic bursts in an overload situation which i= s not our aim. So, we may modify the rule 1 eg by stating "A fresh OLR of = type (1) makes all old type (1) OLRs invalid and leave unchanged clients w= ith a OLR type(0)". But not sure the story is finished., if later the speci= fic peak vanishes and the server wants to handle client A as other nodes, = what does the server do? Due to my new rule, server sending an OLR type (1= ) does not solve this point, but we would like to avoid a server to continu= e to send OLR type (0),to this client as there is no more specificity - We may use the validity period of 0, but it means no more overlo= ad - the other way is first to use a OLR type(0) with short validity e= xpiration period (and a value of 10% to align)) and to add a new rule: "if= an OLR(0) expires for a client, , and if an OLR type (1) exist for other c= lients, the OLR type(1) applies to this client. 2) A clarification if I have the right understanding When DA receives the first OLR type (1) with a new seq number in an answer = to a client A , this OLR type (1) immediately applies to all nodes (apart t= hose with a OLR type(0) active, cf above), taking into account that DA will= then receives other answers to client B, C... with the same OLR type (1) = and the same seq number should be the same, as long as there is no modif br= ought to OLR type(1). May be also some text to avoid misunderstanding would= be need to avoid a wrong seq numbr handling Do you agree? 3) Another point: when I consider the target network in the future whe= re there are only DOIC clients, why to continue to send a mandatory OLR whi= ch shall always be ignored.... I would prefer to have no such OLR at all,= meaning to introduce a non mandatory OLR AVP with a default value when no = present. As in the target network, the Host OLR is per client, default val= ue would be (0). Views? 4) Regarding DOIC association, here we have an information (OLR with t= ype (1) exchanged inside a DOIC association that applies to many DOIC ass= ociations. It is possible but it should be highlighted . 5) I also saw Mcruz had a preferencee for another OLR type and not a n= ew AVP, have we concluded on this . What are your views? These are not blocking points, there is always some so= lution by adding new rules. Nevertheless I am always cautious when a new AV= P is introduced, as it always creates new combinational cases, that we have= to analyse . So is this optimization actually needed. If yes, we need to a= dd the right rules to avoid unexpected situations and misunderstanding Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 27 f=E9vrier 2014 21:11 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion I think if you change number three to the following then it works better. 3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for the c= lient to which the answer message is being routed. The agent shall apply t= he OLR or type (0) for traffic from that client. The old OLR of type (1) co= ntinues to apply for all clients that do not have a "per client" overload r= eport. I think it is important for a reporting node to be able to start with an "a= ll clients" overload report and then transition to "per client" reports for= chatty clients. Steve On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Dear MCruz, certainly a valid point. I don't have a strong view but I wanted to avoid t= he mixture to keep things simple. Maybe we should forbid the change from 1 to 0 during an ongoing overload. Anyway, I don't think this is a blocking point for the proposal to add the = new AVP. Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Thursday, February 27, 2014 5:13 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Dear Ulrich, Being: (0) OLR per client (1) OLR for all clients Some comments on the interactions you mentioned: 1. A fresh OLR of type (1) makes all old OLRs of any type invalid 2. A fresh OLR of type (0) makes an old OLR of type (0) bound to the sa= me client invalid 3. A fresh OLR of type (0) makes an old OLR of type (1) invalid I do not think 3) is right. Why an OLR per one specific client shall invali= date OLRs for rest of clients? This will imply that rest of clients will no= t have any overload mitigation on until they receive a new value of (1), or= (0) for each of them. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: mi=E9rcoles, 26 de febrero de 2014 12:23 To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi JJacques, thank you for the summary. I think it does not matter whether we call A) "OLR per client" the base solution and "OLR for all clients" the opti= mization or B) "OLR for all clients" the base solution and "OLR per client" the (3GP= P) extension as long as we cover both. I don't think there are impacts on sequence number handling, report types o= r DOIC associations. My proposal then is to add a new mandatory AVP of type enumerated to OC-OLR= with values (0) OLR per client (1) OLR for all clients Reporting nodes that better like A) could allways send (0) unless they supp= ort the "optimization" and want to use it; Reporting nodes that better like B) could allways send (1) unless they supp= ort the "(3GPP) extension" and want to use it. Clients can safely ignore the new AVP. Agents taking the role of the reacting node on behalf of a client must do t= he binding when receiving (0). We also need to say something on interactions e.g.: A fresh OLR of type (1) makes all old OLRs of any type invalid A fresh OLR of type (0) makes an old OLR of type (0) bound to the same clie= nt invalid A fresh OLR of type (0) makes an old OLR of type (1) invalid (i.e. change of type is allowed, mixture is not allowed) Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA= CQUES (JEAN-JACQUES) Sent: Wednesday, February 26, 2014 8:07 AM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi Steve, MCruz and all On my side, I agree with Lionel. I have not the same reading of the draft where I have not found the Stev= e's default case. I agree with Lionel that the OLR for a DOIC association relates to this DOI= C association and the OLR can be different for another DOIC association. = The basic (or "default") principle is that each DOIC association has its "o= wn life". Then, a server (local policy) can decide to send the same OLR to all its= clients (so for all its DOIC associations) , or it can define particular = OLR values for certain clients. Another interest is that when the server wants to update the OLR values = towards clients, it is not obliged to send the new values simultaneously= to all the clients : it may (local server policy) progressively change = the value over a certain duration to minimize sharp transitions. So for DOIC supporting clients, the current text allows these possibilities= , and in particular it satisfies the 3GGP client mitigation requirement. A second step is to address DAs supporting non DOIC clients. Over time, we= may expect that clients will be more and more DOIC supporting; so, this is= the main target. DAs with non DOIC client would be more for a transition= (to be considered nevertheless and which may be long). The current text says that DA is acting on behalf of "A" client; so princip= le with host OLR per DOIC association also applies, and there is no differ= ence for the server, as this does not make a difference between a DOIC sup= porting client and a DA supporting non DOIC clients. Nevertheless, and here I come to Steve's point, this has a cost implying = the DA to manage OLRs per client. Steve introduces an optimization where i= n fact a set of clients are considered for me as a pool regarding DOIC whe= re only one OLR applies and where throttling applies to the requests of t= his pool of clients. I am not against to optimization process but this = pool concept is new and needs some further study. First about the concept o= f DOIC association which evolves , as now linked to a pool . There was a MCruz remark about sequence number, a new AVP or a new report = type. I see that we may have to review the processing of the seq number = handling as also dependent of the new AVP or the OLR type; so a "collate= ral " effect of the optimization. I would also think that, instead of intro= ducing a single node indication in the OLR (AVP or report type) , it should= be a global indication as the optimization is to support a global DOIC a= ssociation. To also see if there are not other collateral effects to analy= ze. Ulrich also mentioned that for realm OLRs we may also have a different re= alm OLR sent to different clients, so this is the same principle as Lionel= for a realm OLR per DOIC association, on which I agree. The current text due to the DOIC association principle, allows this realm = OLR per DOIC association for both DOIC supporting clients and DAs acting= on behalf of A client. Then I expect Steve to do the same remark, with th= e same reason to have an optimization where all clients receives the s= ame realm OLR, but to also see the collateral effects. As a conclusion, I think we should remain with the current text as the base= line, following the DOIC association principle that Lionel mentions, and af= ter more investigation to assess the optimization for host and realm OLRs= with DA supporting non DOIC, this optimization being optional. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 25 f=E9vrier 2014 10:09 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Yes, I agree with Steve. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 24 de febrero de 2014 20:24 To: lionel.morand@orange.com; dime@ietf.or= g Subject: Re: [Dime] Issue#35 conclusion Lionel, The question is whether the reporting node is sending the overload report p= er client or it is sending a global overload report that applies to all cli= ents. I still believe that the default behavior of a reporting node will be to ha= ve a single overload reduction value for the application and that that over= load reduction value will apply to all clients. If this is the case then t= here is little benefit (and significant overhead) to requiring an agent to = maintain state per non-supporting client. I also agree that there is value to the reporting node being able to have a= different reduction value for specific reacting nodes. If this is the cas= e then the reporting node should indicate that it only applies to the origi= n-host in the request and only then should agents be required to maintain s= tate for the non-supporting client. Steve On 2/24/14 12:57 PM, lionel.morand@orange.com wrote: I really don't understand but it is not the first time :) What about the DOIC association? What about my assumption about agent maint= aining overload control state for non-DOIC enabled client? So for me, the proposal from Ulrich is a clarification on the agent behavio= r that was implicit if you consider the comments above. For me, the option for the server is only to send a specific OLR for a spec= ific client. So over two different DOIC association with the same server/re= porting node, you can have two different OLRs. But it does not change the way the OLR is handled by reacting nodes. Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 24 f=E9vrier 2014 19:50 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Maria Cruz, To the degree possible we should minimize the per application overload logi= c required. To this end, it would be better to have this as part of the ba= se specification, as it is likely that most/all applications will want the = same behavior. Whether a reporting node uses per Origin-Host reports is an implementation = detail of the reporting node. How reacting nodes respond to per Origin-Hos= t reports should be specified in a common way. Steve On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote: Hello again, I forgot to mention something else in this thread, that I already mentioned= in related thread #56. This is all in order to take into account 3GPP requirement on overload miti= gation differentiation per client. But this is a server option: TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio= ns to decide when and whether overload mitigation differentiation per clien= t is used". Therefore, we can even consider this new OLR out of the base draft, and be = considered by 3GPP applications when required. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: lunes, 24 de febrero de 2014 19:19 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Steve, all, I agree with Steve. However, I would like to share one concern. We need to avoid that existing = (if any) host OLR ("all-client") in the reacting node is replaced by new ho= st OLR (per client). Host OLR (per client) with the new AVP requires that the server uses a new = sequence number, but existing host OLR (all) shall not be replaced, on the = contrary both Host OLR (all) and new Host OLR (per client) should remain. In order to achieve this, it could be more convenient to use a dedicated OL= R type (host per client), instead of a new AVP. Let me know your opinions. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 24 de febrero de 2014 16:56 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Adding an AVP to indicate that a report applies just to the Origin-Host in = the request is not just an optimization for agents. It had been my assumption all along that the default behavior of a reportin= g node (server) would be to report a single overload value to all reacting = nodes, be they clients or agents. If this is the default behavior then it = would be best to have the default, implicit, meaning of an overload report = to be "applies to all reacting nodes". The real value of this new feature = is to allow a server to further throttle a specific, overly active, reactin= g node when then global reduction percentage doesn't do the job. In addition, if the normal case is that reporting nodes have a single globa= l reduction percentage then requiring agents to bind an overload report to = each non supporting clients pushes a lot of extra work on agents when it ad= ds no value. My proposal is the following: - Add an optional AVP (call it something like Single-Node???) to overload r= eports that indicate when an overload report applies to a specific reacting= node. - Absence of the AVP indicates that the report applies to all reacting node= s (clients and agents acting on behalf of non-DOIC clients). - Reporting nodes should only include the Single-Node AVP if the overload r= eport contents are different from the global overload report. - DOIC-supporting agents receiving an OLR without the Single-Node AVP must = do the following: - For transactions from DOIC-supporting clients the agent must not act on= the OLR. - For transactions from non-DOIC-supporting clients the agent must apply = the OLR to traffic from the set of non supporting clients. This implies t= hat when making throttling decisions, the agent does not differentiate whic= h non supporting client originated the request. - DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr= ansaction originated by a non supporting client must bind that OLR to that = single client. Note that the agent behavior is currently something that is missing from th= e -01 version of the draft. We will need something like this wording indep= endent of the resolution of this issue. Steve On 2/24/14 8:06 AM, lionel.morand@orange.com wrote: Is it implicit? If the agent detects that a client is not supporting DOIC, this agent will = have to store the corresponding overload control state on behalf of this cl= ient and only this client (saying that other clients may support DOIC). I'm= assuming then that any agent will have to store somewhere the origin-host = of this client. And therefore, I don't see what would be the added-value of= this AVP saying that this OLR is only for this client. Even if this AVP is present, it would not preclude a reporting node to alwa= ys put this AVP in every answer, even if the OLR is the same for all the cl= ients. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lundi 24 f=E9vrier 2014 14:27 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Hello Ulrich, I haven't proposed to limit this to host type OLR, I just wanted to clarify= if this is what JJ got in mind. I agree it could be done as you explained in the example below, but the ope= n question is whether it is better to add an AVP when OLR is just meant for= one single client, or on the contrary the agent _always_ need to bind OLR = to one specific client, even if the server simply requires same OLR for any= client. I think having a new AVP simplifies agent behavior. Best regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: lunes, 24 de febrero de 2014 14:19 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] Issue#35 conclusion Hi MCruz, there is no reason to limit this to host type OLRs. If we have an agent A that is configured to take the role of the reporting = node for realm-type reports for realm R, A could receive host type OLRs fro= m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc= tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)= ; A then would aggregate these info and return realm type OLRs to C1 reques= ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct= ion of traffic from C2 to R. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Monday, February 24, 2014 2:02 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hello JJ and all, As per email thread, the latest proposal is: "When an agent takes the role of a reacting node, the agent needs to bind a= received OLR to the origin host of the client that initiated the request w= hich corresponds to the answer containing the OLR." An Ulrich comments on this: "This would cover not only the case where an agent takes the role of the re= acting node on behalf of a (or several) non supporting client, but also the= case where an agent is configured to take the role of a reporting node (fo= r realm-type reports) towards the client and at the same time the role of a= reacting node towards the server." Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: lunes, 24 de febrero de 2014 13:43 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi Mcruz and all I think that you are mixing the case of the DA that is the "reporting" nod= e which wants to indicate a realm OLR to clients, and for which will use va= rious (non standardized ) ways to determine among which it can reuse the Ho= st-OLR AVPs received from various servers. But in this case, clients receiv= ing realm OLRs are supporting DOIC. Here I understand the on going discussion is about the DA behavior when c= lients is not supporting DOIC and to reuse the Host-OLR received for one cl= ient for other clients . For me I remain on my previous mail, with a baseline solution. We may alwa= ys study new extensions, optimizations, but priority should be on the basel= ine. Best regards Jacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome= Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Hello all, Not sure we all have the same understanding here. Let me try to explain my concerns. The original 3GPP requirement we want to cover is the need for a server to = reduce traffic for one specific client, i.e. traffic identified by "Origin-= Host" in the request. Then, two options are under analysis about whether or not the OLR in the se= rver answer shall be marked: a) OLR does not need to include anything else Receiver of the answer (and O= LR) is the client that sends the request, identified by "Origin-Host" in th= e request. Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti= on is performed and requirement fulfilled. But, when an agent is acting on behalf of a client as the reacting node, th= en the "Origin-Host" identifies final client, but not the reacting node. Then, this is why the proposal is to add following clarification about agen= t behavior (possible clause 5.5): "When an agent takes the role of a reacting node, the agent needs to bind a= received OLR to the origin host of the client that initiated the request w= hich corresponds to the answer containing the OLR." But this will imply that _always_ the reacting node applies this OLR to one= specific client, what is not what we need to achieve. How will this impact the case where the agent is providing access to a Real= m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll= owing example: - C1 sends a Realm request via Agent, that finally reaches S1 - S1 answers with OLR (Host:50%). - Agent is acting as reacting node on behalf of C1, if it considers this OL= R only bind to C1... then... should it consider S1-OLR only as relevant for= requests coming from C1? Should agent do not use this S1-OLR to calculate = aggregated Realm overload? In my opinion, in this case it does not make sense to consider OLR was only= meant to C1. And this problem could be solved adding explicit information,= as in b) below. b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H= ost" in the request) from which traffic reduction shall apply. With this new AVP, reacting node will easy be able to identify when OLR sha= ll be applied to any client or just to the Origin-Host identified by new AV= P. Let me know your opinions please Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: lunes, 24 de febrero de 2014 12:28 To: ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Steve, please see inline. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Friday, February 21, 2014 4:53 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Ulrich, I have a couple of concerns with this approach, as currently outlined. First, how do we handle the case where there are multiple DOIC supporting a= gents between the non supporting client and the reporting node. This, I gu= ess, is a general question, not just applying to this proposal. I suggest = we capture in the agent behavior section that is currently missing wording = indicating that the first supporting agent that receives the request must b= e the reacting node for that non-supporting client. Subsequent DOIC suppor= ting agents must not be the reacting node for the non-supporting client. I fully agree We need to think through the ramifications of having multiple agents being = the reacting node for the same non supporting clients, as this could easily= happen in networks where multiple agents are involved in a single transact= ion. On the surface it doesn't seem to be an issue for the loss algorithm,= but this might not be the case with other algorithms. I agree that this is not an issue for loss; it is an issue e.g. for= rate (i.e. for draft-donovan-dime-doc-rate-control) My other concern is that this puts a lot of extra onus on the agent even fo= r the case where the reporting node does not want to differentiate overload= reports. I agree To this end I suggest we add an indication in the OLR marking the reports t= hat are specific to just the Origin-Host in the request. Absence of the "s= ingle-client-only" AVP would mean that the report applies to all clients. = Presence of the AVP would indicate that the OLR applies to the Origin-Host. I understand that the proposal is an optimization for agents. There= fore the semantics of the marking should be reverse: unmarked OLRs are clie= nt specific, marked OLRs indicate that the reporting node does not want to = differentiate, and therefore allow agents not to do the binding to the clie= nt. Steve On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Ben, the proposed conclusion was based on comments received so far (from Lionel,= Nirav, Steve, MCruz, JJ). Now you seem to address two points: a) There is no dependency to DOIC support of the client. To address this I would like to propose rewording of the clarifying text fo= r 5.5. as follows: When an agent takes the role of a reacting node, the agent needs to bind a = received OLR to the origin host of the client that initiated the request wh= ich corresponds to the answer containing the OLR. This would cover not only the case where an agent takes the role of the rea= cting node on behalf of a (or several) non supporting client, but also the = case where an agent is configured to take the role of a reporting node (for= realm-type reports) towards the client and at the same time the role of a = reacting node towards the server. b) There is no binding of the OLR to the orig-host of the client Here I dis= agree. We have the 3GPP requirement to allow requesting different amount of= reduction from different clients, and I think we have 3 options: 1. ignore the 3GPP requirement 2. introduce new report types as originally proposed in #35 3. introduce th= e binding between OLR and orig-host of the client. So far I understood that people favoured option 3. See also inline. Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com] Sent: Thursday, February 20, 2014 11:55 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: #35: additional report types are proposed Dear all, I believe we can conclude, not to add additional report types. However, we = agreed to add clarifying text to clause 5.5 as follows: When an agent received an OLR in response to a request initiated by a clien= t not supporting DOIC, this agent needs to bind the received OLR to the ori= gin-host of the client. I do not agree. You proposal implies that the server's OLR only applies to that client. exactly, that was the intention If there's an intervening= DOIC agent, then the agent, not the client, is the reacting node from the = server's perspective. the server's perspective is agnostic. The server does not know whe= ther it's the client or an agent on the path that takes the role of the rea= cting node But, short of adding an origin-host type, nothing bind= s the OLR to a particular client, regardless of DOIC support at the clients= . the binding is always there, regardless of DOIC support at the cli= ent Whether or not the client also supports DOIC doesn't change that. For DOIC= -supporting clients, the agent has the additional option of reducing traffi= c by asking the clients to reduce traffic (making them reacting nodes from = the perspective of the _agent_, but not the server.) It doesn't have that = option for non-DOIC clients. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_087A34937E64E74E848732CFF8354B9209789198ESESSMB101erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello JJ,

 <= /p>

Interesting analysis.

 <= /p>

In relation to points 2 a= nd 4, now we have uniqueness of Sequence Number defined as:

“= ;The sequence number is only

   required to be unique between two overload control e= ndpoints”

 <= /p>

If we keep this, it means= that for each endpoint (i.e. for each answer to clients B, C…) seque= nce number may be different, and if the answer is meant for “all-clie= nts”, then reacting node will need to read every new answer (that corresponds to= a request from a different client), even if OLR is not modified. I presume= this is acceptable, since default case is meant to be “one-client= 221;, what fits our endpoint definition.

 <= /p>

About 1, I think that if = we define that both “one-client” and “all-client” r= eports can coexist, and if so “one-client” takes precedence ove= r “all-client” it solves the issue you highlighted.

 <= /p>

About 3, I agree that tak= ing into account endpoint definition, default value is “per client= 221;. I would agree on your proposal.

 <= /p>

About 5, having new repor= t types or new AVP, I think requires same cases to be studied. I cannot see= a clear advantage of one of them over the other.

 <= /p>

Best regards

/MCruz<= /p>

 <= /p>

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: martes, 04 de marzo de 2014 14:35
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Hi all<= /p>

 <= /p>

Hereafter several points =  about some collateral consequences of the Ticket #35 proposal

 <= /p>

1)  &= nbsp;   Besides the comme= nted  point 3, I have a similar comment for point 1. I have a client A= with a per client type  (0) active OLR having a high reduction % (90%) , then the  DA receives an OLR client (1) to update % for all= nodes with a small % (10%). According to  rule 1 , client A has now&n= bsp; 10% reduction:  this will create  a burst of traffic. &= nbsp; I assume that very soon after  it will receive  a new OLR t= ype (0) with 90% but this rule is something creating transient  traffic&n= bsp; bursts in an overload situation which is not our aim. So, we may modif= y the rule 1 eg by stating  “A fresh OLR of type (1) makes all o= ld type (1) OLRs  invalid and leave unchanged clients with a OLR type(0)”. But not sure the story is finished., if later t= he specific peak vanishes and the server wants to handle client A as other = nodes,  what does the server do? Due to my new rule, server  send= ing an OLR type (1) does not solve this point, but we would like to avoid a server to continue to send OLR type (0),to this c= lient as there is no more specificity

-      =   We may use  = the validity period of 0, but  it means no more overload

-      =   the other way is = first  to use a OLR type(0) with short validity expiration period (and= a value of 10% to align)) and to add a new  rule: “if an OLR(0) expires for a client, , and if an OLR type (1) exist for other clients, th= e OLR type(1) applies to this client.   

 <= /p>

 

2)  &= nbsp;   A clarification i= f I have the right understanding

When DA receives the firs= t OLR type (1) with a new seq number in an answer to a client A , this OLR = type (1) immediately applies to all nodes (apart those with a OLR type(0) active, cf above), taking into account that DA will then rec= eives  other answers to client B, C… with the same OLR type (1) = and the same seq number should be the same, as long as there is no modif br= ought to OLR type(1). May be also some text to avoid misunderstanding would be need to avoid a wrong seq numbr handlin= g  Do you agree?

 <= /p>

3)  &= nbsp;   Another point: wh= en I consider the target network in the future where there are only DOIC cl= ients, why to continue to send a mandatory OLR which  shall always be ignored…. I would prefer to have  no such OLR a= t all, meaning to introduce a non mandatory OLR AVP with a default value wh= en no present. As in the target network, the Host OLR is  per client, = default value would be (0). Views?

 <= /p>

4)  &= nbsp;   Regarding DOIC as= sociation, here we have an information (OLR with type (1)  exchanged i= nside  a DOIC association that applies to many DOIC associations. = ; It is possible but it should be highlighted .

 <= /p>

5)  &= nbsp;   I also saw Mcruz = had a preferencee for another OLR type and not a new AVP, have  we con= cluded on this .

 <= /p>

What are your views? Thes= e are not blocking points, there is always some solution by adding new rule= s. Nevertheless I am always cautious when a new AVP is introduced, as it always creates new combinational cases, that we have to analyse . So= is this optimization actually needed. If yes, we need to add the right rul= es to avoid unexpected  situations and  misunderstanding

 <= /p>

Best regards<= o:p>

 

JJacques

 

 

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 27 f=E9vrier 2014 21:11
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

 

I think if you change= number three to the following then it works better.

  3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for = the client to which the answer message is being routed.  The agent sha= ll apply the OLR or type (0) for traffic from that client. The old OLR of t= ype (1) continues to apply for all clients that do not have a "per client" overload report.

I think it is important for a reporting node to be able to start with an &q= uot;all clients" overload report and then transition to "per clie= nt" reports for chatty clients.

Steve

On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN - DE/Munich)= wrote:

Dear MCruz,

 <= /p>

certainly a valid point. = I don’t have a strong view but I wanted to avoid the mixture to keep = things simple.

Maybe we should forbid th= e change from 1 to 0 during an ongoing overload.

 <= /p>

Anyway, I don’t thi= nk this is a blocking point for the proposal to add the new AVP.

 <= /p>

Best regards<= /o:p>

Ulrich<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Thursday, February 27, 2014 5:13 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Dear Ulrich,<= /o:p>

 <= /p>

Being:<= /p>

(0)  OLR per client

(1)  OLR for all clients

 <= /p>

Some comments on the inte= ractions you mentioned:

1.     A fresh OLR of type (1) = makes all old OLRs of any type invalid

2.     A fresh OLR of type (0) = makes an old OLR of type (0) bound to the same client invalid

3.     A fresh OLR of type (0) = makes an old OLR of type (1) invalid

 <= /p>

I do not think 3) is righ= t. Why an OLR per one specific client shall invalidate OLRs for rest of cli= ents? This will imply that rest of clients will not have any overload mitigation on until they receive a new value of (1), or (0) f= or each of them.

 <= /p>

Best regards<= /o:p>

/MCruz<= /p>

 <= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: mi=E9rcoles, 26 de febrero de 2014 12:23
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Hi JJacques,

 <= /p>

thank you for the summary= .

 <= /p>

I think it does not matte= r whether we call

A)    “OLR per cli= ent” the base solution and “OLR for all clients” the opti= mization or

B)    “OLR for all clien= ts” the base solution and “OLR per client” the (3GPP) ext= ension

as long as we cover both.=

 <= /p>

I don’t think there= are impacts on sequence number handling, report types or DOIC associations= .

 <= /p>

My proposal then is to ad= d a new mandatory AVP of type enumerated to OC-OLR with values<= /o:p>

(0)  OLR per client

(1)  OLR for all clients

 <= /p>

Reporting nodes that bett= er like A) could allways send (0) unless they support the “optimizati= on” and want to use it;

Reporting nodes that bett= er like B) could allways send (1) unless they support the “(3GPP) ext= ension” and want to use it.

Clients can safely ignore= the new AVP.

Agents taking the role of= the reacting node on behalf of a client must do the binding when receiving= (0).

 <= /p>

We also need to say somet= hing on interactions e.g.:

A fresh OLR of type (1) m= akes all old OLRs of any type invalid

A fresh OLR of type (0) m= akes an old OLR of type (0) bound to the same client invalid

A fresh OLR of type (0) m= akes an old OLR of type (1) invalid

 <= /p>

(i.e. change of type is a= llowed, mixture is not allowed)

 <= /p>

Ulrich<= /p>

 <= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, February 26, 2014 8:07 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Hi Steve, MCruz and all

 <= /p>

On my side,  I agree= with Lionel.

 <= /p>

I  have not the &nbs= p;same reading of the draft where I have  not found the Steve’s = default case.

I agree with Lionel that = the OLR for a DOIC association relates to this DOIC association  and t= he OLR can be different  for another DOIC association. The basic (or “default”) principle is that each DOIC association has its= “own life”.

 <= /p>

Then,  a server (loc= al policy) can decide  to send  the same OLR to all its clients (= so for all its DOIC associations) , or it can define  particular OLR v= alues for   certain clients.

Another  interest &n= bsp;is that  when the server wants to update the OLR values towards &n= bsp;clients, it is  not obliged to send the new values  simultane= ously  to all the clients : it may  (local server policy) progressively  chang= e  the  value  over a certain duration  to minimize &nb= sp;sharp transitions.

 <= /p>

So for DOIC supporting cl= ients, the current text allows these possibilities, and in particular it sa= tisfies the 3GGP client mitigation requirement.

 <= /p>

A second step is to addre= ss DAs supporting non DOIC clients. Over time,  we may expect that cli= ents will be more and more DOIC supporting; so, this is the main target. DAs with non DOIC client would be more for   a transitio= n (to be considered  nevertheless and which may be long).<= /o:p>

 <= /p>

The current text says tha= t DA is acting on behalf of “A” client; so principle  with= host OLR per DOIC association also applies, and there is no difference for the server, as this does not make a difference  between a DOIC suppor= ting client and a DA supporting non DOIC clients.

Nevertheless, and here I = come to Steve’s point,   this has a cost implying the DA to= manage OLRs per client. Steve  introduces an optimization where in fa= ct a set of clients are considered for me as a pool regarding  DOIC wher= e only one OLR applies and where throttling  applies  to the requ= ests of this  pool of clients.  I am not against to optimization = process   but this pool concept is new and needs some further study. First about the concept of DOIC association which evolves , as now = linked to a pool .

 <= /p>

There was a MCruz remark = about sequence number, a new AVP or a  new report type.  I see th= at  we may have to review  the processing of the seq number  = ;handling as also dependent of the new AVP or the OLR type; so   a “= collateral “ effect of the optimization. I would also think that, ins= tead of introducing a single node indication in the OLR (AVP or report type= ) , it should be a global indication as the optimization   is to support a global DOIC association.  To also see if = there are not other collateral effects to analyze.

 <= /p>

Ulrich  also mention= ed that for realm OLRs we may also have  a different realm  OLR s= ent to different clients, so this is the same principle as Lionel  for  a realm OLR per DOIC association, on which I agree.

 <= /p>

The current text due to t= he DOIC association principle,  allows this realm OLR per DOIC associa= tion for both  DOIC  supporting clients and  DAs acting on b= ehalf of A client. Then I expect Steve  to do the same remark, with the sam= e reason  to have  an optimization  where all clients receiv= es  the  same realm OLR, but to also see the collateral effects.

 <= /p>

As a conclusion, I think = we should remain with the current text as the baseline, following the DOIC = association principle that Lionel mentions, and after more investigation to assess the  optimization  for host and realm OL= Rs with DA supporting non DOIC,  this optimization being optional.

 <= /p>

Best regards<= /span>

 =

JJacques

 =

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 f=E9vrier 2014 10:09
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion
=

 

Yes, I agree with Steve.<= /span>

 <= /p>

Best regards<= /o:p>

/MCruz<= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange= .com; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Lionel,

The question is whether the reporting node is sending the overload report p= er client or it is sending a global overload report that applies to all cli= ents. 

I still believe that the default behavior of a reporting node will be to ha= ve a single overload reduction value for the application and that that over= load reduction value will apply to all clients.  If this is the case t= hen there is little benefit (and significant overhead) to requiring an agent to maintain state per non-supporting clien= t.

I also agree that there is value to the reporting node being able to have a= different reduction value for specific reacting nodes.  If this is th= e case then the reporting node should indicate that it only applies to the = origin-host in the request and only then should agents be required to maintain state for the non-supporting client.=

Steve

On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:

I really don't understand= but it is not the first time J

 <= /p>

What about the DOIC assoc= iation? What about my assumption about agent maintaining overload control s= tate for non-DOIC enabled client?

So for me, the proposal f= rom Ulrich is a clarification on the agent behavior that was implicit if yo= u consider the comments above.

 <= /p>

For me, the option for th= e server is only to send a specific OLR for a specific client. So over two = different DOIC association with the same server/reporting node, you can have two different OLRs.

But it does not change th= e way the OLR is handled by reacting nodes.

 <= /p>

Lionel=

 =

De = : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 f=E9vrier 2014 19:50
=C0 :
dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion
=

 

Maria Cruz,

To the degree possible we should minimize the per application overload logi= c required.  To this end, it would be better to have this as part of t= he base specification, as it is likely that most/all applications will want= the same behavior.

Whether a reporting node uses per Origin-Host reports is an implementation = detail of the reporting node.  How reacting nodes respond to per Origi= n-Host reports should be specified in a common way.

Steve

On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote:

Hello= again,

 = ;

I for= got to mention something else in this thread, that I already mentioned in r= elated thread #56.

 = ;

This = is all in order to take into account 3GPP requirement on overload mitigatio= n differentiation per client. But this is a server option:

TR 29809 ch. 6.4.7.1 states "It= may be up to the server/agent implementations to decide when and whether o= verload mitigation differentiation per client is used".

 

Therefore, we can even consider this= new OLR out of the base draft, and be considered by 3GPP applications when= required.

 

Best regards

/MCruz

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: lunes, 24 de febrero de 2014 19:19
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Steve, all,


I agree with Steve.

 <= /p>

However, I would like to = share one concern. We need to avoid that existing (if any) host OLR (“= ;all-client”) in the reacting node is replaced by new host OLR (per client).

Host OLR (per client) wit= h the new AVP requires that the server uses a new sequence number, but exis= ting host OLR (all) shall not be replaced, on the contrary both Host OLR (all) and new Host OLR (per client) should remain.

In order to achieve this,= it could be more convenient to use a dedicated OLR type (host per client),= instead of a new AVP.

 <= /p>

Let me know your opinions= .

Best regards<= /o:p>

/MCruz<= /p>

 <= /p>

 <= /p>

From: DiME [ma= ilto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 16:56
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Adding an AVP to indi= cate that a report applies just to the Origin-Host in the request is not ju= st an optimization for agents.

It had been my assumption all along that the default behavior of a reportin= g node (server) would be to report a single overload value to all reacting = nodes, be they clients or agents.  If this is the default behavior the= n it would be best to have the default, implicit, meaning of an overload report to be "applies to all reactin= g nodes".  The real value of this new feature is to allow a serve= r to further throttle a specific, overly active, reacting node when then gl= obal reduction percentage doesn't do the job.

In addition, if the normal case is that reporting nodes have a single globa= l reduction percentage then requiring agents to bind an overload report to = each non supporting clients pushes a lot of extra work on agents when it ad= ds no value.

My proposal is the following:

- Add an optional AVP (call it something like Single-Node???) to overload r= eports that indicate when an overload report applies to a specific reacting= node.

- Absence of the AVP indicates that the report applies to all reacting node= s (clients and agents acting on behalf of non-DOIC clients).

- Reporting nodes should only include the Single-Node AVP if the overload r= eport contents are different from the global overload report.

- DOIC-supporting agents receiving an OLR without the Single-Node AVP must = do the following:
  - For transactions from DOIC-supporting clients the agent must not a= ct on the OLR.
  - For transactions from non-DOIC-supporting clients the agent must a= pply the OLR to traffic from the set of non supporting clients.   This= implies that when making throttling decisions, the agent does not differen= tiate which non supporting client originated the request.

- DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr= ansaction originated by a non supporting client must bind that OLR to that = single client.

Note that the agent behavior is currently something that is missing from th= e -01 version of the draft.  We will need something like this wording = independent of the resolution of this issue.

Steve

On 2/24/14 8:06 AM, lionel.morand@orange.com wrote:

I=
s it implicit? 
&=
nbsp;
I=
f the agent detects that a client is not supporting DOIC, this agent will h=
ave to store the corresponding overload control state on behalf of this cli=
ent and only this client (saying that other clients may support DOIC). I'm =
assuming then that any agent will have to store somewhere the origin-host o=
f this client. And therefore, I don't see what would be the added-value of =
this AVP saying that this OLR is only for this client.
&=
nbsp;
E=
ven if this AVP is present, it would not preclude a reporting node to alway=
s put this AVP in every answer, even if the OLR is the same for all the cli=
ents.
&=
nbsp;
Regards,
 
Lionel
 
-----Message d'origine-----<=
/span>
De : DiME [mailto:dime-bounces@ietf.org] De la par=
t de Maria Cruz Bartolome
Envoy=E9 : lundi 24 f=E9vrier 2014 14:27
=C0 : d=
ime@ietf.org
O=
bjet : Re: [Dime] Issue#35 conclusion
&=
nbsp;
H=
ello Ulrich,
&=
nbsp;
I=
 haven't proposed to limit this to host type OLR, I just wanted to clarify =
if this is what JJ got in mind.
&=
nbsp;
I=
 agree it could be done as you explained in the example below, but the open=
 question is whether it is better to add an AVP when OLR is just meant for =
one single client, or on the contrary the agent _always_ need to bind OLR t=
o one specific client, even if the server simply requires same OLR for any =
client. 
&=
nbsp;
I=
 think having a new AVP simplifies agent behavior.
&=
nbsp;
B=
est regards
/=
MCruz
&=
nbsp;
-=
----Original Message-----
F=
rom: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: lunes, 24 de febrero de 2014 14:19
T=
o: Maria Cruz Bartolome; dime@ietf.org=
S=
ubject: RE: [Dime] Issue#35 conclusion
&=
nbsp;
H=
i MCruz,
t=
here is no reason to limit this to host type OLRs.
&=
nbsp;
I=
f we have an agent A that is configured to take the role of the reporting n=
ode for realm-type reports for realm R, A could receive host type OLRs from=
 servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduct=
ion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2);=
 A then would aggregate these info and return realm type OLRs to C1 request=
ing 20% reduction of traffic from C1 to R, and to C2 requesting 30% reducti=
on of traffic from C2 to R.
&=
nbsp;
B=
est regards
U=
lrich
&=
nbsp;
-=
----Original Message-----
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Maria Cruz Bartolome
S=
ent: Monday, February 24, 2014 2:02 PM
T=
o: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
H=
ello JJ and all,
&=
nbsp;
A=
s per email thread, the latest proposal is:
&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR." 
&=
nbsp;
A=
n Ulrich comments on this:
&=
quot;This would cover not only the case where an agent takes the role of th=
e reacting node on behalf of a (or several) non supporting client, but also=
 the case where an agent is configured to take the role of a reporting node=
 (for realm-type reports) towards the client and at the same time the role =
of a reacting node towards the server."
&=
nbsp;
I=
s your proposal limited to Host-OLR, i.e. Realm OLR is excluded? 
B=
est regards
/=
MCruz
&=
nbsp;
-=
----Original Message-----
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 24 de febrero de 2014 13:43
T=
o: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
H=
i Mcruz and all
&=
nbsp;
I=
 think that you are  mixing the case of the DA that is the "repor=
ting" node which wants to indicate a realm OLR to clients, and for whi=
ch will use various (non standardized ) ways to determine among which it ca=
n reuse the Host-OLR AVPs received from various servers. But in this case, =
clients receiving realm OLRs are supporting DOIC. 
H=
ere I understand the on going  discussion is about the DA behavior whe=
n  clients is not supporting DOIC and to reuse the Host-OLR received f=
or one client for other clients  .
&=
nbsp;
F=
or me I remain on  my previous mail, with a baseline solution. We may =
always study new extensions, optimizations, but priority should be on the b=
aseline.
&=
nbsp;
Best regards
 
Jacques 
 
   
 
-----Message d'origine-----<=
/span>
De : DiME [mailto:dime-bounces@ietf.org] De la par=
t de Maria Cruz Bartolome Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0=
 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion
 
H=
ello all,
&=
nbsp;
N=
ot sure we all have the same understanding here.
L=
et me try to explain my concerns.
&=
nbsp;
T=
he original 3GPP requirement we want to cover is the need for a server to r=
educe traffic for one specific client, i.e. traffic identified by "Ori=
gin-Host" in the request.
T=
hen, two options are under analysis about whether or not the OLR in the ser=
ver answer shall be marked:
&=
nbsp;
a=
) OLR does not need to include anything else Receiver of the answer (and OL=
R) is the client that sends the request, identified by "Origin-Host&qu=
ot; in the request.
T=
hen, as long as the reacting node=3D=3D"Origin-Host", the expecte=
d reduction is performed and requirement fulfilled.
B=
ut, when an agent is acting on behalf of a client as the reacting node, the=
n the "Origin-Host" identifies final client, but not the reacting=
 node.
T=
hen, this is why the proposal is to add following clarification about agent=
 behavior (possible clause 5.5):
&=
quot;When an agent takes the role of a reacting node, the agent needs to bi=
nd a received OLR to the origin host of the client that initiated the reque=
st which corresponds to the answer containing the OLR."
B=
ut this will imply that _always_ the reacting node applies this OLR to one =
specific client, what is not what we need to achieve.
H=
ow will this impact the case where the agent is providing access to a Realm=
? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider f=
ollowing example:
-=
 C1 sends a Realm request via Agent, that finally reaches S1
-=
 S1 answers with OLR (Host:50%).
-=
 Agent is acting as reacting node on behalf of C1, if it considers this OLR=
 only bind to C1... then... should it consider S1-OLR only as relevant for =
requests coming from C1? Should agent do not use this S1-OLR to calculate a=
ggregated Realm overload?
I=
n my opinion, in this case it does not make sense to consider OLR was only =
meant to C1. And this problem could be solved adding explicit information, =
as in b) below.
&=
nbsp;
b=
) OLR needs to be extended (new AVP) that identifies the client ("Orig=
in-Host" in the request) from which traffic reduction shall apply.
W=
ith this new AVP, reacting node will easy be able to identify when OLR shal=
l be applied to any client or just to the Origin-Host identified by new AVP=
.
&=
nbsp;
L=
et me know your opinions please
B=
est regards
/=
MCruz
&=
nbsp;
&=
nbsp;
&=
nbsp;
-=
----Original Message-----
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 24 de febrero de 2014 12:28
T=
o: ext Steve Donovan; dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
S=
teve,
&=
nbsp;
p=
lease see inline.
&=
nbsp;
U=
lrich
&=
nbsp;
F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of ext Steve Donovan
S=
ent: Friday, February 21, 2014 4:53 PM
T=
o: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
U=
lrich,
&=
nbsp;
I=
 have a couple of concerns with this approach, as currently outlined. =
 
&=
nbsp;
F=
irst, how do we handle the case where there are multiple DOIC supporting ag=
ents between the non supporting client and the reporting node.  This, =
I guess, is a general question, not just applying to this proposal.  I=
 suggest we capture in the agent behavior section that is currently missing=
 wording indicating that the first supporting agent that receives the reque=
st must be the reacting node for that non-supporting client.  Subseque=
nt DOIC supporting agents must not be the reacting node for the non-support=
ing client.
&=
lt;Ulrich>I fully agree</Ulrich>
&=
nbsp;
&=
nbsp;
W=
e need to think through the ramifications of having multiple agents being t=
he reacting node for the same non supporting clients, as this could easily =
happen in networks where multiple agents are involved in a single transacti=
on.  On the surface it doesn't seem to be an issue for the loss algori=
thm, but this might not be the case with other algorithms.
&=
lt;Ulrich>I agree that this is not an issue for loss; it is an issue e.g=
. for rate (i.e. for draft-donovan-dime-doc-rate-control)</Ulrich>
&=
nbsp;
M=
y other concern is that this puts a lot of extra onus on the agent even for=
 the case where the reporting node does not want to differentiate overload =
reports.
&=
lt;Ulrich> I agree </Ulrich>
T=
o this end I suggest we add an indication in the OLR marking the reports th=
at are specific to just the Origin-Host in the request.  Absence of th=
e "single-client-only" AVP would mean that the report applies to =
all clients.  Presence of the AVP would indicate that the OLR applies =
to the Origin-Host.
&=
lt;Ulrich>I understand that the proposal is an optimization for agents. =
Therefore the semantics of the marking should be reverse: unmarked OLRs are=
 client specific, marked OLRs indicate that the reporting node does not wan=
t to differentiate, and therefore allow agents not to do the binding to the=
 client.</Ulrich>     
&=
nbsp;
S=
teve
O=
n 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:=
B=
en,
&=
nbsp;
t=
he proposed conclusion was based on comments received so far (from Lionel, =
Nirav, Steve, MCruz, JJ). 
N=
ow you seem to address two points:
a=
) There is no dependency to DOIC support of the client.
T=
o address this I would like to propose rewording of the clarifying text for=
 5.5. as follows:
&=
nbsp;
W=
hen an agent takes the role of a reacting node, the agent needs to bind a r=
eceived OLR to the origin host of the client that initiated the request whi=
ch corresponds to the answer containing the OLR. 
&=
nbsp;
T=
his would cover not only the case where an agent takes the role of the reac=
ting node on behalf of a (or several) non supporting client, but also the c=
ase where an agent is configured to take the role of a reporting node (for =
realm-type reports) towards the client and at the same time the role of a r=
eacting node towards the server.
&=
nbsp;
b=
) There is no binding of the OLR to the orig-host of the client Here I disa=
gree. We have the 3GPP requirement to allow requesting different amount of =
reduction from different clients, and I think we have 3 options:
1=
. ignore the 3GPP requirement
2=
. introduce new report types as originally proposed in #35 3. introduce the=
 binding between OLR and orig-host of the client.
&=
nbsp;
S=
o far I understood that people favoured option 3.
&=
nbsp;
S=
ee also inline.
&=
nbsp;
U=
lrich
&=
nbsp;
&=
nbsp;
&=
nbsp;
-=
----Original Message-----
F=
rom: ext Ben Campbell [mailto:ben@nostru=
m.com]
S=
ent: Thursday, February 20, 2014 11:55 PM
T=
o: Wiehe, Ulrich (NSN - DE/Munich)
C=
c: dime@ietf.org
S=
ubject: Re: [Dime] Issue#35 conclusion
&=
nbsp;
&=
nbsp;
O=
n Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:
&=
nbsp;
#=
35: additional report types are proposed
 =
D=
ear all,
 =
I=
 believe we can conclude, not to add additional report types. However, we a=
greed to add clarifying text to clause 5.5 as follows:
 =
W=
hen an agent received an OLR in response to a request initiated by a client=
 not supporting DOIC, this agent needs to bind the received OLR to the orig=
in-host of the client.
&=
nbsp;
I=
 do not agree.
&=
nbsp;
Y=
ou proposal implies that the server's OLR only applies to that client.
&=
lt;Ulrich>exactly, that was the intention</Ulrich>  If there'=
s an intervening DOIC agent, then the agent, not the client, is the reactin=
g node from the server's perspective.
&=
lt;Ulrich> the server's perspective is agnostic. The server does not kno=
w whether it's the client or an agent on the path that takes the role of th=
e reacting node</Ulrich>  But, short of adding an origin-host ty=
pe, nothing binds the OLR to a particular client, regardless of DOIC suppor=
t at the clients.
&=
lt;Ulrich> the binding is always there, regardless of DOIC support at th=
e client</Ulrich>
&=
nbsp;
 =
Whether or not the client also supports DOIC doesn't change that. For DOIC-=
supporting clients, the agent has the additional option of reducing traffic=
 by asking the clients to reduce traffic (making them reacting nodes from t=
he perspective of the _agent_, but not the server.)  It doesn't have t=
hat option for non-DOIC clients.
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;
_______________________________________________
DiME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
/span>
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">htt=
ps://www.ietf.org/mailman/listinfo/dime=
 
________________________________________________________________=
_________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.
&=
nbsp;
_=
______________________________________________
D=
iME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime
&=
nbsp;

 



_______________________________________________
DiME mailing list
<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
/span>
<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">htt=
ps://www.ietf.org/mailman/listinfo/dime=

 

________________________________________________________________=
_________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informatio=
ns confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vou=
s avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, =
deforme ou falsifie. Merci.
&=
nbsp;
T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law;
t=
hey should not be distributed, used or copied without authorisation.=
I=
f you have received this email in error, please notify the sender and delet=
e this message and its attachments.
A=
s emails may be altered, Orange is not liable for messages that have been m=
odified, changed or falsified.
T=
hank you.

 



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime

 

--_000_087A34937E64E74E848732CFF8354B9209789198ESESSMB101erics_-- From nobody Tue Mar 4 09:07:54 2014 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3B11A0267 for ; Tue, 4 Mar 2014 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i4R22BjiJl4h for ; Tue, 4 Mar 2014 09:06:56 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3681B1A024C for ; Tue, 4 Mar 2014 09:06:55 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 52FC92ACAE0; Tue, 4 Mar 2014 18:06:51 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 2DFA938416B; Tue, 4 Mar 2014 18:06:51 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 18:06:50 +0100 From: To: Maria Cruz Bartolome , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" Thread-Topic: [Dime] Issue#35 conclusion Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0D/9p5E0P/tHNMw Date: Tue, 4 Mar 2014 17:06:50 +0000 Message-ID: <16317_1393952811_5316082B_16317_4358_1_6B7134B31289DC4FAF731D844122B36E4DF9F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784904@ESESSMB101.ericsson.se> <6255_1393250808_530B51F7_6255_2234_1_6B7134B31289DC4FAF731D844122B36E4BB90C@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B6B9D.6010601@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784B4E@ESESSMB101.ericsson.se> <087A34937E64E74E848732CFF8354B9209784B72@ESESSMB101.ericsson.se> <530B9469.4070403@usdonovans.com> <16141_1393268235_530B960B_16141_14014_1_6B7134B31289DC4FAF731D844122B36E4BC596@PEXCVZYM13.corporate.adroot.infra.ftgroup> <530B9C5E.90800@usdonovans.com> <087A34937E64E74E848732CFF8354B9209784EA0@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4999@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209787161@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B4CE2@DEMUMBX014.nsn-intra.net> <530F9BC3.1010003@usdonovans.com> <087A34937E64E74E848732CFF8354B9209789198@ESESSMB101.ericsson.se> In-Reply-To: <087A34937E64E74E848732CFF8354B9209789198@ESESSMB101.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4DF9F3PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.4.80315 Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jYsrhFu390W9yLGtPW2Ga6iWDAA X-Mailman-Approved-At: Tue, 04 Mar 2014 09:07:52 -0800 Subject: Re: [Dime] Issue#35 conclusion X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:07:11 -0000 --_000_6B7134B31289DC4FAF731D844122B36E4DF9F3PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Can someone explain to me what would be the added-value to create two types= of OLR if any reporting node can freely use one or the other? The agent in the middle will have to expect to store OLR for specific non-s= upporting DOIC nodes anyway. So OK, with the new type, time to time, you wi= ll be able to optimize a little bit. But this comes with some extra cost as you have now to manage possible inte= ractions between two flavors of the same OLR. Regards, Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 4 mars 2014 16:44 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Hello JJ, Interesting analysis. In relation to points 2 and 4, now we have uniqueness of Sequence Number de= fined as: "The sequence number is only required to be unique between two overload control endpoints" If we keep this, it means that for each endpoint (i.e. for each answer to c= lients B, C...) sequence number may be different, and if the answer is mean= t for "all-clients", then reacting node will need to read every new answer = (that corresponds to a request from a different client), even if OLR is not= modified. I presume this is acceptable, since default case is meant to be = "one-client", what fits our endpoint definition. About 1, I think that if we define that both "one-client" and "all-client" = reports can coexist, and if so "one-client" takes precedence over "all-clie= nt" it solves the issue you highlighted. About 3, I agree that taking into account endpoint definition, default valu= e is "per client". I would agree on your proposal. About 5, having new report types or new AVP, I think requires same cases to= be studied. I cannot see a clear advantage of one of them over the other. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: martes, 04 de marzo de 2014 14:35 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi all Hereafter several points about some collateral consequences of the Ticket = #35 proposal 1) Besides the commented point 3, I have a similar comment for point = 1. I have a client A with a per client type (0) active OLR having a high r= eduction % (90%) , then the DA receives an OLR client (1) to update % for = all nodes with a small % (10%). According to rule 1 , client A has now 10= % reduction: this will create a burst of traffic. I assume that very so= on after it will receive a new OLR type (0) with 90% but this rule is som= ething creating transient traffic bursts in an overload situation which i= s not our aim. So, we may modify the rule 1 eg by stating "A fresh OLR of = type (1) makes all old type (1) OLRs invalid and leave unchanged clients w= ith a OLR type(0)". But not sure the story is finished., if later the speci= fic peak vanishes and the server wants to handle client A as other nodes, = what does the server do? Due to my new rule, server sending an OLR type (1= ) does not solve this point, but we would like to avoid a server to continu= e to send OLR type (0),to this client as there is no more specificity - We may use the validity period of 0, but it means no more over= load - the other way is first to use a OLR type(0) with short validity= expiration period (and a value of 10% to align)) and to add a new rule: "= if an OLR(0) expires for a client, , and if an OLR type (1) exist for other= clients, the OLR type(1) applies to this client. 2) A clarification if I have the right understanding When DA receives the first OLR type (1) with a new seq number in an answer = to a client A , this OLR type (1) immediately applies to all nodes (apart t= hose with a OLR type(0) active, cf above), taking into account that DA will= then receives other answers to client B, C... with the same OLR type (1) = and the same seq number should be the same, as long as there is no modif br= ought to OLR type(1). May be also some text to avoid misunderstanding would= be need to avoid a wrong seq numbr handling Do you agree? 3) Another point: when I consider the target network in the future whe= re there are only DOIC clients, why to continue to send a mandatory OLR whi= ch shall always be ignored.... I would prefer to have no such OLR at all,= meaning to introduce a non mandatory OLR AVP with a default value when no = present. As in the target network, the Host OLR is per client, default val= ue would be (0). Views? 4) Regarding DOIC association, here we have an information (OLR with t= ype (1) exchanged inside a DOIC association that applies to many DOIC ass= ociations. It is possible but it should be highlighted . 5) I also saw Mcruz had a preferencee for another OLR type and not a n= ew AVP, have we concluded on this . What are your views? These are not blocking points, there is always some so= lution by adding new rules. Nevertheless I am always cautious when a new AV= P is introduced, as it always creates new combinational cases, that we have= to analyse . So is this optimization actually needed. If yes, we need to a= dd the right rules to avoid unexpected situations and misunderstanding Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : jeudi 27 f=E9vrier 2014 21:11 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion I think if you change number three to the following then it works better. 3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for the c= lient to which the answer message is being routed. The agent shall apply t= he OLR or type (0) for traffic from that client. The old OLR of type (1) co= ntinues to apply for all clients that do not have a "per client" overload r= eport. I think it is important for a reporting node to be able to start with an "a= ll clients" overload report and then transition to "per client" reports for= chatty clients. Steve On 2/27/14 11:47 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Dear MCruz, certainly a valid point. I don't have a strong view but I wanted to avoid t= he mixture to keep things simple. Maybe we should forbid the change from 1 to 0 during an ongoing overload. Anyway, I don't think this is a blocking point for the proposal to add the = new AVP. Best regards Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Thursday, February 27, 2014 5:13 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Dear Ulrich, Being: (0) OLR per client (1) OLR for all clients Some comments on the interactions you mentioned: 1. A fresh OLR of type (1) makes all old OLRs of any type invalid 2. A fresh OLR of type (0) makes an old OLR of type (0) bound to the s= ame client invalid 3. A fresh OLR of type (0) makes an old OLR of type (1) invalid I do not think 3) is right. Why an OLR per one specific client shall invali= date OLRs for rest of clients? This will imply that rest of clients will no= t have any overload mitigation on until they receive a new value of (1), or= (0) for each of them. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: mi=E9rcoles, 26 de febrero de 2014 12:23 To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi JJacques, thank you for the summary. I think it does not matter whether we call A) "OLR per client" the base solution and "OLR for all clients" the opt= imization or B) "OLR for all clients" the base solution and "OLR per client" the (3GP= P) extension as long as we cover both. I don't think there are impacts on sequence number handling, report types o= r DOIC associations. My proposal then is to add a new mandatory AVP of type enumerated to OC-OLR= with values (0) OLR per client (1) OLR for all clients Reporting nodes that better like A) could allways send (0) unless they supp= ort the "optimization" and want to use it; Reporting nodes that better like B) could allways send (1) unless they supp= ort the "(3GPP) extension" and want to use it. Clients can safely ignore the new AVP. Agents taking the role of the reacting node on behalf of a client must do t= he binding when receiving (0). We also need to say something on interactions e.g.: A fresh OLR of type (1) makes all old OLRs of any type invalid A fresh OLR of type (0) makes an old OLR of type (0) bound to the same clie= nt invalid A fresh OLR of type (0) makes an old OLR of type (1) invalid (i.e. change of type is allowed, mixture is not allowed) Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA= CQUES (JEAN-JACQUES) Sent: Wednesday, February 26, 2014 8:07 AM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi Steve, MCruz and all On my side, I agree with Lionel. I have not the same reading of the draft where I have not found the Stev= e's default case. I agree with Lionel that the OLR for a DOIC association relates to this DOI= C association and the OLR can be different for another DOIC association. = The basic (or "default") principle is that each DOIC association has its "o= wn life". Then, a server (local policy) can decide to send the same OLR to all its= clients (so for all its DOIC associations) , or it can define particular = OLR values for certain clients. Another interest is that when the server wants to update the OLR values = towards clients, it is not obliged to send the new values simultaneously= to all the clients : it may (local server policy) progressively change = the value over a certain duration to minimize sharp transitions. So for DOIC supporting clients, the current text allows these possibilities= , and in particular it satisfies the 3GGP client mitigation requirement. A second step is to address DAs supporting non DOIC clients. Over time, we= may expect that clients will be more and more DOIC supporting; so, this is= the main target. DAs with non DOIC client would be more for a transition= (to be considered nevertheless and which may be long). The current text says that DA is acting on behalf of "A" client; so princip= le with host OLR per DOIC association also applies, and there is no differ= ence for the server, as this does not make a difference between a DOIC sup= porting client and a DA supporting non DOIC clients. Nevertheless, and here I come to Steve's point, this has a cost implying = the DA to manage OLRs per client. Steve introduces an optimization where i= n fact a set of clients are considered for me as a pool regarding DOIC whe= re only one OLR applies and where throttling applies to the requests of t= his pool of clients. I am not against to optimization process but this = pool concept is new and needs some further study. First about the concept o= f DOIC association which evolves , as now linked to a pool . There was a MCruz remark about sequence number, a new AVP or a new report = type. I see that we may have to review the processing of the seq number = handling as also dependent of the new AVP or the OLR type; so a "collate= ral " effect of the optimization. I would also think that, instead of intro= ducing a single node indication in the OLR (AVP or report type) , it should= be a global indication as the optimization is to support a global DOIC a= ssociation. To also see if there are not other collateral effects to analy= ze. Ulrich also mentioned that for realm OLRs we may also have a different re= alm OLR sent to different clients, so this is the same principle as Lionel= for a realm OLR per DOIC association, on which I agree. The current text due to the DOIC association principle, allows this realm = OLR per DOIC association for both DOIC supporting clients and DAs acting= on behalf of A client. Then I expect Steve to do the same remark, with th= e same reason to have an optimization where all clients receives the s= ame realm OLR, but to also see the collateral effects. As a conclusion, I think we should remain with the current text as the base= line, following the DOIC association principle that Lionel mentions, and af= ter more investigation to assess the optimization for host and realm OLRs= with DA supporting non DOIC, this optimization being optional. Best regards JJacques De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : mardi 25 f=E9vrier 2014 10:09 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Yes, I agree with Steve. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 24 de febrero de 2014 20:24 To: lionel.morand@orange.com; dime@ietf.or= g Subject: Re: [Dime] Issue#35 conclusion Lionel, The question is whether the reporting node is sending the overload report p= er client or it is sending a global overload report that applies to all cli= ents. I still believe that the default behavior of a reporting node will be to ha= ve a single overload reduction value for the application and that that over= load reduction value will apply to all clients. If this is the case then t= here is little benefit (and significant overhead) to requiring an agent to = maintain state per non-supporting client. I also agree that there is value to the reporting node being able to have a= different reduction value for specific reacting nodes. If this is the cas= e then the reporting node should indicate that it only applies to the origi= n-host in the request and only then should agents be required to maintain s= tate for the non-supporting client. Steve On 2/24/14 12:57 PM, lionel.morand@orange.com wrote: I really don't understand but it is not the first time :) What about the DOIC association? What about my assumption about agent maint= aining overload control state for non-DOIC enabled client? So for me, the proposal from Ulrich is a clarification on the agent behavio= r that was implicit if you consider the comments above. For me, the option for the server is only to send a specific OLR for a spec= ific client. So over two different DOIC association with the same server/re= porting node, you can have two different OLRs. But it does not change the way the OLR is handled by reacting nodes. Lionel De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan Envoy=E9 : lundi 24 f=E9vrier 2014 19:50 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Maria Cruz, To the degree possible we should minimize the per application overload logi= c required. To this end, it would be better to have this as part of the ba= se specification, as it is likely that most/all applications will want the = same behavior. Whether a reporting node uses per Origin-Host reports is an implementation = detail of the reporting node. How reacting nodes respond to per Origin-Hos= t reports should be specified in a common way. Steve On 2/24/14 12:40 PM, Maria Cruz Bartolome wrote: Hello again, I forgot to mention something else in this thread, that I already mentioned= in related thread #56. This is all in order to take into account 3GPP requirement on overload miti= gation differentiation per client. But this is a server option: TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementatio= ns to decide when and whether overload mitigation differentiation per clien= t is used". Therefore, we can even consider this new OLR out of the base draft, and be = considered by 3GPP applications when required. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome Sent: lunes, 24 de febrero de 2014 19:19 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Steve, all, I agree with Steve. However, I would like to share one concern. We need to avoid that existing = (if any) host OLR ("all-client") in the reacting node is replaced by new ho= st OLR (per client). Host OLR (per client) with the new AVP requires that the server uses a new = sequence number, but existing host OLR (all) shall not be replaced, on the = contrary both Host OLR (all) and new Host OLR (per client) should remain. In order to achieve this, it could be more convenient to use a dedicated OL= R type (host per client), instead of a new AVP. Let me know your opinions. Best regards /MCruz From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan Sent: lunes, 24 de febrero de 2014 16:56 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Adding an AVP to indicate that a report applies just to the Origin-Host in = the request is not just an optimization for agents. It had been my assumption all along that the default behavior of a reportin= g node (server) would be to report a single overload value to all reacting = nodes, be they clients or agents. If this is the default behavior then it = would be best to have the default, implicit, meaning of an overload report = to be "applies to all reacting nodes". The real value of this new feature = is to allow a server to further throttle a specific, overly active, reactin= g node when then global reduction percentage doesn't do the job. In addition, if the normal case is that reporting nodes have a single globa= l reduction percentage then requiring agents to bind an overload report to = each non supporting clients pushes a lot of extra work on agents when it ad= ds no value. My proposal is the following: - Add an optional AVP (call it something like Single-Node???) to overload r= eports that indicate when an overload report applies to a specific reacting= node. - Absence of the AVP indicates that the report applies to all reacting node= s (clients and agents acting on behalf of non-DOIC clients). - Reporting nodes should only include the Single-Node AVP if the overload r= eport contents are different from the global overload report. - DOIC-supporting agents receiving an OLR without the Single-Node AVP must = do the following: - For transactions from DOIC-supporting clients the agent must not act on= the OLR. - For transactions from non-DOIC-supporting clients the agent must apply = the OLR to traffic from the set of non supporting clients. This implies t= hat when making throttling decisions, the agent does not differentiate whic= h non supporting client originated the request. - DOIC-supporting agents receiving an OLR with the Single-Node AVP for a tr= ansaction originated by a non supporting client must bind that OLR to that = single client. Note that the agent behavior is currently something that is missing from th= e -01 version of the draft. We will need something like this wording indep= endent of the resolution of this issue. Steve On 2/24/14 8:06 AM, lionel.morand@orange.com wrote: Is it implicit? If the agent detects that a client is not supporting DOIC, this agent will = have to store the corresponding overload control state on behalf of this cl= ient and only this client (saying that other clients may support DOIC). I'm= assuming then that any agent will have to store somewhere the origin-host = of this client. And therefore, I don't see what would be the added-value of= this AVP saying that this OLR is only for this client. Even if this AVP is present, it would not preclude a reporting node to alwa= ys put this AVP in every answer, even if the OLR is the same for all the cl= ients. Regards, Lionel -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoy=E9 : lundi 24 f=E9vrier 2014 14:27 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Hello Ulrich, I haven't proposed to limit this to host type OLR, I just wanted to clarify= if this is what JJ got in mind. I agree it could be done as you explained in the example below, but the ope= n question is whether it is better to add an AVP when OLR is just meant for= one single client, or on the contrary the agent _always_ need to bind OLR = to one specific client, even if the server simply requires same OLR for any= client. I think having a new AVP simplifies agent behavior. Best regards /MCruz -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: lunes, 24 de febrero de 2014 14:19 To: Maria Cruz Bartolome; dime@ietf.org Subject: RE: [Dime] Issue#35 conclusion Hi MCruz, there is no reason to limit this to host type OLRs. If we have an agent A that is configured to take the role of the reporting = node for realm-type reports for realm R, A could receive host type OLRs fro= m servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduc= tion from C2, S2 requesting 30% reduction from C1 and 40% reductin from C2)= ; A then would aggregate these info and return realm type OLRs to C1 reques= ting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduct= ion of traffic from C2 to R. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto= lome Sent: Monday, February 24, 2014 2:02 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hello JJ and all, As per email thread, the latest proposal is: "When an agent takes the role of a reacting node, the agent needs to bind a= received OLR to the origin host of the client that initiated the request w= hich corresponds to the answer containing the OLR." An Ulrich comments on this: "This would cover not only the case where an agent takes the role of the re= acting node on behalf of a (or several) non supporting client, but also the= case where an agent is configured to take the role of a reporting node (fo= r realm-type reports) towards the client and at the same time the role of a= reacting node towards the server." Is your proposal limited to Host-OLR, i.e. Realm OLR is excluded? Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE= S (JEAN-JACQUES) Sent: lunes, 24 de febrero de 2014 13:43 To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Hi Mcruz and all I think that you are mixing the case of the DA that is the "reporting" nod= e which wants to indicate a realm OLR to clients, and for which will use va= rious (non standardized ) ways to determine among which it can reuse the Ho= st-OLR AVPs received from various servers. But in this case, clients receiv= ing realm OLRs are supporting DOIC. Here I understand the on going discussion is about the DA behavior when c= lients is not supporting DOIC and to reuse the Host-OLR received for one cl= ient for other clients . For me I remain on my previous mail, with a baseline solution. We may alwa= ys study new extensions, optimizations, but priority should be on the basel= ine. Best regards Jacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome= Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : dime@ietf.org Objet : Re: [Dime] Issue#35 conclusion Hello all, Not sure we all have the same understanding here. Let me try to explain my concerns. The original 3GPP requirement we want to cover is the need for a server to = reduce traffic for one specific client, i.e. traffic identified by "Origin-= Host" in the request. Then, two options are under analysis about whether or not the OLR in the se= rver answer shall be marked: a) OLR does not need to include anything else Receiver of the answer (and O= LR) is the client that sends the request, identified by "Origin-Host" in th= e request. Then, as long as the reacting node=3D=3D"Origin-Host", the expected reducti= on is performed and requirement fulfilled. But, when an agent is acting on behalf of a client as the reacting node, th= en the "Origin-Host" identifies final client, but not the reacting node. Then, this is why the proposal is to add following clarification about agen= t behavior (possible clause 5.5): "When an agent takes the role of a reacting node, the agent needs to bind a= received OLR to the origin host of the client that initiated the request w= hich corresponds to the answer containing the OLR." But this will imply that _always_ the reacting node applies this OLR to one= specific client, what is not what we need to achieve. How will this impact the case where the agent is providing access to a Real= m? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider foll= owing example: - C1 sends a Realm request via Agent, that finally reaches S1 - S1 answers with OLR (Host:50%). - Agent is acting as reacting node on behalf of C1, if it considers this OL= R only bind to C1... then... should it consider S1-OLR only as relevant for= requests coming from C1? Should agent do not use this S1-OLR to calculate = aggregated Realm overload? In my opinion, in this case it does not make sense to consider OLR was only= meant to C1. And this problem could be solved adding explicit information,= as in b) below. b) OLR needs to be extended (new AVP) that identifies the client ("Origin-H= ost" in the request) from which traffic reduction shall apply. With this new AVP, reacting node will easy be able to identify when OLR sha= ll be applied to any client or just to the Origin-Host identified by new AV= P. Let me know your opinions please Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -= DE/Munich) Sent: lunes, 24 de febrero de 2014 12:28 To: ext Steve Donovan; dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Steve, please see inline. Ulrich From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Friday, February 21, 2014 4:53 PM To: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion Ulrich, I have a couple of concerns with this approach, as currently outlined. First, how do we handle the case where there are multiple DOIC supporting a= gents between the non supporting client and the reporting node. This, I gu= ess, is a general question, not just applying to this proposal. I suggest = we capture in the agent behavior section that is currently missing wording = indicating that the first supporting agent that receives the request must b= e the reacting node for that non-supporting client. Subsequent DOIC suppor= ting agents must not be the reacting node for the non-supporting client. I fully agree We need to think through the ramifications of having multiple agents being = the reacting node for the same non supporting clients, as this could easily= happen in networks where multiple agents are involved in a single transact= ion. On the surface it doesn't seem to be an issue for the loss algorithm,= but this might not be the case with other algorithms. I agree that this is not an issue for loss; it is an issue e.g. for= rate (i.e. for draft-donovan-dime-doc-rate-control) My other concern is that this puts a lot of extra onus on the agent even fo= r the case where the reporting node does not want to differentiate overload= reports. I agree To this end I suggest we add an indication in the OLR marking the reports t= hat are specific to just the Origin-Host in the request. Absence of the "s= ingle-client-only" AVP would mean that the report applies to all clients. = Presence of the AVP would indicate that the OLR applies to the Origin-Host. I understand that the proposal is an optimization for agents. There= fore the semantics of the marking should be reverse: unmarked OLRs are clie= nt specific, marked OLRs indicate that the reporting node does not want to = differentiate, and therefore allow agents not to do the binding to the clie= nt. Steve On 2/21/14 4:48 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: Ben, the proposed conclusion was based on comments received so far (from Lionel,= Nirav, Steve, MCruz, JJ). Now you seem to address two points: a) There is no dependency to DOIC support of the client. To address this I would like to propose rewording of the clarifying text fo= r 5.5. as follows: When an agent takes the role of a reacting node, the agent needs to bind a = received OLR to the origin host of the client that initiated the request wh= ich corresponds to the answer containing the OLR. This would cover not only the case where an agent takes the role of the rea= cting node on behalf of a (or several) non supporting client, but also the = case where an agent is configured to take the role of a reporting node (for= realm-type reports) towards the client and at the same time the role of a = reacting node towards the server. b) There is no binding of the OLR to the orig-host of the client Here I dis= agree. We have the 3GPP requirement to allow requesting different amount of= reduction from different clients, and I think we have 3 options: 1. ignore the 3GPP requirement 2. introduce new report types as originally proposed in #35 3. introduce th= e binding between OLR and orig-host of the client. So far I understood that people favoured option 3. See also inline. Ulrich -----Original Message----- From: ext Ben Campbell [mailto:ben@nostrum.com] Sent: Thursday, February 20, 2014 11:55 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] Issue#35 conclusion On Feb 20, 2014, at 6:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: #35: additional report types are proposed Dear all, I believe we can conclude, not to add additional report types. However, we = agreed to add clarifying text to clause 5.5 as follows: When an agent received an OLR in response to a request initiated by a clien= t not supporting DOIC, this agent needs to bind the received OLR to the ori= gin-host of the client. I do not agree. You proposal implies that the server's OLR only applies to that client. exactly, that was the intention If there's an intervening= DOIC agent, then the agent, not the client, is the reacting node from the = server's perspective. the server's perspective is agnostic. The server does not know whe= ther it's the client or an agent on the path that takes the role of the rea= cting node But, short of adding an origin-host type, nothing bind= s the OLR to a particular client, regardless of DOIC support at the clients. the binding is always there, regardless of DOIC support at the cli= ent Whether or not the client also supports DOIC doesn't change that. For DOIC= -supporting clients, the agent has the additional option of reducing traffi= c by asking the clients to reduce traffic (making them reacting nodes from = the perspective of the _agent_, but not the server.) It doesn't have that = option for non-DOIC clients. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ 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, Orange decline toute responsabilite si ce message a ete altere, 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, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E4DF9F3PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Can someon= e explain to me what would be the added-value to create two types of OLR if= any reporting node can freely use one or the other?

The agent = in the middle will have to expect to store OLR for specific non-supporting = DOIC nodes anyway. So OK, with the new type, time to time, you will be able to optimize a little bit.

But this c= omes with some extra cost as you have now to manage possible interactions b= etween two flavors of the same OLR.

 = ;

Regards,

 = ;

Lionel

 = ;

De := DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 4 mars 2014 16:44
=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

 

Hello JJ,<= o:p>

 = ;

Interestin= g analysis.

 = ;

In relatio= n to points 2 and 4, now we have uniqueness of Sequence Number defined as:<= o:p>

The sequence number is only

   required to be unique between two overload control e= ndpoints”=

 = ;

If we keep= this, it means that for each endpoint (i.e. for each answer to clients B, = C…) sequence number may be different, and if the answer is meant for “all-clients”, then reacting node will need to read = every new answer (that corresponds to a request from a different client), e= ven if OLR is not modified. I presume this is acceptable, since default cas= e is meant to be “one-client”, what fits our endpoint definition.

 = ;

About 1, I= think that if we define that both “one-client” and “all-= client” reports can coexist, and if so “one-client” takes= precedence over “all-client” it solves the issue you highlighted.

 = ;

About 3, I= agree that taking into account endpoint definition, default value is ̶= 0;per client”. I would agree on your proposal.

 = ;

About 5, h= aving new report types or new AVP, I think requires same cases to be studie= d. I cannot see a clear advantage of one of them over the other.

 = ;

Best regar= ds

/MCruz

 = ;

From:= DiME [mailto:dime-b= ounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: martes, 04 de marzo de 2014 14:35
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

 

Hi all

 = ;

Hereafter = several points  about some collateral consequences of the Ticket #35 p= roposal

 = ;

1)      Besides the commented  point 3, I have a simila= r comment for point 1. I have a client A with a per client type  (0) active OLR having a high reduction % (90%) , then the  DA receive= s an OLR client (1) to update % for all nodes with a small % (10%). Accordi= ng to  rule 1 , client A has now  10% reduction:  this will = create  a burst of traffic.   I assume that very soon after  it will receive  a new OLR type (0) with 90% but this rul= e is something creating transient  traffic  bursts in an overload= situation which is not our aim. So, we may modify the rule 1 eg by stating=   “A fresh OLR of type (1) makes all old type (1) OLRs  invalid and leave unchanged clients with a OLR type(0)”. But not sur= e the story is finished., if later the specific peak vanishes and the serve= r wants to handle client A as other nodes,  what does the server do? D= ue to my new rule, server  sending an OLR type (1) does not solve this point, but we would like to avoid a server to cont= inue to send OLR type (0),to this client as there is no more specificity

-<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;      We may use  the validity period of 0, but = it means no more overload

-<= span style=3D"font:7.0pt "Times New Roman"">   &nb= sp;      the other way is first  to use a OLR type(0) wi= th short validity expiration period (and a value of 10% to align)) and to add a new  rule: “if an OLR(0) expires for a client, , a= nd if an OLR type (1) exist for other clients, the OLR type(1) applies to t= his client.   

 = ;

 

2)      A clarification if I have the right understanding

When DA re= ceives the first OLR type (1) with a new seq number in an answer to a clien= t A , this OLR type (1) immediately applies to all nodes (apart those with a OLR type(0) active, cf above), taking into account that DA wi= ll then receives  other answers to client B, C… with the same OL= R type (1) and the same seq number should be the same, as long as there is = no modif brought to OLR type(1). May be also some text to avoid misunderstanding would be need to avoid a wrong seq num= br handling  Do you agree?

 = ;

3)      Another point: when I consider the target network in= the future where there are only DOIC clients, why to continue to send a mandatory OLR which  shall always be ignored…. I woul= d prefer to have  no such OLR at all, meaning to introduce a non manda= tory OLR AVP with a default value when no present. As in the target network= , the Host OLR is  per client, default value would be (0). Views?

 = ;

4)      Regarding DOIC association, here we have an informat= ion (OLR with type (1)  exchanged inside  a DOIC association that applies to many DOIC associations.  It is possible but it should= be highlighted .

 = ;

5)      I also saw Mcruz had a preferencee for another OLR t= ype and not a new AVP, have  we concluded on this .

 = ;

What are y= our views? These are not blocking points, there is always some solution by = adding new rules. Nevertheless I am always cautious when a new AVP is introduced, as it always creates new combinational cases, that = we have to analyse . So is this optimization actually needed. If yes, we ne= ed to add the right rules to avoid unexpected  situations and  mi= sunderstanding

 = ;

Best regards

 <= /p>

JJacques

 <= /p>

 <= /p>

De := DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : jeudi 27 f=E9vrier 2014 21:11
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

 

= I think if you change number three to the following then it works better.
  3. A fresh OLR of type (0) makes an old OLR of type (1) invalid for = the client to which the answer message is being routed.  The agent sha= ll apply the OLR or type (0) for traffic from that client. The old OLR of t= ype (1) continues to apply for all clients that do not have a "per client" overload report.

I think it is important for a reporting node to be able to start with an &q= uot;all clients" overload report and then transition to "per clie= nt" reports for chatty clients.

Steve

On 2/27/14 11:47 AM, Wiehe, Ulr= ich (NSN - DE/Munich) wrote:

Dear MCruz= ,

 

certainly = a valid point. I don’t have a strong view but I wanted to avoid the m= ixture to keep things simple.

Maybe we s= hould forbid the change from 1 to 0 during an ongoing overload.

 

Anyway, I = don’t think this is a blocking point for the proposal to add the new = AVP.

 

Best regar= ds

Ulrich

 

From:= DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Thursday, February 27, 2014 5:13 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion
<= o:p>

 

Dear Ulric= h,

 

Being:

(0) &nb= sp; OLR per client

(1) &nb= sp; OLR for all clients=

 

Some comme= nts on the interactions you mentioned:

1. &nbs= p;    A fresh OLR of type (1) makes all old OLRs of any ty= pe invalid

2. &nbs= p;    A fresh OLR of type (0) makes an old OLR of type (0)= bound to the same client invalid

3. &nbs= p;    A fresh OLR of type (0) makes an old OLR of type (1)= invalid

 

I do not t= hink 3) is right. Why an OLR per one specific client shall invalidate OLRs = for rest of clients? This will imply that rest of clients will not have any overload mitigation on until they receive a new value of= (1), or (0) for each of them.

 

Best regar= ds

/MCruz

 

 

From:= DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: mi=E9rcoles, 26 de febrero de 2014 12:23
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion
<= o:p>

 

Hi JJacque= s,

 

thank you = for the summary.

 

I think it= does not matter whether we call

A= )     “OLR per client” the base solution= and “OLR for all clients” the optimization or

B= )    “OLR for all clients” the base solution = and “OLR per client” the (3GPP) extension

as long as= we cover both.

 

I don̵= 7;t think there are impacts on sequence number handling, report types or DO= IC associations.

 

My proposa= l then is to add a new mandatory AVP of type enumerated to OC-OLR with valu= es

(= 0)   OLR per client

(= 1)   OLR for all clients=

 

Reporting = nodes that better like A) could allways send (0) unless they support the &#= 8220;optimization” and want to use it;

Reporting = nodes that better like B) could allways send (1) unless they support the &#= 8220;(3GPP) extension” and want to use it.

Clients ca= n safely ignore the new AVP.<= /p>

Agents tak= ing the role of the reacting node on behalf of a client must do the binding= when receiving (0).

 

We also ne= ed to say something on interactions e.g.:<= /o:p>

A fresh OL= R of type (1) makes all old OLRs of any type invalid

A fresh OL= R of type (0) makes an old OLR of type (0) bound to the same client invalid=

A fresh OL= R of type (0) makes an old OLR of type (1) invalid

 

(i.e. chan= ge of type is allowed, mixture is not allowed)<= o:p>

 

Ulrich

 

 

From:= DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, February 26, 2014 8:07 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion
<= o:p>

 

Hi Steve, = MCruz and all

 

On my side= ,  I agree with Lionel.<= /p>

 

I  ha= ve not the  same reading of the draft where I have  not found the= Steve’s default case.

I agree wi= th Lionel that the OLR for a DOIC association relates to this DOIC associat= ion  and the OLR can be different  for another DOIC association. The basic (or “default”) principle is that each DOIC associati= on has its “own life”.

 

Then, &nbs= p;a server (local policy) can decide  to send  the same OLR to al= l its clients (so for all its DOIC associations) , or it can define  p= articular OLR values for   certain clients.

Another &n= bsp;interest  is that  when the server wants to update the OLR va= lues towards  clients, it is  not obliged to send the new values =  simultaneously  to all the clients : it may  (local server policy) progressivel= y  change  the  value  over a certain duration  to= minimize  sharp transitions.

 

So for DOI= C supporting clients, the current text allows these possibilities, and in p= articular it satisfies the 3GGP client mitigation requirement.

 

A second s= tep is to address DAs supporting non DOIC clients. Over time,  we may = expect that clients will be more and more DOIC supporting; so, this is the main target. DAs with non DOIC client would be more for  =  a transition (to be considered  nevertheless and which may be lo= ng).

 

The curren= t text says that DA is acting on behalf of “A” client; so princ= iple  with host OLR per DOIC association also applies, and there is no difference for the server, as this does not make a difference  betwee= n a DOIC supporting client and a DA supporting non DOIC clients.

Neverthele= ss, and here I come to Steve’s point,   this has a cost imp= lying the DA to manage OLRs per client. Steve  introduces an optimizat= ion where in fact a set of clients are considered for me as a pool regarding &= nbsp;DOIC where only one OLR applies and where throttling  applies &nb= sp;to the requests of this  pool of clients.  I am not against to= optimization process   but this pool concept is new and needs some further study. First about the concept of DOIC association whic= h evolves , as now linked to a pool .

 

There was = a MCruz remark about sequence number, a new AVP or a  new report type.=  I see that  we may have to review  the processing of the s= eq number  handling as also dependent of the new AVP or the OLR type; so=   a “collateral “ effect of the optimization. I woul= d also think that, instead of introducing a single node indication in the O= LR (AVP or report type) , it should be a global indication as the optimization   is to support a global DOIC association. &= nbsp;To also see if there are not other collateral effects to analyze.

 

Ulrich &nb= sp;also mentioned that for realm OLRs we may also have  a different re= alm  OLR sent to different clients, so this is the same principle as Lionel  for  a realm OLR per DOIC association, on which I agree.=

 

The curren= t text due to the DOIC association principle,  allows this realm OLR p= er DOIC association for both  DOIC  supporting clients and  = DAs acting on behalf of A client. Then I expect Steve  to do the same rem= ark, with the same reason  to have  an optimization  where a= ll clients receives  the  same realm OLR, but to also see the col= lateral effects.

 

As a concl= usion, I think we should remain with the current text as the baseline, foll= owing the DOIC association principle that Lionel mentions, and after more investigation to assess the  optimization  for ho= st and realm OLRs with DA supporting non DOIC,  this optimization bein= g optional.

 

Best regards<= /o:p>

 <= /p>

JJacques

 <= /p>

De := DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 f=E9vrier 2014 10:09
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

 

Yes, I agr= ee with Steve.

 

Best regar= ds

/MCruz

 

From:= DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: lunes, 24 de febrero de 2014 20:24
To: lionel.morand@orange= .com; dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion
<= o:p>

 

= Lionel,

The question is whether the reporting node is sending the overload report p= er client or it is sending a global overload report that applies to all cli= ents. 

I still believe that the default behavior of a reporting node will be to ha= ve a single overload reduction value for the application and that that over= load reduction value will apply to all clients.  If this is the case t= hen there is little benefit (and significant overhead) to requiring an agent to maintain state per non-supporting clien= t.

I also agree that there is value to the reporting node being able to have a= different reduction value for specific reacting nodes.  If this is th= e case then the reporting node should indicate that it only applies to the = origin-host in the request and only then should agents be required to maintain state for the non-supporting client.=

Steve

On 2/24/14 12:57 PM, lionel.morand@orange.com wrote:

I really d= on't understand but it is not the first time J

 

What about= the DOIC association? What about my assumption about agent maintaining ove= rload control state for non-DOIC enabled client?

So for me,= the proposal from Ulrich is a clarification on the agent behavior that was=