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=
 implicit if you consider the comments above.


 


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


But it doe=
s not change the way the OLR is handled by reacting nodes.


 


Lionel<=
/p>

 <=
/p>





De :=
 DiME [mail=
to: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 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 ove=
rload mitigation 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 whe=
n and whether overload mitigation differentiation per client is
 used".


 


Therefore, we can eve=
n consider this new OLR out of the base draft, and be considered by 3GPP ap=
plications 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<=
o:p>






 


Steve, all=
,




I agree with Steve.


 


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

Host OLR (=
per client) with the new AVP requires that the server uses a new sequence n=
umber, but existing host OLR (all) shall not be replaced,
 on the contrary both Host OLR (all) and new Host OLR (per client) should r=
emain.


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


 


Let me kno=
w your opinions.


Best regar=
ds


/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<=
o:p>






 


=
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 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:






Is it implicit? 


 


If the agent detects that a client is not supporting DOIC, th=
is agent will have to store the corresponding overload control state on beh=
alf of this client and only this client (saying that other clients may supp=
ort DOIC). I'm assuming then that any agent will have to store somewhere th=
e 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 reportin=
g node to always put this AVP in every answer, even if the OLR is the same =
for all the clients.


 


R=
egards,


&=
nbsp;


L=
ionel


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces@ietf.org] De la part de Mari=
a Cruz Bartolome


E=
nvoy=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 wan=
ted to clarify if this is what JJ got in mind.<=
o:p>


 


I agree it could be done as you explained in the example belo=
w, 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_ nee=
d to bind OLR to one specific client, even if the server simply requires sa=
me 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] 


S=
ent: lunes, 24 de febrero de 2014 14:19


To: Maria Cruz Bartolome; di=
me@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 from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1=
 and 20% reduction from C2, S2 requesting 30% reduction from C1 and 40% red=
uctin from C2); A then would aggregate these info and return realm type OLR=
s to C1 requesting 20% reduction of traffic from C1 to R, and to C2 request=
ing 30% reduction of traffic from C2 to R.=



 


Best regards

Ulrich


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome


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 ag=
ent needs to bind a received OLR to the origin host of the client that init=
iated the request which corresponds to the answer containing the OLR."=
 


 


An Ulrich comments on this:<=
/o:p>


"This would cover not only the case where an agent takes=
 the role of the reacting node on behalf of a (or several) non supporting c=
lient, 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."


 


Is your proposal limited to Host-OLR, i.e. Realm OLR is exclu=
ded? 


Best regards

/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



S=
ent: 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" node which wants to indicate a realm OLR to clien=
ts, and for which will use various (non standardized ) ways to determine am=
ong which it can reuse the Host-OLR AVPs received from various servers. But=
 in this case, clients receiving realm OLRs are supporting DOIC. 


Here I understand the on going  discussion is about the =
DA behavior when  clients is not supporting DOIC and to reuse the Host=
-OLR received for one client for other clients  .


 


For me I remain on  my previous mail, with a baseline so=
lution. We may always study new extensions, optimizations, but priority sho=
uld be on the baseline.


 


B=
est regards


&=
nbsp;


J=
acques 


&=
nbsp;


&=
nbsp;  


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces@ietf.org] De la part de Mari=
a Cruz Bartolome Envoy=E9 : lundi 24 f=E9vrier 2014 13:21 =C0 : <=
/span>dime@ietf=
.org Objet : Re: [Dime] Issue#35 conclusion


&=
nbsp;


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 fo=
r a server to reduce traffic for one specific client, i.e. traffic identifi=
ed by "Origin-Host" in the request.


Then, two options are under analysis about whether or not the=
 OLR in the server answer shall be marked:=



 


a) OLR does not need to include anything else Receiver of the=
 answer (and OLR) is the client that sends the request, identified by "=
;Origin-Host" in the request.


Then, as long as the reacting node=3D=3D"Origin-Host&quo=
t;, the expected reduction is performed and requirement fulfilled.


But, when an agent is acting on behalf of a client as the rea=
cting node, then the "Origin-Host" identifies final client, but n=
ot the reacting node.


Then, this is why the proposal is to add following clarificat=
ion about agent behavior (possible clause 5.5):=



"When an agent takes the role of a reacting node, the ag=
ent needs to bind a received OLR to the origin host of the client that init=
iated the request which corresponds to the answer containing the OLR."=



But this will imply that _always_ the reacting node applies t=
his OLR to one specific client, what is not what we need to achieve.=



How will this impact the case where the agent is providing ac=
cess to a Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. L=
et's consider following 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 con=
siders this OLR only bind to C1... then... should it consider S1-OLR only a=
s 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 conside=
r OLR was only meant to C1. And this problem could be solved adding explici=
t information, as in b) below.


 


b) OLR needs to be extended (new AVP) that identifies the cli=
ent ("Origin-Host" in the request) from which traffic reduction s=
hall apply.


With this new AVP, reacting node will easy be able to identif=
y when OLR shall be applied to any client or just to the Origin-Host identi=
fied by new AVP.


 


Let me know your opinions please<=
o:p>


Best regards

/MCruz


 


 


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)


S=
ent: 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:d=
ime-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 DOI=
C supporting agents between the non supporting client and the reporting nod=
e.  This, I guess, is a general question, not just applying to this pr=
oposal.  I suggest we capture in the agent behavior section that is cu=
rrently missing wording indicating that the first supporting agent that rec=
eives the request must be the reacting node for that non-supporting client.=
  Subsequent DOIC supporting agents must not be the reacting node for =
the non-supporting client.

<Ulrich>I fully agree</Ulrich>


 


 


We need to think through the ramifications of having multiple=
 agents being the reacting node for the same non supporting clients, as thi=
s could easily happen in networks where multiple agents are involved in a s=
ingle transaction.  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.


<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>


 


My 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 differen=
tiate overload reports.


<Ulrich> I agree </Ulrich>


To this end I suggest we add an indication in the OLR marking=
 the reports that are specific to just the Origin-Host in the request. =
; Absence of the "single-client-only" AVP would mean that the rep=
ort applies to all clients.  Presence of the AVP would indicate that t=
he OLR applies to the Origin-Host.


<Ulrich>I understand that the proposal is an optimizati=
on for agents. Therefore the semantics of the marking should be reverse: un=
marked OLRs are client specific, marked OLRs indicate that the reporting no=
de does not want to differentiate, and therefore allow agents not to do the=
 binding to the client.</Ulrich>     


 


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). <=
/o:p>


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 clar=
ifying text for 5.5. as follows:


 


When an agent takes the role of a reacting node, the agent ne=
eds to bind a received OLR to the origin host of the client that initiated =
the request which corresponds to the answer containing the OLR. 


 


This would cover not only the case where an agent takes the r=
ole of the 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 repor=
ting 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 cli=
ent Here I disagree. We have the 3GPP requirement to allow requesting diffe=
rent amount of reduction from different clients, and I think we have 3 opti=
ons:


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.


 


So far I understood that people favoured option 3.


 


See also inline.


 


Ulrich


 


 


 


-----Original Message-----


From: ext Ben Campbell [ma=
ilto: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) =
<ulrich.wiehe@nsn.com> wr=
ote:


 


#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 initia=
ted by a client not supporting DOIC, this agent needs to bind the received =
OLR to the origin-host of the client.


 


I do not agree.=



 


You proposal implies that the server's OLR only applies to th=
at client.


<Ulrich>exactly, that was the intention</Ulrich>&=
nbsp; If there's an intervening DOIC agent, then the agent, not the client,=
 is the reacting node from the server's perspective.


<Ulrich> the server's perspective is agnostic. The serv=
er does not know whether it's the client or an agent on the path that takes=
 the role of the reacting node</Ulrich>  But, short of adding an=
 origin-host type, nothing binds the OLR to a particular client, regardless=
 of DOIC support at the clients.


<Ulrich> the binding is always there, regardless of DOI=
C support at the client</Ulrich>


 


 Whether or not the client also supports DOIC doesn't change =
that. For DOIC-supporting clients, the agent has the additional option of r=
educing traffic by asking the clients to reduce traffic (making them reacti=
ng 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


 


_=
______________________________________________


D=
iME mailing list


DiME@ietf.=
org


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


&=
nbsp;


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 




 


=
 


_=
______________________________________________


D=
iME mailing list


DiME@ietf.=
org


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




 


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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_--


From nobody Tue Mar  4 09:45: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 2F9351A023E; Tue,  4 Mar 2014 09:45:24 -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 0-6JVxx8phkc; Tue,  4 Mar 2014 09:45:17 -0800 (PST)
Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by ietfa.amsl.com (Postfix) with ESMTP id 649591A0232; Tue,  4 Mar 2014 09:45:17 -0800 (PST)
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-3.tower-170.messagelabs.com!1393955111!24253705!1
X-Originating-IP: [20.137.2.88]
X-StarScan-Received: 
X-StarScan-Version: 6.9.16; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 11421 invoked from network); 4 Mar 2014 17:45:12 -0000
Received: from amer-mta102.csc.com (HELO amer-mta112.csc.com) (20.137.2.88) by server-3.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  4 Mar 2014 17:45:12 -0000
Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta112.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s24HjA2a025888; Tue, 4 Mar 2014 12:45:10 -0500
In-Reply-To: <087A34937E64E74E848732CFF8354B920978871D@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <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>  <087A34937E64E74E848732CFF8354B920978871D@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
MIME-Version: 1.0
X-KeepSent: FDBDB374:1EB9ADC5-85257C91:005F7DDD; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012
From: Janet P Gunn 
Message-ID: 
Date: Tue, 4 Mar 2014 12:45:08 -0500
X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 03/04/2014 12:45:10 PM, Serialize complete at 03/04/2014 12:45:10 PM
Content-Type: multipart/alternative; boundary="=_alternative 006185D785257C91_="
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yZ5mNyygZOeAXkddqsEg7RgqS7M
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: Tue, 04 Mar 2014 17:45:24 -0000

This is a multipart message in MIME format.
--=_alternative 006185D785257C91_=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64

SSB0aGluayB0aGUgaW50ZW50LCBpbiBjaGFuZ2luZyBmcm9tICJoYXMgYmVlbiBzZW5kaW5nICAx
MDAgcmVxdWVzdHMgcGVyIA0Kc2Vjb25kIiB0byAid291bGQgbm9ybWFsbHkgc2VuZCAxMDAgcmVx
dWVzdHMiIHdhcyB0byBnZXQgcmlkIG9mIHRoZSANCnJlZmVyZW5jZSB0byBhICAiaGlzdG9yaWNh
bCAgdHJhbnNtaXNzaW9uIHJhdGUiLg0KDQpUaGUgcGhyYXNlLCAid291bGQgbm9ybWFsbHkgc2Vu
ZCIgc3RpbGwgaGFzIHRoZSBjb25ub3RhdGlvbiAoZm9yIG1lIA0KYW55d2F5KSBvZiBhICJoaXN0
b3JpY2FsICB0cmFuc21pc3Npb24gcmF0ZSIuDQoNClBvc3NpYmxlIHN1Z2dlc3Rpb25zIGFyZSAN
CiJ3b3VsZCwgd2l0aG91dCBvdmVybG9hZCBjb250cm9sLCBzZW5kIDEwMCByZXF1ZXN0cyINCm9y
IA0KIndvdWxkIG90aGVyd2lzZSBzZW5kIDEwMCByZXF1ZXN0cyIgKHdoaWNoIGlzIGNvbnNpc3Rl
bnQgd2l0aCB0aGUgd29yZGluZyANCmluIDQuNykuDQoNCkp1c3QgdHJ5aW5nIHRvIG1ha2UgaXQg
Y2xlYXJlciB0byBmdXR1cmUgcmVhZGVycy4NCg0KVGhhbmtzDQoNCkphbmV0DQoNClRoaXMgaXMg
YSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQs
IHBsZWFzZSANCmRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkg
ZS1tYWlsIG9mIHRoZSBtaXN0YWtlIGluIA0KZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2Yg
Y29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gDQpiaW5kIENTQyB0byBh
bnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IA0K
d3JpdHRlbiBhZ3JlZW1lbnQgb3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJt
aXR0aW5nIHRoZSB1c2Ugb2YgDQplLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4NCg0KDQoNCkZyb206
ICAgTWFyaWEgQ3J1eiBCYXJ0b2xvbWUgPG1hcmlhLmNydXouYmFydG9sb21lQGVyaWNzc29uLmNv
bT4NClRvOiAgICAgSmFuZXQgUCBHdW5uL1VTQS9DU0NAQ1NDLCBTdGV2ZSBEb25vdmFuIDxzcmRv
bm92YW5AdXNkb25vdmFucy5jb20+DQpDYzogICAgIERpTUUgPGRpbWUtYm91bmNlc0BpZXRmLm9y
Zz4sICJkaW1lQGlldGYub3JnIiA8ZGltZUBpZXRmLm9yZz4NCkRhdGU6ICAgMDMvMDMvMjAxNCAw
NjowMyBQTQ0KU3ViamVjdDogICAgICAgIFJFOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBu
ZWVkZWQgdG8gYmUgYmFzZWQgb24gDQpwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbg0KDQoN
Cg0KSGVsbG8gSmFuZXQsIGFsbCwNCiANClRoZSBwcmUtYWdyZWVkIHByb3Bvc2FsIGlzIHRoZSBm
b2xsb3dpbmc6DQogDQpOb3cgKGNoYXB0ZXIgNC43KTogDQogICBUaGUgT0MtUmVkdWN0aW9uLVBl
cmNlbnRhZ2UgQVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzIgDQogICBh
bmQgZGVzY3JpYmVzIHRoZSBwZXJjZW50YWdlIG9mIHRoZSB0cmFmZmljIHRoYXQgdGhlIHNlbmRl
ciBpcyANCiAgIHJlcXVlc3RlZCB0byByZWR1Y2UsIGNvbXBhcmVkIHRvIHdoYXQgaXQgb3RoZXJ3
aXNlIHdvdWxkIGhhdmUgc2VudC4gDQogDQpQcm9wb3NhbDogDQogIFRoZSBPQy1SZWR1Y3Rpb24t
UGVyY2VudGFnZSBBVlAgKEFWUCBjb2RlIFRCRDgpIGlzIHR5cGUgb2YgVW5zaWduZWQzMiANCiAg
YW5kIGRlc2NyaWJlcyB0aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5k
ZXIgaXMgDQogIHJlcXVlc3RlZCB0byByZWR1Y2UsIGNvbXBhcmVkIHRvIHdoYXQgaXQgb3RoZXJ3
aXNlIHdvdWxkIHNlbmQuICANCg0KIA0KTm93IChjaGFwdGVyIDUuNS4yKToNCiAgICBJbmRpY2F0
ZXMgdGhhdCB0aGUgcmVwb3J0aW5nIG5vZGUgdXJnZXMgdGhlIHJlYWN0aW5nIG5vZGUgdG8NCiAg
ICByZWR1Y2UgaXRzIHRyYWZmaWMgYnkgYSBnaXZlbiBwZXJjZW50YWdlLiAgRm9yIGV4YW1wbGUg
aWYgdGhlDQogICAgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBzZW5kaW5nIDEwMCBwYWNrZXRzIHBl
ciBzZWNvbmQgdG8gdGhlDQogICAgcmVwb3J0aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRpb24gb2Yg
T0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUNCiAgICBvZiAxMCB3b3VsZCBtZWFuIHRoYXQg
ZnJvbSBub3cgb24gdGhlIHJlYWN0aW5nIG5vZGUgTVVTVCBvbmx5IHNlbmQNCiAgICA5MCBwYWNr
ZXRzIHBlciBzZWNvbmQuICBIb3cgdGhlIHJlYWN0aW5nIG5vZGUgYWNoaWV2ZXMgdGhlICJ0cnVl
DQogICAgcmVkdWN0aW9uIiB0cmFuc2FjdGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0
IG1lc3NhZ2VzIGlzIHVwDQogICAgdG8gdGhlIGltcGxlbWVudGF0aW9uLiAgVGhlIHJlYWN0aW5n
IG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5DQogICAgMTB0aCBwYWNrZXQgZnJvbSBpdHMgb3V0
cHV0IHF1ZXVlIGFuZCBsZXQgdGhlIGdlbmVyaWMgYXBwbGljYXRpb24NCiAgICBsb2dpYyB0cnkg
dG8gcmVjb3ZlciBmcm9tIGl0Lg0KIA0KUHJvcG9zYWw6DQogICAgSW5kaWNhdGVzIHRoYXQgdGhl
IHJlcG9ydGluZyBub2RlIHVyZ2VzIHRoZSByZWFjdGluZyBub2RlIHRvDQogICAgcmVkdWNlIGl0
cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2VudGFnZS4gRm9yIGV4YW1wbGUgaWYgYW4gDQogICAg
T0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgIDEwIGhhcyBiZWVuIHJlY2VpdmVkLCAN
CiAgICB0aGUgcmVhY3Rpbmcgbm9kZSB3aGljaCAgd291bGQgbm9ybWFsbHkgc2VuZCAxMDAgcmVx
dWVzdHMgDQogICAgTVVTVCBvbmx5IHNlbmQgOTAgcmVxdWVzdHMgdG8gdGhlIHJlcG9ydGluZyBu
b2RlLg0KICAgIEhvdyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hpZXZlcyB0aGUgInRydWUgDQogICAg
cmVkdWN0aW9uIiB0cmFuc2FjdGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0IG1lc3Nh
Z2VzIGlzIHVwIA0KICAgIHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4gVGhlIHJlYWN0aW5nIG5vZGUg
TUFZIHNpbXBseSBkcm9wIGV2ZXJ5IDEwdGggDQogICByZXF1ZXN0IGZyb20gaXRzIG91dHB1dCBx
dWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9uIGxvZ2ljIA0KICAgdHJ5IHRvIHJl
Y292ZXIgZnJvbSBpdC4NCiANCiANCkxldCBtZSBrbm93IGlmIHRoaXMgdGV4dCBjb3ZlcnMgeW91
ciBjb25jZXJucy4NCkkgdG9vayBwcm9maXQgdG8gcmVwbGFjZSBwYWNrZXQgYnkgcmVxdWVzdC4N
CiANCkJlc3QgcmVnYXJkcw0KL01DcnV6DQogDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3Vu
Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFuZXQgUCBHdW5uDQpTZW50OiBsdW5lcywgMDMg
ZGUgbWFyem8gZGUgMjAxNCAyMTowOA0KVG86IFN0ZXZlIERvbm92YW4NCkNjOiBEaU1FOyBkaW1l
QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVk
IHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIA0KaGlzdG9yeSAtIGNvbmNsdXNpb24NCiANCk9LLCBJ
IGFkbWl0IHRvIGJlaW5nIGNvbmZ1c2VkLiANCg0KSW5kZXBlbmRlbnQgb2YgdGhlIHBhY2tldHMg
dnMgcmVxdWVzdHMgZGlzdGluY3Rpb24tIA0KDQpBc3N1bWluZyBhIG5vZGUgcmVjZWl2ZXMgYSBt
ZXNzYWdlIHJlcXVpcmluZyAxMCUgcmVkdWN0aW9uLCBkb2VzIHRoaXMgbWVhbiANCg0KDQpBIC0g
VGhlIG5vZGUgd2lsbCBkcm9wIG9uZSBvdXQgb2YgZXZlcnkgMTAgcmVxdWVzdHMgaXQgIndhbnRz
IiB0byBzZW5kICwgDQp3aGV0aGVyIGl0ICJ3YW50cyIgdG8gc2VuZCAxMCByZXF1ZXN0cyBvciAx
MDAwIHJlcXVlc3RzIHBlciB1bml0IHRpbWUuIA0KDQpvciANCg0KQi0gSWYgaXQgIm5vcm1hbGx5
IiBzZW5kcyAxMDAgbWVzc2FnZXMgcGVyIHVuaXQgdGltZSwgaXQgd2lsbCByZXN0cmljdCANCml0
c2VsZiB0byA5MCBtZXNzYWdlcyBwZXIgdW5pdCB0aW1lLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg
aXQgIndhbnRzIiB0byANCnNlbmQgMTAgb3IgMTAwMCANCj8gDQoNCiJBIiBtYWtlcyBtb3JlIHNl
bnNlIHRvIG1lLCBidXQgdGhlIHByb3Bvc2VkIHRleHQgKHJlcGVhdGVkIGJlbG93KSBzZWVtcyAN
CnRvIGltcGx5ICJCIiAoOTAgcGFja2V0cyBwZXIgc2Vjb25kIGJhc2VkIG9uIHdoYXQgaXQgImhh
cyBiZWVuIHNlbmRpbmciIG9yIA0KIndvdWxkIG5vcm1hbGx5IHNlbmQiIGluZGVwZW5kZW50IG9m
IHRoZSBudW1iZXIgdGhlIG5vZGUgIndhbnRzIiB0byANCnNlbmQiKS4gDQoNCklmICJBIiBpcyBp
bnRlbmRlZCwgSSBzdWdnZXN0IHJld29yZGluZyB0aGUgdGV4dCB0byBtYWtlIGl0IGNsZWFyZXIg
DQoNCjxxdW90ZWQgZnJvbSBiZWxvdz4NCiBGb3IgZXhhbXBsZSBpZiB0aGUgcmVhY3Rpbmcgbm9k
ZSBoYXMgYmVlbiBzZW5kaW5nIA0KIDEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8gdGhlIHJlcG9y
dGluZyBub2RlLCB0aGVuIA0KIGEgcmVjZXB0aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdl
IHZhbHVlIG9mIDEwIA0KIHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcg
bm9kZSBNVVNUIA0KIG9ubHkgc2VuZCA5MCBwYWNrZXRzIHBlciBzZWNvbmQuIA0KIA0KTWF5YmUg
aXQgd291bGQgYmUgZXZlbiBlYXNpZXIgdG8gcmV2ZXJzZSB0aGUgc2VudGVuY2UgYXMgZm9sbG93
OiANCiANCkZvciBleGFtcGxlIGlmIGFuIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9m
IA0KMTAgaGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGluZyBub2RlIHdoaWNoIA0Kd291bGQg
bm9ybWFsbHkgc2VuZCAxMDAgcGFja2V0cyBNVVNUIG9ubHkgc2VuZCA5MCANCnBhY2tldHMgdG8g
dGhlIHJlcG9ydGluZyBub2RlLiANCjwvcXVvdGVkIGZyb20gYmVsb3c+IA0KDQoNCkl0IGlzIHBv
c3NpYmxlIHRoYXQgeW91ciAid291bGQgbm9ybWFsbHkgc2VuZCIgaXMgdGhlIHNhbWUgYXMgbXkg
IndhbnRzIHRvIA0Kc2VuZCIsIGJ1dCB0aGF0IGlzbid0IHRoZSB3YXkgaXQgcmVhZHMsIGF0IGxl
YXN0IHRvIG1lLiANCg0KVGhhbmtzLCANCg0KSmFuZXQNCg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVz
c2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIA0KZGVs
ZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhl
IG1pc3Rha2UgaW4gDQpkZWxpdmVyeS4gTk9URTogUmVnYXJkbGVzcyBvZiBjb250ZW50LCB0aGlz
IGUtbWFpbCBzaGFsbCBub3Qgb3BlcmF0ZSB0byANCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBv
dGhlciBjb250cmFjdCB1bmxlc3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgDQp3cml0dGVuIGFncmVl
bWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVz
ZSBvZiANCmUtbWFpbCBmb3Igc3VjaCBwdXJwb3NlLiANCg0KDQoNCkZyb206ICAgICAgICBTdGV2
ZSBEb25vdmFuIDxzcmRvbm92YW5AdXNkb25vdmFucy5jb20+IA0KVG86ICAgICAgICBkaW1lQGll
dGYub3JnIA0KRGF0ZTogICAgICAgIDAzLzAzLzIwMTQgMDE6NTIgUE0gDQpTdWJqZWN0OiAgICAg
ICAgUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiAN
CnByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uIA0KU2VudCBieTogICAgICAgICJEaU1FIiA8
ZGltZS1ib3VuY2VzQGlldGYub3JnPiANCg0KDQoNCg0KSmFuZXQsDQoNCkknbSBub3Qgc3VyZSB3
aHkgd2UgdXNlIHRoZSB3b3JkIHBhY2tldHMuICBJdCBzaG91bGQgYmUgcmVxdWVzdHMgaW5zdGVh
ZC4gDQpUaHJvdHRsaW5nIGRvZXMgbm90IGltcGFjdCBwYWNrZXRzIGNhcnJ5aW5nIGFuc3dlciBt
ZXNzYWdlcywgZm9yIGluc3RhbmNlLg0KDQpXaGF0IGlzIG1lYW50IGlzIHRoYXQgaWYgbm9ybWFs
IGhhbmRsaW5nIHdvdWxkIGhhdmUgcmVzdWx0ZWQgaW4gMTAwIA0KcmVxdWVzdCBtZXNzYWdlcyBi
ZWluZyBzZW50IHRoZW4gYW4gb3ZlcmxvYWQgcmVwb3J0IHJlcXVlc3RpbmcgYSByZWR1Y3Rpb24g
DQpvZiAxMCUgd291bGQgcmVzdWx0IGluIDkwIHJlcXVlc3QgbWVzc2FnZXMgYmVpbmcgc2VudCBh
bmQgMTAgcmVxdWVzdCANCm1lc3NhZ2VzIGJlaW5nIHRocm90dGxlZC4gIFRoZSBsb3NzIGFsZ29y
aXRobSBpcyBpbnRlbnRpb25hbGx5IHNpbXBsZSBhbmQgDQpzdGF0ZWxlc3MuICBUaGUgcHJvcG9z
ZWQgaW1wbGVtZW50YXRpb24gYmVpbmcgdG8gZHJvcCAxIGluIFggbWVzc2FnZXMgDQp3aGVyZSBY
IGlzIGNhbGN1bGF0ZWQgYmFzZWQgb24gdGhlIHJlcXVlc3RlZCBwZXJjZW50YWdlIHJlZHVjdGlv
biByZWNlaXZlZCANCmluIHRoZSBvdmVybG9hZCByZXBvcnQuICBUaGlzIGlzIG1lYW50IHRvIGJl
IGluZGVwZW5kZW50IG9mIGFueSBoeXN0ZXJlc2lzIA0KYW5kIGluZGVwZW5kZW50IG9mIHRoZSBh
cnJpdmFsIHJhdGUgb2Ygc2VydmljZSByZXF1ZXN0cy4gDQoNClN0ZXZlDQoNCk9uIDMvMy8xNCA2
OjA4IFBNLCBKYW5ldCBQIEd1bm4gd3JvdGU6IA0KSXQgc2VlbXMgdG8gbWUgdGhpcyBiZWdzIHRo
ZSBxdWVzdGlvbjogDQpXaGF0IGRvZXMgIm5vcm1hbGx5IHNlbmRzIDEwMCBwYWNrZXRzIiBhY3R1
YWxseSBNRUFOPyAgSG93IGlzIHRoZSBudW1iZXIgDQpvZiBwYWNrZXRzIGl0ICJub3JtYWxseSBz
ZW5kcyIgY2FsY3VsYXRlZD8gDQoNCkphbmV0DQoNClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2Uu
IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSANCmRlbGV0ZSB3
aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9mIHRoZSBtaXN0
YWtlIGluIA0KZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1h
aWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gDQpiaW5kIENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIg
Y29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4cGxpY2l0IA0Kd3JpdHRlbiBhZ3JlZW1lbnQg
b3IgZ292ZXJubWVudCBpbml0aWF0aXZlIGV4cHJlc3NseSBwZXJtaXR0aW5nIHRoZSB1c2Ugb2Yg
DQplLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4gDQoNCg0KDQpGcm9tOiAgICAgICAgPGxpb25lbC5t
b3JhbmRAb3JhbmdlLmNvbT4gDQpUbzogICAgICAgIEpvdW5pIEtvcmhvbmVuIDxqb3VuaS5ub3Nw
YW1AZ21haWwuY29tPiwgImRpbWVAaWV0Zi5vcmciIA0KPGRpbWVAaWV0Zi5vcmc+IA0KRGF0ZTog
ICAgICAgIDAyLzI4LzIwMTQgMDg6NTkgQU0gDQpTdWJqZWN0OiAgICAgICAgUmU6IFtEaW1lXSAj
NTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiANCnByZXZpb3VzIGhpc3Rv
cnkgLSBjb25jbHVzaW9uIA0KU2VudCBieTogICAgICAgICJEaU1FIiA8ZGltZS1ib3VuY2VzQGll
dGYub3JnPiANCg0KDQoNCg0KSm91bmksIEknbSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgT0sgd2l0
aCB0aGUgY29uY2x1c2lvbiBnaXZlbiBoZXJlIHRvbywgDQpyaWdodD8gSiANCiANCkRlIDogRGlN
RSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZSBNYXJpYSBDcnV6
IA0KQmFydG9sb21lDQpFbnZvecOpIDogbWVyY3JlZGkgMjYgZsOpdnJpZXIgMjAxNCAxMzo1Ng0K
w4AgOiBkaW1lQGlldGYub3JnDQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5v
dCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5IC0gY29uY2x1c2lvbiAN
CiANCkZpbmUgDQogDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgVFJPVFRJTiwgDQpKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykNClNlbnQ6
IG1pw6lyY29sZXMsIDI2IGRlIGZlYnJlcm8gZGUgMjAxNCA4OjQzDQpUbzogZGltZUBpZXRmLm9y
Zw0KU3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBi
YXNlZCBvbiBwcmV2aW91cyANCmhpc3RvcnkgLSBjb25jbHVzaW9uIA0KIA0KSGkgDQogDQpSZW1v
dmUg4oCcZnJvbSBub3cgb27igJ0gaXMgYWNjZXB0YWJsZSBmb3IgbWUsIGJ1dCAgSSBoYXZlIGEg
cHJlZmVyZW5jZSBmb3IgDQp0aGUgcmV2ZXJzZSB3b3JkaW5nIExpb25lbCBwcm9wb3Nlcywgd2hp
Y2ggaXMgc2hvcnRlciBhbmQgYnJpbmdzIHRoZSANCmNsYXJpZmljYXRpb24gSSB3YXMgbG9va2lu
ZyBmb3IsOiANCkZvciBleGFtcGxlIGlmIGFuIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVl
IG9mIA0KMTAgaGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGluZyBub2RlIHdoaWNoIA0Kd291
bGQgbm9ybWFsbHkgc2VuZCAxMDAgcGFja2V0cyBNVVNUIG9ubHkgc2VuZCA5MCANCnBhY2tldHMg
dG8gdGhlIHJlcG9ydGluZyBub2RlLiANCiANCiANCkJlc3QgcmVnYXJkcyANCiANCkpKYWNxdWVz
IA0KIA0KIA0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBw
YXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAyNCBmw6l2cmllciAyMDE0IDE3
OjAwDQrDgCA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxp
bmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyANCmhpc3RvcnkgLSBjb25jbHVz
aW9uIA0KIA0KSSdtIHdpdGggTGlvbmVsLiAgSSBkb24ndCB1bmRlcnN0YW5kIHdoeSB0aGUgcHJv
cG9zZWQgd29yZGluZyBpcyANCmNvbmZ1c2luZy4gIFJlYWN0aW5nIG5vZGVzIGFsd2F5cyBvbmx5
IGFwcGx5IHRoZSByZWR1Y3Rpb24gcGVyY2VudGFnZSBmb3IgDQp0aGUgcGVyaW9kIG9mIHRpbWUg
dGhhdCB0aGUgc3BlY2lmaWMgb3ZlcmxvYWQgcmVwb3J0IGlzIGFjdGl2ZS4gIFRoYXQgDQpwZXJp
b2QgZWl0aGVyIGVuZHMgd2hlbiBhIG5ldyBvdmVybG9hZCByZXBvcnQgaXMgcmVjZWl2ZWQgb3Ig
d2hlbiB0aGUgDQpvdmVybG9hZCByZXBvcnQgZXhwaXJlcy4NCg0KVGhhdCBzYWlkLCBJJ20gaGFw
cHkgd2l0aCBqdXN0IHJlbW92aW5nIHRoZSB3b3JkcyAiZnJvbSBubyBvbiIgYXMgcHJvcG9zZWQg
DQpieSBMaW9uZWwgYmVsb3cuDQoNClN0ZXZlDQoNCk9uIDIvMjQvMTQgNzoyNiBBTSwgbGlvbmVs
Lm1vcmFuZEBvcmFuZ2UuY29tIHdyb3RlOiANCkkgZG9uJ3Qgc2VlIHRoZSBpc3N1ZSwgYXMgZXhw
bGFpbmVkIGluIG15IG1haWwgYnV0IE9LIHRvIHJlbW92ZSBpdC4gDQogDQpJZiAiZm9yIG5vdyIg
aXMgcmVtb3ZlZCwgdGhlIHJlc3VsdGluZyB0ZXh0IHdvdWxkIGJlOiANCiANCiBGb3IgZXhhbXBs
ZSBpZiB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBzZW5kaW5nIA0KIDEwMCBwYWNrZXRzIHBl
ciBzZWNvbmQgdG8gdGhlIHJlcG9ydGluZyBub2RlLCB0aGVuIA0KIGEgcmVjZXB0aW9uIG9mIE9D
LVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDEwIA0KIHdvdWxkIG1lYW4gdGhhdCBmcm9t
IG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIA0KIG9ubHkgc2VuZCA5MCBwYWNrZXRzIHBl
ciBzZWNvbmQuIA0KIA0KTWF5YmUgaXQgd291bGQgYmUgZXZlbiBlYXNpZXIgdG8gcmV2ZXJzZSB0
aGUgc2VudGVuY2UgYXMgZm9sbG93OiANCiANCkZvciBleGFtcGxlIGlmIGFuIE9DLVJlZHVjdGlv
bi1QZXJjZW50YWdlIHZhbHVlIG9mIA0KMTAgaGFzIGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGlu
ZyBub2RlIHdoaWNoIA0Kd291bGQgbm9ybWFsbHkgc2VuZCAxMDAgcGFja2V0cyBNVVNUIG9ubHkg
c2VuZCA5MCANCnBhY2tldHMgdG8gdGhlIHJlcG9ydGluZyBub2RlLiANCiANCiANCkJ1dCBJJ20g
ZmluZSBpZiB0aGUgaW5pdGlhbCBwcm9wb3NlZCByZXZpc2VkIHRleHQgaXMga2VwdC4gDQogDQpM
aW9uZWwgDQogDQpEZSA6IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmddIERlIGxh
IHBhcnQgZGUgTWFyaWEgQ3J1eiANCkJhcnRvbG9tZSANCkVudm95w6kgOiBsdW5kaSAyNCBmw6l2
cmllciAyMDE0IDE0OjEzIA0Kw4AgOiBkaW1lQGlldGYub3JnIA0KT2JqZXQgOiBSZTogW0RpbWVd
ICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIA0KaGlz
dG9yeSAtIGNvbmNsdXNpb24gDQogDQpIZWxsbywgDQogDQpJIGFncmVlIHdpdGggVWxyaWNoJ3Mg
cHJvcG9zYWwgDQpDaGVlcnMgDQovTUNydXogDQogDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIA0KLSBERS9N
dW5pY2gpIA0KU2VudDogbHVuZXMsIDI0IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo0NiANClRvOiBl
eHQgVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpOyBkaW1lQGlldGYub3JnIA0K
U3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNl
ZCBvbiBwcmV2aW91cyANCmhpc3RvcnkgLSBjb25jbHVzaW9uIA0KIA0KSSBzaGFyZSBKSmFjcXVl
cyBjb25jZXJuLiBSZXBsYWNpbmcgImZyb20gbm93IG9uIiB3aXRoICJmb3IgdGhlIHBlcmlvZCAN
CnRoYXQgdGhlIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUiIA0KaXMgbWlzbGVhZGluZy4gTWF5
IGJlIGl0cyBiZXR0ZXIgdG8gc2ltcGx5IHJlbW92ZSAiZnJvbSBub3cgb24iLiANCiANClVscmlj
aCANCiANCiANCiANCiANCiANCkZyb206IERpTUUgW21haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBleHQgVFJPVFRJTiwgDQpKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVF
UykgDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDE0IDc6MTEgUE0gDQpUbzogZGltZUBp
ZXRmLm9yZyANClN1YmplY3Q6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQg
dG8gYmUgYmFzZWQgb24gcHJldmlvdXMgDQpoaXN0b3J5IC0gY29uY2x1c2lvbiANCiANCkhpIE1D
cnV6LCBTdGV2ZSANCiANCkkgYWxzbyBhZ3JlZSBvbiB0aGUgIndvdWxkIHNlbmQgIiBpbnN0ZWFk
IG9mIHRoZSAid291bGQgaGF2ZSBzZW50IiAgZm9yIA0Kc3VyZS4gIEJ1dCBJIGhhdmUgIGEgc21h
bGwgY29uY2Vybi8gY2xhcmlmaWNhdGlvbiAgYWJvdXQgdGhlIFN0ZXZlIGNvbW1lbnQgDQpvbiAg
ICJmb3IgdGhlIHBlcmlvZCB0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlIiBhbmQg
dGhlIGV4YW1wbGUgDQp0byB3aGljaCBpdCByZWZlcnMuIA0KIA0KRHVyaW5nIHRoZSB0aW1lIHRo
ZSBPTFIgaXMgYWN0aXZlLCB3aGljaCBtYXkgYmUgcmF0aGVyIGxvbmcsICB0aGUgdHJhZmZpYyAN
CnRoZSByZWFjdGluZyBub2RlIHdvdWxkIHNlbmQgbWF5IGJlIDEwMCBwYWNrZXQgIHdoZW4gaXQg
aGFzIGp1c3QgcmVjZWl2ZWQgDQp0aGUgT0xSLiBBIGJpdCBsYXRlciwgdGhlIHRyYWZmaWMgaXQg
d291bGQgc2VuZCBjb3VsZCBiZSAxMjAgKG9yIDgwKSwgYW5kIA0KZnJvbSB0aGUgT0xSIGRlZmlu
aXRpb24sICAgaXQgd291bGQgc2VuZCAxMjB4MCw5IChvciA4MCogMCw5KSBwYWNrZXRzLCBvbiAN
CndoaWNoIEkgYWdyZWUuIFRoaXMgaXMgaW4gbGluZSAgd2l0aCB0aGUgZXZlcnkgMTB0aCBwYWNr
ZXQgZHJvcHBpbmcgIG9uIA0Kd2hpY2ggSSBhbHNvIGFncmVlLiANCiANCkFzIHRoZSB0ZXh0ICAg
d291bGQgIGJlIHdyaXR0ZW4gd2l0aCB0aGUgU3RldmUgbW9kaWZpY2F0aW9uICwgd2UgbWF5IA0K
dW5kZXJzdGFuZCBpdCBpcyAgODAgUGFja2V0IGR1cmluZyBhbGwgdGhlIHRpbWUgIHRoZSBPTFIg
aXMgYWN0aXZlLiBOb3QgDQp5ZXQgdGhpbmsgdG8gYW4gYWx0ZXJuYXRpdmUgdGV4dCwgYnV0IGZp
cnN0IHRvIHNlZSBpZiB5b3UgYWdyZWUgd2l0aCBteSANCnJlbWFyay4gDQogDQpKSmFjcXVlcyAN
CiANCiANCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFy
dCBkZSANCmxpb25lbC5tb3JhbmRAb3JhbmdlLmNvbSANCkVudm95w6kgOiB2ZW5kcmVkaSAyMSBm
w6l2cmllciAyMDE0IDE4OjMzIA0Kw4AgOiBTdGV2ZSBEb25vdmFuOyBkaW1lQGlldGYub3JnIA0K
T2JqZXQgOiBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2Vk
IG9uIHByZXZpb3VzIA0KaGlzdG9yeSAtIGNvbmNsdXNpb24gDQogDQorMSAoaW5jbHVkaW5nIFN0
ZXZlIGNvbW1lbnQpIA0KIA0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4gDQpFbnZvecOpIDogdmVuZHJlZGkgMjEgZsOp
dnJpZXIgMjAxNCAxNjozNyANCsOAIDogZGltZUBpZXRmLm9yZyANCk9iamV0IDogUmU6IFtEaW1l
XSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyANCmhp
c3RvcnkgLSBjb25jbHVzaW9uIA0KIA0KTWFyaWEgQ3J1eiwgDQogDQpJIHN1cHBvcnQgeW91ciBz
dWdnZXN0ZWQgY2hhbmdlcy4gIEkgaGF2ZSBvbmUgZnVydGhlciBzdWdnZXN0ZWQgY2hhbmdlIA0K
YmVsb3cuIA0KIA0KU3RldmUgDQpPbiAyLzIxLzE0IDI6NDAgQU0sIE1hcmlhIENydXogQmFydG9s
b21lIHdyb3RlOiANCiM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHBy
ZXZpb3VzIGhpc3RvcnkgDQogDQpGb2xsb3dpbmcgYWdyZWVtZW50IGlzIHJlYWNoZWQ6IA0KIA0K
Tm93IChjaGFwdGVyIDQuNyk6IA0KICAgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIEFWUCAo
QVZQIGNvZGUgVEJEOCkgaXMgdHlwZSBvZiBVbnNpZ25lZDMyIA0KICAgYW5kIGRlc2NyaWJlcyB0
aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMgDQogICByZXF1
ZXN0ZWQgdG8gcmVkdWNlLCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3VsZCBoYXZl
IHNlbnQuIA0KIA0KUHJvcG9zYWw6IA0KICBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgQVZQ
IChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzIgICANCiAgYW5kIGRlc2NyaWJl
cyB0aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMgICANCiAg
cmVxdWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2Ugd291bGQg
c2VuZC4gIDwtLS0tIA0KIA0KIA0KTm93IChjaGFwdGVyIDUuNS4yKTogDQogICAgIEluZGljYXRl
cyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9kZSB0byANCiAg
ICAgcmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2VudGFnZS4gIEZvciBleGFtcGxl
IGlmIHRoZSANCiAgICAgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBzZW5kaW5nIDEwMCBwYWNrZXRz
IHBlciBzZWNvbmQgdG8gdGhlIA0KICAgICByZXBvcnRpbmcgbm9kZSwgdGhlbiBhIHJlY2VwdGlv
biBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSANCiAgICAgb2YgMTAgd291bGQgbWVh
biB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1Qgb25seSBzZW5kIA0KICAg
ICA5MCBwYWNrZXRzIHBlciBzZWNvbmQuICBIb3cgdGhlIHJlYWN0aW5nIG5vZGUgYWNoaWV2ZXMg
dGhlICJ0cnVlIA0KICAgICByZWR1Y3Rpb24iIHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRoZSBz
ZW50IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXAgDQogICAgIHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4g
IFRoZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeSANCiAgICAgMTB0aCBwYWNr
ZXQgZnJvbSBpdHMgb3V0cHV0IHF1ZXVlIGFuZCBsZXQgdGhlIGdlbmVyaWMgYXBwbGljYXRpb24g
DQogICAgIGxvZ2ljIHRyeSB0byByZWNvdmVyIGZyb20gaXQuMCA8IHZhbHVlIDwgMTAwIA0KIA0K
IFByb3Bvc2FsOiANCkluZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUg
cmVhY3Rpbmcgbm9kZSB0byByZWR1Y2UgDQppdHMgdHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRh
Z2UuIEZvciBleGFtcGxlIGlmIHRoZSANCnJlYWN0aW5nIG5vZGUgd291bGQgc2VuZCAxMDAgcGFj
a2V0cyB0byB0aGUgICAgICAgICAgICAgICAgICAgICAgICAgIDwtLS0gDQpyZXBvcnRpbmcgbm9k
ZSwgdGhlbiBhIHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSBvZiAN
CjEwIHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIG9u
bHkgc2VuZCANCjkwIHBhY2tldHMgaW5zdGVhZCBvZiAxMDAuIEhvdyB0aGUgcmVhY3Rpbmcgbm9k
ZSBhY2hpZXZlcyB0aGUgInRydWUgPC0tLSANCnJlZHVjdGlvbiIgdHJhbnNhY3Rpb25zIGxlYWRp
bmcgdG8gdGhlIHNlbnQgcmVxdWVzdCBtZXNzYWdlcyBpcyB1cCB0byANCnRoZSBpbXBsZW1lbnRh
dGlvbi4gVGhlIHJlYWN0aW5nIG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5IDEwdGggDQpwYWNr
ZXQgZnJvbSBpdHMgb3V0cHV0IHF1ZXVlIGFuZCBsZXQgdGhlIGdlbmVyaWMgYXBwbGljYXRpb24g
bG9naWMgdHJ5IA0KdG8gcmVjb3ZlciBmcm9tIGl0LiANClNSRD4gUmVwbGFjZSAiZnJvbSBub3cg
b24iIGluIHRoZSBhYm92ZSB3aXRoICJmb3IgdGhlIHBlcmlvZCB0aGF0IHRoZSANCm92ZXJsb2Fk
IHJlcG9ydCBpcyBhY3RpdmUiIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQpEaU1FIG1haWxpbmcgbGlzdCANCkRp
TUVAaWV0Zi5vcmcgDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUg
DQogDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fIA0KDQogDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw
ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQpjb25maWRlbnRpZWxsZXMgb3UgcHJp
dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyANCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0
ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogDQpyZWN1IGNlIG1l
c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgDQphIGwnZXhwZWRpdGV1ciBl
dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg
DQplbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIA0KT3Jhbmdl
IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs
IGRlZm9ybWUgb3UgDQpmYWxzaWZpZS4gTWVyY2kuIA0KIA0KVGhpcyBtZXNzYWdlIGFuZCBpdHMg
YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgDQppbmZv
cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyANCnRoZXkgc2hvdWxkIG5vdCBi
ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLiANCklm
IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl
IHNlbmRlciBhbmQgDQpkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuIA0K
QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn
ZXMgdGhhdCBoYXZlIGJlZW4gDQptb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuIA0KVGhh
bmsgeW91LiANCiANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18gDQoNCiANCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu
dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCmNvbmZpZGVudGllbGxlcyBv
dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIA0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4
cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiANCnJlY3Ug
Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciANCmEgbCdleHBlZGl0
ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz
YWdlcyANCmVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgDQpP
cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs
dGVyZSwgZGVmb3JtZSBvdSANCmZhbHNpZmllLiBNZXJjaS4gDQogDQpUaGlzIG1lc3NhZ2UgYW5k
IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCAN
CmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IA0KdGhleSBzaG91bGQg
bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u
IA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlm
eSB0aGUgc2VuZGVyIGFuZCANCmRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50
cy4gDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBt
ZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiANCm1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4g
DQpUaGFuayB5b3UuIA0KIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18gDQpEaU1FIG1haWxpbmcgbGlzdCANCkRpTUVAaWV0Zi5vcmcgDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUgDQogDQogDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1l
c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0
aW9ucyANCmNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j
DQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv
bi4gU2kgdm91cyBhdmV6IA0KcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl
IHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp
ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgDQplbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp
YmxlcyBkJ2FsdGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz
aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSANCmZhbHNpZmllLiBNZXJjaS4N
Cg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50
aWFsIG9yIHByaXZpbGVnZWQgDQppbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg
bGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo
b3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy
cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIA0KZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg
bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gDQptb2RpZmllZCwgY2hhbmdl
ZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcNCmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQoNCg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRpTUUgbWFpbGluZyBsaXN0
DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rp
bWUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkRp
TUUgbWFpbGluZyBsaXN0DQpEaU1FQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL2RpbWUNCg0K
--=_alternative 006185D785257C91_=
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: base64

PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgdGhlIGludGVudCwgaW4gY2hh
bmdpbmcgZnJvbSAmcXVvdDtoYXMNCmJlZW4gc2VuZGluZyAmbmJzcDsxMDAgcmVxdWVzdHMgcGVy
IHNlY29uZCZxdW90OyB0byAmcXVvdDt3b3VsZCBub3JtYWxseQ0Kc2VuZCAxMDAgcmVxdWVzdHMm
cXVvdDsgd2FzIHRvIGdldCByaWQgb2YgdGhlIHJlZmVyZW5jZSB0byBhICZuYnNwOyZxdW90O2hp
c3RvcmljYWwNCiZuYnNwO3RyYW5zbWlzc2lvbiByYXRlJnF1b3Q7LjwvZm9udD4NCjxicj4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlIHBocmFzZSwgJnF1b3Q7d291bGQg
bm9ybWFsbHkgc2VuZCZxdW90Ow0Kc3RpbGwgaGFzIHRoZSBjb25ub3RhdGlvbiAoZm9yIG1lIGFu
eXdheSkgb2YgYSAmcXVvdDtoaXN0b3JpY2FsICZuYnNwO3RyYW5zbWlzc2lvbg0KcmF0ZSZxdW90
Oy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBvc3Np
YmxlIHN1Z2dlc3Rpb25zIGFyZSA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt
c2VyaWYiPiZxdW90O3dvdWxkLCB3aXRob3V0IG92ZXJsb2FkIGNvbnRyb2wsDQpzZW5kIDEwMCBy
ZXF1ZXN0cyZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+
b3IgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDt3b3Vs
ZCBvdGhlcndpc2Ugc2VuZCAxMDAgcmVxdWVzdHMmcXVvdDsNCih3aGljaCBpcyBjb25zaXN0ZW50
IHdpdGggdGhlIHdvcmRpbmcgaW4gNC43KS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9InNhbnMtc2VyaWYiPkp1c3QgdHJ5aW5nIHRvIG1ha2UgaXQgY2xlYXJlciB0byBmdXR1
cmUNCnJlYWRlcnMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl
cmlmIj5UaGFua3M8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy
aWYiPkphbmV0PGJyPg0KPGJyPg0KVGhpcyBpcyBhIFBSSVZBVEUgbWVzc2FnZS4gSWYgeW91IGFy
ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlDQpkZWxldGUgd2l0aG91dCBjb3B5
aW5nIGFuZCBraW5kbHkgYWR2aXNlIHVzIGJ5IGUtbWFpbCBvZiB0aGUgbWlzdGFrZSBpbg0KZGVs
aXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90
IG9wZXJhdGUgdG8NCmJpbmQgQ1NDIHRvIGFueSBvcmRlciBvciBvdGhlciBjb250cmFjdCB1bmxl
c3MgcHVyc3VhbnQgdG8gZXhwbGljaXQgd3JpdHRlbg0KYWdyZWVtZW50IG9yIGdvdmVybm1lbnQg
aW5pdGlhdGl2ZSBleHByZXNzbHkgcGVybWl0dGluZyB0aGUgdXNlIG9mIGUtbWFpbA0KZm9yIHN1
Y2ggcHVycG9zZS48L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0xIGNv
bG9yPSM1ZjVmNWYgZmFjZT0ic2Fucy1zZXJpZiI+RnJvbTogJm5ic3A7ICZuYnNwOyAmbmJzcDsN
CiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+TWFyaWEgQ3J1eiBC
YXJ0b2xvbWUNCiZsdDttYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmljc3Nvbi5jb20mZ3Q7PC9mb250
Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPlRvOiAm
bmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5z
LXNlcmlmIj5KYW5ldCBQIEd1bm4vVVNBL0NTQ0BDU0MsDQpTdGV2ZSBEb25vdmFuICZsdDtzcmRv
bm92YW5AdXNkb25vdmFucy5jb20mZ3Q7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0j
NWY1ZjVmIGZhY2U9InNhbnMtc2VyaWYiPkNjOiAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7
PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5EaU1FICZsdDtkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmcmZ3Q7LA0KJnF1b3Q7ZGltZUBpZXRmLm9yZyZxdW90OyAmbHQ7ZGltZUBpZXRm
Lm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0ic2Fu
cy1zZXJpZiI+RGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzwvZm9udD48Zm9udCBz
aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MDMvMDMvMjAxNCAwNjowMyBQTTwvZm9udD4NCjxicj48
Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJzYW5zLXNlcmlmIj5TdWJqZWN0OiAmbmJz
cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl
cmlmIj5SRTogW0RpbWVdICM1MjoNClRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBv
biBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbjwvZm9udD4NCjxicj4NCjxociBub3NoYWRl
Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGli
cmkiPkhlbGxvIEphbmV0LCBhbGwsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0
MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9
IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5UaGUgcHJlLWFncmVlZCBwcm9wb3NhbCBpcw0KdGhlIGZv
bGxvd2luZzo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2Fs
aWJyaSI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5Ob3cg
KGNoYXB0ZXIgNC43KTogPGJyPg0KICZuYnNwOyBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2Ug
QVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzINCjxicj4NCiAmbmJzcDsg
YW5kIGRlc2NyaWJlcyB0aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5k
ZXIgaXMNCjxicj4NCiAmbmJzcDsgcmVxdWVzdGVkIHRvIHJlZHVjZSwgY29tcGFyZWQgdG8gd2hh
dCBpdCBvdGhlcndpc2UgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJy
aSI+d291bGQNCmhhdmUgc2VudDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+LiA8
YnI+DQogPGJyPg0KUHJvcG9zYWw6IDxicj4NCiAmbmJzcDtUaGUgT0MtUmVkdWN0aW9uLVBlcmNl
bnRhZ2UgQVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzINCiZuYnNwOyA8
YnI+DQogJm5ic3A7YW5kIGRlc2NyaWJlcyB0aGUgcGVyY2VudGFnZSBvZiB0aGUgdHJhZmZpYyB0
aGF0IHRoZSBzZW5kZXIgaXMgJm5ic3A7DQo8YnI+DQogJm5ic3A7cmVxdWVzdGVkIHRvIHJlZHVj
ZSwgY29tcGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2UgPC9mb250Pjxmb250IHNpemU9MiBjb2xv
cj1yZWQgZmFjZT0iQ2FsaWJyaSI+d291bGQNCnNlbmQ8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
IkNhbGlicmkiPi48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0K
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZu
YnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Tm93IChjaGFwdGVy
IDUuNS4yKTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAm
bmJzcDsgSW5kaWNhdGVzIHRoYXQgdGhlIHJlcG9ydGluZw0Kbm9kZSB1cmdlcyB0aGUgcmVhY3Rp
bmcgbm9kZSB0bzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7
ICZuYnNwOyByZWR1Y2UgaXRzIHRyYWZmaWMgYnkgYSBnaXZlbg0KcGVyY2VudGFnZS4gJm5ic3A7
PC9mb250Pjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Rm9yIGV4YW1wbGUN
CmlmIHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZhY2U9IkNhbGlicmki
PiZuYnNwOyAmbmJzcDsgcmVhY3Rpbmcgbm9kZSBoYXMNCmJlZW4gc2VuZGluZyAxMDAgcGFja2V0
cyBwZXIgc2Vjb25kIHRvIHRoZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9cmVkIGZh
Y2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgcmVwb3J0aW5nIG5vZGUsDQp0aGVuIGEgcmVjZXB0
aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlPC9mb250Pg0KPGJyPjxmb250IHNp
emU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyBvZiAxMCB3b3VsZCBt
ZWFuDQp0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1Qgb25seSBzZW5kPC9m
b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZu
YnNwOyA5MCBwYWNrZXRzIHBlcg0Kc2Vjb25kPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDYWxp
YnJpIj4uICZuYnNwO0hvdyB0aGUgcmVhY3Rpbmcgbm9kZQ0KYWNoaWV2ZXMgdGhlICZxdW90O3Ry
dWU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsg
cmVkdWN0aW9uJnF1b3Q7IHRyYW5zYWN0aW9ucw0KbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0
IG1lc3NhZ2VzIGlzIHVwPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4m
bmJzcDsgJm5ic3A7IHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4gJm5ic3A7VGhlDQpyZWFjdGluZyBu
b2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i
Q2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAxMHRoIHBhY2tldCBmcm9tIGl0cyBvdXRwdXQNCnF1ZXVl
IGFuZCBsZXQgdGhlIGdlbmVyaWMgYXBwbGljYXRpb248L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y
IGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgbG9naWMgdHJ5IHRvIHJlY292ZXIgZnJvbQ0K
aXQuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmki
PiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UHJvcG9zYWw6
PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7IElu
ZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcNCm5vZGUgdXJnZXMgdGhlIHJlYWN0aW5nIG5vZGUg
dG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsg
cmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4NCnBlcmNlbnRhZ2U8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4uIEZvciBleGFtcGxlIGlmDQphbiA8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7
IE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlDQp2YWx1ZSBvZiAmbmJzcDsxMCBoYXMgYmVlbiByZWNl
aXZlZCwgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+
Jm5ic3A7ICZuYnNwOyB0aGUgcmVhY3Rpbmcgbm9kZQ0Kd2hpY2ggJm5ic3A7d291bGQgbm9ybWFs
bHkgc2VuZCAxMDAgPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA4MmJmIGZhY2U9IkNhbGli
cmkiPnJlcXVlc3RzDQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPXJlZCBmYWNlPSJD
YWxpYnJpIj4mbmJzcDsgJm5ic3A7IE1VU1Qgb25seSBzZW5kDQo5MCA8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGNvbG9yPSMwMDgyYmYgZmFjZT0iQ2FsaWJyaSI+cmVxdWVzdHMgPC9mb250Pjxmb250IHNp
emU9MiBjb2xvcj1yZWQgZmFjZT0iQ2FsaWJyaSI+dG8NCnRoZSByZXBvcnRpbmcgbm9kZTwvZm9u
dD48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg
ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyBIb3cgdGhlIHJlYWN0aW5nIG5vZGUgYWNoaWV2
ZXMNCnRoZSAmcXVvdDt0cnVlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy
aSI+Jm5ic3A7ICZuYnNwOyByZWR1Y3Rpb24mcXVvdDsgdHJhbnNhY3Rpb25zDQpsZWFkaW5nIHRv
IHRoZSBzZW50IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXAgPC9mb250Pg0KPGJyPjxmb250IHNpemU9
MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7IHRvIHRoZSBpbXBsZW1lbnRhdGlvbi4gVGhl
DQpyZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeSAxMHRoIDwvZm9udD4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXpl
PTIgY29sb3I9IzAwODJiZiBmYWNlPSJDYWxpYnJpIj5yZXF1ZXN0DQo8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGZhY2U9IkNhbGlicmkiPmZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5l
cmljDQphcHBsaWNhdGlvbiBsb2dpYyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh
bGlicmkiPiZuYnNwOyAmbmJzcDt0cnkgdG8gcmVjb3ZlciBmcm9tIGl0LjwvZm9udD4NCjxicj48
Zm9udCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj4mbmJzcDs8L2ZvbnQ+DQo8
YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7PC9mb250
Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPkxldCBtZSBr
bm93IGlmIHRoaXMgdGV4dA0KY292ZXJzIHlvdXIgY29uY2VybnMuPC9mb250Pg0KPGJyPjxmb250
IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPkkgdG9vayBwcm9maXQgdG8gcmVw
bGFjZQ0KcGFja2V0IGJ5IHJlcXVlc3QuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0j
MDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29s
b3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj5CZXN0IHJlZ2FyZHM8L2ZvbnQ+DQo8YnI+PGZvbnQg
c2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+L01DcnV6PC9mb250Pg0KPGJyPjxm
b250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPiZuYnNwOzwvZm9udD4NCjxi
cj48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gRGlNRSBbPC9mb250Pjxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBmYWNlPSJU
YWhvbWEiPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC9hPjxmb250IHNpemU9
MiBmYWNlPSJUYWhvbWEiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFuZXQgUCBHdW5uPGI+PGJy
Pg0KU2VudDo8L2I+IGx1bmVzLCAwMyBkZSBtYXJ6byBkZSAyMDE0IDIxOjA4PGI+PGJyPg0KVG86
PC9iPiBTdGV2ZSBEb25vdmFuPGI+PGJyPg0KQ2M6PC9iPiBEaU1FOyBkaW1lQGlldGYub3JnPGI+
PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQg
dG8gYmUgYmFzZWQgb24gcHJldmlvdXMNCmhpc3RvcnkgLSBjb25jbHVzaW9uPC9mb250Pg0KPGJy
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxicj48
Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPk9LLCBJIGFkbWl0IHRvIGJlaW5nIGNvbmZ1c2VkLjwv
Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48
Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkluZGVwZW5kZW50IG9mIHRoZSBwYWNrZXRz
IHZzIHJlcXVlc3RzIGRpc3RpbmN0aW9uLTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N
CkFzc3VtaW5nIGEgbm9kZSByZWNlaXZlcyBhIG1lc3NhZ2UgcmVxdWlyaW5nIDEwJSByZWR1Y3Rp
b24sIGRvZXMgdGhpcyBtZWFuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQSAtIFRo
ZSBub2RlIHdpbGwgZHJvcCBvbmUgb3V0IG9mIGV2ZXJ5IDEwIHJlcXVlc3RzIGl0ICZxdW90O3dh
bnRzJnF1b3Q7DQp0byBzZW5kICwgd2hldGhlciBpdCAmcXVvdDt3YW50cyZxdW90OyB0byBzZW5k
IDEwIHJlcXVlc3RzIG9yIDEwMDAgcmVxdWVzdHMNCnBlciB1bml0IHRpbWUuPC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y
IGZhY2U9IkFyaWFsIj48YnI+DQpvciA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l
dyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KQi0g
SWYgaXQgJnF1b3Q7bm9ybWFsbHkmcXVvdDsgc2VuZHMgMTAwIG1lc3NhZ2VzIHBlciB1bml0IHRp
bWUsIGl0IHdpbGwNCnJlc3RyaWN0IGl0c2VsZiB0byA5MCBtZXNzYWdlcyBwZXIgdW5pdCB0aW1l
LCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgaXQNCiZxdW90O3dhbnRzJnF1b3Q7IHRvIHNlbmQgMTAg
b3IgMTAwMDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9u
dD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCj88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh
Y2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJp
YWwiPjxicj4NCiZxdW90O0EmcXVvdDsgbWFrZXMgbW9yZSBzZW5zZSB0byBtZSwgYnV0IHRoZSBw
cm9wb3NlZCB0ZXh0IChyZXBlYXRlZCBiZWxvdykNCnNlZW1zIHRvIGltcGx5ICZxdW90O0ImcXVv
dDsgKDkwIHBhY2tldHMgcGVyIHNlY29uZCBiYXNlZCBvbiB3aGF0IGl0ICZxdW90O2hhcw0KYmVl
biBzZW5kaW5nJnF1b3Q7IG9yICZxdW90O3dvdWxkIG5vcm1hbGx5IHNlbmQmcXVvdDsgaW5kZXBl
bmRlbnQgb2YgdGhlDQpudW1iZXIgdGhlIG5vZGUgJnF1b3Q7d2FudHMmcXVvdDsgdG8gc2VuZCZx
dW90OykuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0K
PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KSWYgJnF1b3Q7QSZxdW90OyBp
cyBpbnRlbmRlZCwgSSBzdWdnZXN0IHJld29yZGluZyB0aGUgdGV4dCB0byBtYWtlIGl0IGNsZWFy
ZXI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2Zv
bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQombHQ7cXVvdGVkIGZyb20g
YmVsb3cmZ3Q7PGJyPg0KIEZvciBleGFtcGxlIGlmIHRoZSByZWFjdGluZyBub2RlIDxiPmhhcyBi
ZWVuIHNlbmRpbmc8L2I+PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PjxiPg0KPC9iPjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxiPjxicj4N
CiAxMDAgcGFja2V0cyBwZXIgc2Vjb25kPC9iPiB0byB0aGUgcmVwb3J0aW5nIG5vZGUsIHRoZW48
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogYSByZWNlcHRpb24gb2YgT0MtUmVkdWN0
aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgMTA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+
DQogd291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBub2RlIE1VU1Q8L2Zv
bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogb25seSBzZW5kPGI+IDkwIHBhY2tldHMgcGVy
IHNlY29uZDwvYj4uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk1heWJl
IGl0IHdvdWxkIGJlIGV2ZW4gZWFzaWVyIHRvIHJldmVyc2UgdGhlIHNlbnRlbmNlIGFzIGZvbGxv
dzo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQogPC9m
b250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KRm9yIGV4YW1wbGUgaWYg
YW4gT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgPGJyPg0KMTAgaGFzIGJlZW4gcmVj
ZWl2ZWQsIHRoZSByZWFjdGluZyBub2RlIHdoaWNoIDxicj4NCndvdWxkIG5vcm1hbGx5IHNlbmQg
MTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgPGJyPg0KcGFja2V0cyB0byB0aGUgcmVwb3J0
aW5nIG5vZGUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9m
b250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmx0Oy9xdW90ZWQgZnJv
bSBiZWxvdyZndDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxi
cj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkl0IGlzIHBv
c3NpYmxlIHRoYXQgeW91ciAmcXVvdDt3b3VsZCBub3JtYWxseSBzZW5kJnF1b3Q7IGlzIHRoZSBz
YW1lIGFzDQpteSAmcXVvdDt3YW50cyB0byBzZW5kJnF1b3Q7LCBidXQgdGhhdCBpc24ndCB0aGUg
d2F5IGl0IHJlYWRzLCBhdCBsZWFzdA0KdG8gbWUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48
YnI+DQpUaGFua3MsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8
YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpKYW5ldDxicj4NCjxi
cj4NClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQsIHBsZWFzZQ0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFk
dmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4NCmRlbGl2ZXJ5LiBOT1RFOiBSZWdh
cmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvDQpiaW5k
IENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4
cGxpY2l0IHdyaXR0ZW4NCmFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVz
c2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwNCmZvciBzdWNoIHB1cnBvc2UuPC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8YnI+DQo8YnI+DQo8
L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0iQXJpYWwiPjxicj4NCkZyb206
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTEgZmFjZT0iQXJp
YWwiPlN0ZXZlDQpEb25vdmFuICZsdDtzcmRvbm92YW5AdXNkb25vdmFucy5jb20mZ3Q7PC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9
MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFsIj48YnI+DQpUbzogJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+ZGltZUBpZXRmLm9yZzwv
Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz
aXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+PGJyPg0KRGF0ZTogJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+MDMvMDMvMjAx
NA0KMDE6NTIgUE08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwv
Zm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBmYWNlPSJBcmlhbCI+PGJyPg0KU3ViamVj
dDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MSBmYWNlPSJB
cmlhbCI+UmU6DQpbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQg
b24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFj
ZT0iQXJpYWwiPjxicj4NClNlbnQgYnk6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9u
dD48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90O0RpTUUmcXVvdDsNCiZsdDtkaW1lLWJv
dW5jZXNAaWV0Zi5vcmcmZ3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPC9mb250Pg0KPGRpdiBhbGlnbj1jZW50ZXI+DQo8YnI+DQo8aHIgbm9zaGFkZT48L2Rp
dj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8YnI+DQo8
YnI+DQpKYW5ldCw8YnI+DQo8YnI+DQpJJ20gbm90IHN1cmUgd2h5IHdlIHVzZSB0aGUgd29yZCBw
YWNrZXRzLiAmbmJzcDtJdCBzaG91bGQgYmUgcmVxdWVzdHMgaW5zdGVhZC4NCiZuYnNwO1Rocm90
dGxpbmcgZG9lcyBub3QgaW1wYWN0IHBhY2tldHMgY2FycnlpbmcgYW5zd2VyIG1lc3NhZ2VzLCBm
b3INCmluc3RhbmNlLjxicj4NCjxicj4NCldoYXQgaXMgbWVhbnQgaXMgdGhhdCBpZiBub3JtYWwg
aGFuZGxpbmcgd291bGQgaGF2ZSByZXN1bHRlZCBpbiAxMDAgcmVxdWVzdA0KbWVzc2FnZXMgYmVp
bmcgc2VudCB0aGVuIGFuIG92ZXJsb2FkIHJlcG9ydCByZXF1ZXN0aW5nIGEgcmVkdWN0aW9uIG9m
IDEwJQ0Kd291bGQgcmVzdWx0IGluIDkwIHJlcXVlc3QgbWVzc2FnZXMgYmVpbmcgc2VudCBhbmQg
MTAgcmVxdWVzdCBtZXNzYWdlcw0KYmVpbmcgdGhyb3R0bGVkLiAmbmJzcDtUaGUgbG9zcyBhbGdv
cml0aG0gaXMgaW50ZW50aW9uYWxseSBzaW1wbGUgYW5kIHN0YXRlbGVzcy4NCiZuYnNwO1RoZSBw
cm9wb3NlZCBpbXBsZW1lbnRhdGlvbiBiZWluZyB0byBkcm9wIDEgaW4gWCBtZXNzYWdlcyB3aGVy
ZSBYDQppcyBjYWxjdWxhdGVkIGJhc2VkIG9uIHRoZSByZXF1ZXN0ZWQgcGVyY2VudGFnZSByZWR1
Y3Rpb24gcmVjZWl2ZWQgaW4gdGhlDQpvdmVybG9hZCByZXBvcnQuICZuYnNwO1RoaXMgaXMgbWVh
bnQgdG8gYmUgaW5kZXBlbmRlbnQgb2YgYW55IGh5c3RlcmVzaXMNCmFuZCBpbmRlcGVuZGVudCBv
ZiB0aGUgYXJyaXZhbCByYXRlIG9mIHNlcnZpY2UgcmVxdWVzdHMuIDxicj4NCjxicj4NClN0ZXZl
PGJyPg0KPGJyPg0KT24gMy8zLzE0IDY6MDggUE0sIEphbmV0IFAgR3VubiB3cm90ZTogPC9mb250
Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KSXQgc2VlbXMgdG8gbWUgdGhpcyBiZWdz
IHRoZSBxdWVzdGlvbjo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpXaGF0IGRvZXMgJnF1b3Q7
bm9ybWFsbHkgc2VuZHMgMTAwIHBhY2tldHMmcXVvdDsgYWN0dWFsbHkgTUVBTj8gJm5ic3A7SG93
DQppcyB0aGUgbnVtYmVyIG9mIHBhY2tldHMgaXQgJnF1b3Q7bm9ybWFsbHkgc2VuZHMmcXVvdDsg
Y2FsY3VsYXRlZD88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8
L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQo8YnI+DQpKYW5ldDxicj4NCjxi
cj4NClRoaXMgaXMgYSBQUklWQVRFIG1lc3NhZ2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl
ZCByZWNpcGllbnQsIHBsZWFzZQ0KZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFk
dmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4NCmRlbGl2ZXJ5LiBOT1RFOiBSZWdh
cmRsZXNzIG9mIGNvbnRlbnQsIHRoaXMgZS1tYWlsIHNoYWxsIG5vdCBvcGVyYXRlIHRvDQpiaW5k
IENTQyB0byBhbnkgb3JkZXIgb3Igb3RoZXIgY29udHJhY3QgdW5sZXNzIHB1cnN1YW50IHRvIGV4
cGxpY2l0IHdyaXR0ZW4NCmFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVz
c2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwNCmZvciBzdWNoIHB1cnBvc2UuPC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQo8YnI+DQo8L2ZvbnQ+
PGZvbnQgc2l6ZT0xIGNvbG9yPSM1ZjVmNWYgZmFjZT0iQXJpYWwiPjxicj4NCjxicj4NCkZyb206
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD48YSBocmVmPW1haWx0bzpsaW9uZWwu
bW9yYW5kQG9yYW5nZS5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1
PiZsdDtsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20mZ3Q7PC91PjwvZm9udD48L2E+PGZvbnQgc2l6
ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGNvbG9yPSM1
ZjVmNWYgZmFjZT0iQXJpYWwiPjxicj4NClRvOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8
L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5Kb3VuaSBLb3Job25lbg0KPC9mb250Pjxh
IGhyZWY9bWFpbHRvOmpvdW5pLm5vc3BhbUBnbWFpbC5jb20+PGZvbnQgc2l6ZT0xIGNvbG9yPWJs
dWUgZmFjZT0iQXJpYWwiPjx1PiZsdDtqb3VuaS5ub3NwYW1AZ21haWwuY29tJmd0OzwvdT48L2Zv
bnQ+PC9hPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+LA0KPC9mb250PjxhIGhyZWY9bWFpbHRv
OmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PiZx
dW90O2RpbWVAaWV0Zi5vcmcmcXVvdDs8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTEgZmFjZT0i
QXJpYWwiPg0KPC9mb250PjxhIGhyZWY9bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0x
IGNvbG9yPWJsdWUgZmFjZT0iQXJpYWwiPjx1PiZsdDtkaW1lQGlldGYub3JnJmd0OzwvdT48L2Zv
bnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250
IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFsIj48YnI+DQpEYXRlOiAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4wMi8yOC8y
MDE0DQowODo1OSBBTTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4g
PC9mb250Pjxmb250IHNpemU9MSBjb2xvcj0jNWY1ZjVmIGZhY2U9IkFyaWFsIj48YnI+DQpTdWJq
ZWN0OiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0xIGZhY2U9
IkFyaWFsIj5SZToNCltEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNl
ZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbjwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTEgY29sb3I9IzVmNWY1ZiBm
YWNlPSJBcmlhbCI+PGJyPg0KU2VudCBieTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9m
b250Pjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7RGlNRSZxdW90Ow0KPC9mb250Pjxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MSBjb2xvcj1i
bHVlIGZhY2U9IkFyaWFsIj48dT4mbHQ7ZGltZS1ib3VuY2VzQGlldGYub3JnJmd0OzwvdT48L2Zv
bnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pg0KPGRp
diBhbGlnbj1jZW50ZXI+DQo8YnI+DQo8aHIgbm9zaGFkZT48L2Rpdj4NCjxicj48Zm9udCBzaXpl
PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KPGJyPg0KSm91bmksIEknbSBhc3N1bWluZyB0
aGF0IHlvdSBhcmUgT0sgd2l0aCB0aGUgY29uY2x1c2lvbiBnaXZlbiBoZXJlIHRvbywNCnJpZ2h0
PyA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iV2luZ2RpbmdzIj5KPC9m
b250Pjxmb250IHNpemU9MiBjb2xvcj0jMDA0MDgwIGZhY2U9IkNhbGlicmkiPg0KPC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0KRGUgOjwvYj4gRGlNRSBbPC9mb250PjxhIGhyZWY9
Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh
Y2U9IlRhaG9tYSI+PHU+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9h
Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPl0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IE1hcmlh
IENydXogQmFydG9sb21lPGI+PGJyPg0KRW52b3nDqSA6PC9iPiBtZXJjcmVkaSAyNiBmw6l2cmll
ciAyMDE0IDEzOjU2PGI+PGJyPg0Kw4AgOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOmRpbWVA
aWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5kaW1lQGll
dGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0K
T2JqZXQgOjwvYj4gUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBi
YXNlZCBvbiBwcmV2aW91cw0KaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KRmluZTwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iVGFo
b21hIj48Yj48YnI+DQpGcm9tOjwvYj4gRGlNRSBbPC9mb250PjxhIGhyZWY9Im1haWx0bzpkaW1l
LWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IlRhaG9tYSI+
PHU+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9
MiBmYWNlPSJUYWhvbWEiPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VFJPVFRJTiwgSkVBTi1KQUNR
VUVTIChKRUFOLUpBQ1FVRVMpPGI+PGJyPg0KU2VudDo8L2I+IG1pw6lyY29sZXMsIDI2IGRlIGZl
YnJlcm8gZGUgMjAxNCA4OjQzPGI+PGJyPg0KVG86PC9iPiA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86
ZGltZUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1PmRp
bWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj48
YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0
byBiZSBiYXNlZCBvbiBwcmV2aW91cw0KaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y
IGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSGk8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y
PSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KUmVtb3ZlIOKAnGZyb20gbm93IG9u4oCdIGlz
IGFjY2VwdGFibGUgZm9yIG1lLCBidXQgJm5ic3A7SSBoYXZlIGEgcHJlZmVyZW5jZQ0KZm9yIHRo
ZSByZXZlcnNlIHdvcmRpbmcgTGlvbmVsIHByb3Bvc2VzLCB3aGljaCBpcyBzaG9ydGVyIGFuZCBi
cmluZ3MgdGhlDQpjbGFyaWZpY2F0aW9uIEkgd2FzIGxvb2tpbmcgZm9yLDo8L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
IkNvdXJpZXIgTmV3Ij48YnI+DQpGb3IgZXhhbXBsZSBpZiBhbiBPQy1SZWR1Y3Rpb24tUGVyY2Vu
dGFnZSB2YWx1ZSBvZiA8YnI+DQoxMCBoYXMgYmVlbiByZWNlaXZlZCwgdGhlIHJlYWN0aW5nIG5v
ZGUgd2hpY2ggPGJyPg0Kd291bGQgbm9ybWFsbHkgc2VuZCAxMDAgcGFja2V0cyBNVVNUIG9ubHkg
c2VuZCA5MCA8YnI+DQpwYWNrZXRzIHRvIHRoZSByZXBvcnRpbmcgbm9kZS48L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQogPGJyPg0KIDwvZm9udD48Zm9u
dCBzaXplPTIgY29sb3I9IzAwNDA4MCBmYWNlPSJDYWxpYnJpIj48YnI+DQpCZXN0IHJlZ2FyZHMg
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8L2ZvbnQ+
PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDQwODAgZmFjZT0iQ2FsaWJyaSI+PGJyPg0KSkphY3F1ZXMg
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8YnI+DQog
PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPjxicj4NCkRlIDo8L2I+IERpTUUg
WzwvZm9udD48YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXpl
PTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5v
cmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj5dDQo8Yj5EZSBsYSBw
YXJ0IGRlPC9iPiBTdGV2ZSBEb25vdmFuPGI+PGJyPg0KRW52b3nDqSA6PC9iPiBsdW5kaSAyNCBm
w6l2cmllciAyMDE0IDE3OjAwPGI+PGJyPg0Kw4AgOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRv
OmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5k
aW1lQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+
PGJyPg0KT2JqZXQgOjwvYj4gUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0
byBiZSBiYXNlZCBvbiBwcmV2aW91cw0KaGlzdG9yeSAtIGNvbmNsdXNpb248L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCiA8YnI+DQpJJ20gd2l0aCBMaW9u
ZWwuICZuYnNwO0kgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIHByb3Bvc2VkIHdvcmRpbmcgaXMg
Y29uZnVzaW5nLg0KJm5ic3A7UmVhY3Rpbmcgbm9kZXMgYWx3YXlzIG9ubHkgYXBwbHkgdGhlIHJl
ZHVjdGlvbiBwZXJjZW50YWdlIGZvciB0aGUNCnBlcmlvZCBvZiB0aW1lIHRoYXQgdGhlIHNwZWNp
ZmljIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUuICZuYnNwO1RoYXQNCnBlcmlvZCBlaXRoZXIg
ZW5kcyB3aGVuIGEgbmV3IG92ZXJsb2FkIHJlcG9ydCBpcyByZWNlaXZlZCBvciB3aGVuIHRoZSBv
dmVybG9hZA0KcmVwb3J0IGV4cGlyZXMuPGJyPg0KPGJyPg0KVGhhdCBzYWlkLCBJJ20gaGFwcHkg
d2l0aCBqdXN0IHJlbW92aW5nIHRoZSB3b3JkcyAmcXVvdDtmcm9tIG5vIG9uJnF1b3Q7DQphcyBw
cm9wb3NlZCBieSBMaW9uZWwgYmVsb3cuPGJyPg0KPGJyPg0KU3RldmU8YnI+DQo8YnI+DQpPbiAy
LzI0LzE0IDc6MjYgQU0sIDwvZm9udD48YSBocmVmPW1haWx0bzpsaW9uZWwubW9yYW5kQG9yYW5n
ZS5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48dT5s
aW9uZWwubW9yYW5kQG9yYW5nZS5jb208L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i
VGltZXMgTmV3IFJvbWFuIj4NCndyb3RlOiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48YnI+DQpJIGRvbid0IHNlZSB0aGUgaXNzdWUsIGFzIGV4cGxhaW5lZCBpbiBteSBt
YWlsIGJ1dCBPSyB0byByZW1vdmUgaXQuIDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg
TmV3IFJvbWFuIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+
PGJyPg0KSWYgJnF1b3Q7Zm9yIG5vdyZxdW90OyBpcyByZW1vdmVkLCB0aGUgcmVzdWx0aW5nIHRl
eHQgd291bGQgYmU6PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiBGb3Ig
ZXhhbXBsZSBpZiB0aGUgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBzZW5kaW5nPC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl
PSJDb3VyaWVyIE5ldyI+PGJyPg0KIDEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8gdGhlIHJlcG9y
dGluZyBub2RlLCB0aGVuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIGEgcmVjZXB0
aW9uIG9mIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDEwPC9mb250Pjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD
b3VyaWVyIE5ldyI+PGJyPg0KIHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rp
bmcgbm9kZSBNVVNUPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIG9ubHkgc2VuZCA5
MCBwYWNrZXRzIHBlciBzZWNvbmQuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPg0KPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi
cj4NCk1heWJlIGl0IHdvdWxkIGJlIGV2ZW4gZWFzaWVyIHRvIHJldmVyc2UgdGhlIHNlbnRlbmNl
IGFzIGZvbGxvdzo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8
YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KRm9yIGV4
YW1wbGUgaWYgYW4gT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgPGJyPg0KMTAgaGFz
IGJlZW4gcmVjZWl2ZWQsIHRoZSByZWFjdGluZyBub2RlIHdoaWNoIDxicj4NCndvdWxkIG5vcm1h
bGx5IHNlbmQgMTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgPGJyPg0KcGFja2V0cyB0byB0
aGUgcmVwb3J0aW5nIG5vZGUuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPGJyPg0KIDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3
Ij48YnI+DQpCdXQgSSdtIGZpbmUgaWYgdGhlIGluaXRpYWwgcHJvcG9zZWQgcmV2aXNlZCB0ZXh0
IGlzIGtlcHQuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJy
Pg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkxpb25lbDwv
Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KIDwvZm9udD48
Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkRlIDogRGlNRSBbPC9mb250Pjxh
IGhyZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1i
bHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC91
PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5dDQpEZSBsYSBwYXJ0
IGRlIE1hcmlhIENydXogQmFydG9sb21lPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO
ZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K
RW52b3nDqSA6IGx1bmRpIDI0IGbDqXZyaWVyIDIwMTQgMTQ6MTM8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp
ZXIgTmV3Ij48YnI+DQrDgCA6IDwvZm9udD48YSBocmVmPW1haWx0bzpkaW1lQGlldGYub3JnPjxm
b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5kaW1lQGlldGYub3Jn
PC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2Zv
bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpPYmpldCA6IFJlOiBbRGlt
ZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlz
dG9yeQ0KLSBjb25jbHVzaW9uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPiA8YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K
SGVsbG8sPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQog
PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSSBhZ3JlZSB3aXRo
IFVscmljaCdzIHByb3Bvc2FsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KQ2hlZXJz
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQg
c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQovTUNydXo8L2ZvbnQ+PGZvbnQgc2l6ZT0z
IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9
IkNvdXJpZXIgTmV3Ij48YnI+DQpGcm9tOiBEaU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll
ciBOZXciPjx1Pm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9u
dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPl0NCk9uIEJlaGFsZiBPZiBXaWVoZSwgVWxyaWNo
IChOU04gLSBERS9NdW5pY2gpPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KU2VudDog
bHVuZXMsIDI0IGRlIGZlYnJlcm8gZGUgMjAxNCAxMDo0NjwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO
ZXciPjxicj4NClRvOiBleHQgVFJPVFRJTiwgSkVBTi1KQUNRVUVTIChKRUFOLUpBQ1FVRVMpOyA8
L2ZvbnQ+PGEgaHJlZj1tYWlsdG86ZGltZUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29sb3I9Ymx1
ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+ZGltZUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl
PSJDb3VyaWVyIE5ldyI+PGJyPg0KU3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcg
bm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cw0KaGlzdG9yeSAtIGNvbmNsdXNpb248
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCiA8L2ZvbnQ+
PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpJIHNoYXJlIEpKYWNxdWVzIGNv
bmNlcm4uIFJlcGxhY2luZyAmcXVvdDtmcm9tIG5vdyBvbiZxdW90OyB3aXRoICZxdW90O2Zvcg0K
dGhlIHBlcmlvZCB0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlJnF1b3Q7PC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9
MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KaXMgbWlzbGVhZGluZy4gTWF5IGJlIGl0cyBiZXR0
ZXIgdG8gc2ltcGx5IHJlbW92ZSAmcXVvdDtmcm9tIG5vdyBvbiZxdW90Oy48L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQogPC9mb250Pjxmb250IHNpemU9
MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KVWxyaWNoPC9mb250Pjxmb250IHNpemU9MyBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQogPGJyPg0KIDxicj4NCiA8YnI+DQogPGJyPg0KIDwv
Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkZyb206IERpTUUgWzwv
Zm9udD48YSBocmVmPSJtYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnIj48Zm9udCBzaXplPTIg
Y29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bWFpbHRvOmRpbWUtYm91bmNlc0BpZXRm
Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+XQ0KT24g
QmVoYWxmIE9mIGV4dCBUUk9UVElOLCBKRUFOLUpBQ1FVRVMgKEpFQU4tSkFDUVVFUyk8L2ZvbnQ+
PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y
IGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDE0
IDc6MTEgUE08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2Zv
bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpUbzogPC9mb250PjxhIGhy
ZWY9bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291
cmllciBOZXciPjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO
ZXciPjxicj4NClN1YmplY3Q6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQg
dG8gYmUgYmFzZWQgb24gcHJldmlvdXMNCmhpc3RvcnkgLSBjb25jbHVzaW9uPC9mb250Pjxmb250
IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQogPC9mb250Pjxmb250IHNpemU9
MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSGkgTUNydXosIFN0ZXZlPC9mb250Pjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBm
YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSSBhbHNvIGFncmVlIG9uIHRoZSAmcXVvdDt3b3VsZCBz
ZW5kICZxdW90OyBpbnN0ZWFkIG9mIHRoZSAmcXVvdDt3b3VsZA0KaGF2ZSBzZW50JnF1b3Q7ICZu
YnNwO2ZvciBzdXJlLiAmbmJzcDtCdXQgSSBoYXZlICZuYnNwO2Egc21hbGwgY29uY2Vybi8NCmNs
YXJpZmljYXRpb24gJm5ic3A7YWJvdXQgdGhlIFN0ZXZlIGNvbW1lbnQgb24gJm5ic3A7ICZxdW90
O2ZvciB0aGUgcGVyaW9kDQp0aGF0IHRoZSBvdmVybG9hZCByZXBvcnQgaXMgYWN0aXZlJnF1b3Q7
IGFuZCB0aGUgZXhhbXBsZSB0byB3aGljaCBpdCByZWZlcnMuPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i
Q291cmllciBOZXciPjxicj4NCkR1cmluZyB0aGUgdGltZSB0aGUgT0xSIGlzIGFjdGl2ZSwgd2hp
Y2ggbWF5IGJlIHJhdGhlciBsb25nLCAmbmJzcDt0aGUNCnRyYWZmaWMgdGhlIHJlYWN0aW5nIG5v
ZGUgd291bGQgc2VuZCBtYXkgYmUgMTAwIHBhY2tldCAmbmJzcDt3aGVuIGl0IGhhcw0KanVzdCBy
ZWNlaXZlZCB0aGUgT0xSLiBBIGJpdCBsYXRlciwgdGhlIHRyYWZmaWMgaXQgd291bGQgc2VuZCBj
b3VsZCBiZQ0KMTIwIChvciA4MCksIGFuZCBmcm9tIHRoZSBPTFIgZGVmaW5pdGlvbiwgJm5ic3A7
IGl0IHdvdWxkIHNlbmQgMTIweDAsOQ0KKG9yIDgwKiAwLDkpIHBhY2tldHMsIG9uICZuYnNwO3do
aWNoIEkgYWdyZWUuIFRoaXMgaXMgaW4gbGluZSAmbmJzcDt3aXRoDQp0aGUgZXZlcnkgMTB0aCBw
YWNrZXQgZHJvcHBpbmcgJm5ic3A7b24gd2hpY2ggSSBhbHNvIGFncmVlLiA8YnI+DQogPGJyPg0K
QXMgdGhlIHRleHQgJm5ic3A7IHdvdWxkICZuYnNwO2JlIHdyaXR0ZW4gd2l0aCB0aGUgU3RldmUg
bW9kaWZpY2F0aW9uICwNCndlIG1heSB1bmRlcnN0YW5kIGl0IGlzICZuYnNwOzgwIFBhY2tldCBk
dXJpbmcgYWxsIHRoZSB0aW1lICZuYnNwO3RoZSBPTFINCmlzIGFjdGl2ZS4gTm90IHlldCB0aGlu
ayB0byBhbiBhbHRlcm5hdGl2ZSB0ZXh0LCBidXQgZmlyc3QgdG8gc2VlIGlmIHlvdQ0KYWdyZWUg
d2l0aCBteSByZW1hcmsuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
PiA8YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSkph
Y3F1ZXMgPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCiA8
YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KRGUgOiBE
aU1FIFs8L2ZvbnQ+PGEgaHJlZj0ibWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZyI+PGZvbnQg
c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1Pm1haWx0bzpkaW1lLWJvdW5j
ZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci
Pl0NCkRlIGxhIHBhcnQgZGUgPC9mb250PjxhIGhyZWY9bWFpbHRvOmxpb25lbC5tb3JhbmRAb3Jh
bmdlLmNvbT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+bGlv
bmVsLm1vcmFuZEBvcmFuZ2UuY29tPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp
bWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48
YnI+DQpFbnZvecOpIDogdmVuZHJlZGkgMjEgZsOpdnJpZXIgMjAxNCAxODozMzwvZm9udD48Zm9u
dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFj
ZT0iQ291cmllciBOZXciPjxicj4NCsOAIDogU3RldmUgRG9ub3ZhbjsgPC9mb250PjxhIGhyZWY9
bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmll
ciBOZXciPjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0i
VGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci
Pjxicj4NCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBi
ZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5DQotIGNvbmNsdXNpb248L2ZvbnQ+PGZvbnQgc2l6
ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh
Y2U9IkNvdXJpZXIgTmV3Ij48YnI+DQorMSAoaW5jbHVkaW5nIFN0ZXZlIGNvbW1lbnQpPC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KIDwvZm9udD48Zm9u
dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkRlIDogRGlNRSBbPC9mb250PjxhIGhy
ZWY9Im1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPjxmb250IHNpemU9MiBjb2xvcj1ibHVl
IGZhY2U9IkNvdXJpZXIgTmV3Ij48dT5tYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnPC91Pjwv
Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5dDQpEZSBsYSBwYXJ0IGRl
IFN0ZXZlIERvbm92YW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpFbnZvecOpIDog
dmVuZHJlZGkgMjEgZsOpdnJpZXIgMjAxNCAxNjozNzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i
VGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci
Pjxicj4NCsOAIDogPC9mb250PjxhIGhyZWY9bWFpbHRvOmRpbWVAaWV0Zi5vcmc+PGZvbnQgc2l6
ZT0yIGNvbG9yPWJsdWUgZmFjZT0iQ291cmllciBOZXciPjx1PmRpbWVAaWV0Zi5vcmc8L3U+PC9m
b250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9u
dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6
IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5DQot
IGNvbmNsdXNpb248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxi
cj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpNYXJpYSBD
cnV6LDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KIDwv
Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkkgc3VwcG9ydCB5b3Vy
IHN1Z2dlc3RlZCBjaGFuZ2VzLiAmbmJzcDtJIGhhdmUgb25lIGZ1cnRoZXIgc3VnZ2VzdGVkIGNo
YW5nZQ0KYmVsb3cuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8
YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KU3RldmU8
L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk9uIDIvMjEvMTQgMjo0MCBBTSwgTWFyaWEg
Q3J1eiBCYXJ0b2xvbWUgd3JvdGU6PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg
Um9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KIzUy
OiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeTwv
Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjxicj4NCiA8L2ZvbnQ+
PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpGb2xsb3dpbmcgYWdyZWVtZW50
IGlzIHJlYWNoZWQ6PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk5vdyAo
Y2hhcHRlciA0LjcpOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4g
PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyBUaGUg
T0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgQVZQIChBVlAgY29kZSBUQkQ4KSBpcyB0eXBlIG9mIFVu
c2lnbmVkMzI8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2Zv
bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogJm5ic3A7IGFuZCBkZXNj
cmliZXMgdGhlIHBlcmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzPC9m
b250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNp
emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyByZXF1ZXN0ZWQgdG8gcmVkdWNl
LCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3VsZCBoYXZlIHNlbnQuPC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KIDwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NClByb3Bvc2FsOjwvZm9udD48Zm9udCBzaXpl
PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy
aWVyIE5ldyI+PGJyPg0KICZuYnNwO1RoZSBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSBBVlAgKEFW
UCBjb2RlIFRCRDgpIGlzIHR5cGUgb2YgVW5zaWduZWQzMg0KJm5ic3A7PC9mb250Pjxmb250IHNp
emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv
dXJpZXIgTmV3Ij48YnI+DQogJm5ic3A7YW5kIGRlc2NyaWJlcyB0aGUgcGVyY2VudGFnZSBvZiB0
aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy
IE5ldyI+PGJyPg0KICZuYnNwO3JlcXVlc3RlZCB0byByZWR1Y2UsIGNvbXBhcmVkIHRvIHdoYXQg
aXQgb3RoZXJ3aXNlIHdvdWxkIHNlbmQuICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZsdDstLS0tPC9mb250Pjxmb250IHNpemU9
MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KIDxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6
ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpOb3cgKGNoYXB0ZXIgNS41LjIpOjwvZm9udD48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBm
YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyAmbmJzcDsgSW5kaWNhdGVzIHRoYXQgdGhl
IHJlcG9ydGluZyBub2RlIHVyZ2VzIHRoZSByZWFjdGluZyBub2RlDQp0bzwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD
b3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyAmbmJzcDsgcmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEg
Z2l2ZW4gcGVyY2VudGFnZS4gJm5ic3A7Rm9yIGV4YW1wbGUNCmlmIHRoZTwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD
b3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyAmbmJzcDsgcmVhY3Rpbmcgbm9kZSBoYXMgYmVlbiBz
ZW5kaW5nIDEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8NCnRoZTwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy
IE5ldyI+PGJyPg0KICZuYnNwOyAmbmJzcDsgcmVwb3J0aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRp
b24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UNCnZhbHVlPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg
TmV3Ij48YnI+DQogJm5ic3A7ICZuYnNwOyBvZiAxMCB3b3VsZCBtZWFuIHRoYXQgZnJvbSBub3cg
b24gdGhlIHJlYWN0aW5nIG5vZGUgTVVTVA0Kb25seSBzZW5kPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg
TmV3Ij48YnI+DQogJm5ic3A7ICZuYnNwOyA5MCBwYWNrZXRzIHBlciBzZWNvbmQuICZuYnNwO0hv
dyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hpZXZlcw0KdGhlICZxdW90O3RydWU8L2ZvbnQ+PGZvbnQg
c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i
Q291cmllciBOZXciPjxicj4NCiAmbmJzcDsgJm5ic3A7IHJlZHVjdGlvbiZxdW90OyB0cmFuc2Fj
dGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0DQptZXNzYWdlcyBpcyB1cDwvZm9udD48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBm
YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KICZuYnNwOyAmbmJzcDsgdG8gdGhlIGltcGxlbWVudGF0
aW9uLiAmbmJzcDtUaGUgcmVhY3Rpbmcgbm9kZSBNQVkgc2ltcGx5DQpkcm9wIGV2ZXJ5PC9mb250
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0y
IGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQogJm5ic3A7ICZuYnNwOyAxMHRoIHBhY2tldCBmcm9t
IGl0cyBvdXRwdXQgcXVldWUgYW5kIGxldCB0aGUgZ2VuZXJpYyBhcHBsaWNhdGlvbjwvZm9udD48
Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIg
ZmFjZT0iQ291cmllciBOZXciPjxicj4NCiAmbmJzcDsgJm5ic3A7IGxvZ2ljIHRyeSB0byByZWNv
dmVyIGZyb20gaXQuMCAmbHQ7IHZhbHVlICZsdDsgMTAwPC9mb250Pjxmb250IHNpemU9MyBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291
cmllciBOZXciPjxicj4NCiBQcm9wb3NhbDo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4N
CkluZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9k
ZSB0byByZWR1Y2UgPGJyPg0KaXRzIHRyYWZmaWMgYnkgYSBnaXZlbiBwZXJjZW50YWdlLiBGb3Ig
ZXhhbXBsZSBpZiB0aGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpyZWFjdGluZyBu
b2RlIHdvdWxkIHNlbmQgMTAwIHBhY2tldHMgdG8gdGhlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsmbHQ7LS0tPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KcmVwb3J0
aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFs
dWUgb2YgPGJyPg0KMTAgd291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9uIHRoZSByZWFjdGluZyBu
b2RlIE1VU1Qgb25seSBzZW5kPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KOTAgcGFj
a2V0cyBpbnN0ZWFkIG9mIDEwMC4gSG93IHRoZSByZWFjdGluZyBub2RlIGFjaGlldmVzIHRoZSAm
cXVvdDt0cnVlDQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbHQ7LS0tPC9mb250Pjxmb250IHNpemU9
MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3Vy
aWVyIE5ldyI+PGJyPg0KcmVkdWN0aW9uJnF1b3Q7IHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRo
ZSBzZW50IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXANCnRvIDxicj4NCnRoZSBpbXBsZW1lbnRhdGlv
bi4gVGhlIHJlYWN0aW5nIG5vZGUgTUFZIHNpbXBseSBkcm9wIGV2ZXJ5IDEwdGggPGJyPg0KcGFj
a2V0IGZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9u
IGxvZ2ljIHRyeQ0KPGJyPg0KdG8gcmVjb3ZlciBmcm9tIGl0LjwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy
IE5ldyI+PGJyPg0KU1JEJmd0OyBSZXBsYWNlICZxdW90O2Zyb20gbm93IG9uJnF1b3Q7IGluIHRo
ZSBhYm92ZSB3aXRoICZxdW90O2ZvciB0aGUNCnBlcmlvZCB0aGF0IHRoZSBvdmVybG9hZCByZXBv
cnQgaXMgYWN0aXZlJnF1b3Q7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPg0KPGJyPg0KIDxicj4NCiA8YnI+DQogPGJyPg0KIDxicj4NCiA8YnI+DQogPGJyPg0KIDwv
Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9mb250Pjxmb250IHNpemU9MyBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l
dyI+PGJyPg0KRGlNRSBtYWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz
IE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBO
ZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86RGlNRUBpZXRmLm9y
Zz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+RGlNRUBpZXRm
Lm9yZzwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+
PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vZGltZT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC91PjwvZm9udD48L2E+
PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQogPGJyPg0KIDwvZm9u
dD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2ZvbnQ+PGZv
bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQogPC9mb250Pjxmb250IHNp
emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv
aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcw0K
b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwvZm9udD48Zm9udCBzaXplPTMgZmFj
ZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO
ZXciPjxicj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0
b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoNCnJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVp
bGxleiBsZSBzaWduYWxlcjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu
Ij4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCmEgbCdleHBl
ZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBt
ZXNzYWdlcw0KZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDwv
Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3Bv
bnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lDQpvdSBmYWxzaWZp
ZS4gTWVyY2kuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8YnI+
DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KVGhpcyBtZXNz
YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp
bGVnZWQNCmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PC9mb250Pjxm
b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBm
YWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1
c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy
IE5ldyI+PGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxl
YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0
dGFjaG1lbnRzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwv
Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCkFzIGVtYWlscyBtYXkg
YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi
ZWVuDQptb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9mb250Pjxmb250IHNpemU9MyBm
YWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy
IE5ldyI+PGJyPg0KVGhhbmsgeW91LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3
IFJvbWFuIj4gPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi
cj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8
YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KQ2UgbWVz
c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp
b25zIGNvbmZpZGVudGllbGxlcw0Kb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwv
Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBz
aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0
ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXoNCnJlY3UgY2UgbWVz
c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvZm9udD48Zm9udCBzaXplPTMg
ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll
ciBOZXciPjxicj4NCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg
cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0
aWJsZXMgZCdhbHRlcmF0aW9uLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv
bWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCk9yYW5n
ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl
LCBkZWZvcm1lDQpvdSBmYWxzaWZpZS4gTWVyY2kuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU
aW1lcyBOZXcgUm9tYW4iPiA8YnI+DQogPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy
IE5ldyI+PGJyPg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g
Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQNCmluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl
Y3RlZCBieSBsYXc7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0K
PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KdGhleSBzaG91bGQg
bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250
IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp
cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KZGVsZXRlIHRo
aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i
VGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci
Pjxicj4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y
IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuDQptb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu
PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250
IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KVGhhbmsgeW91LjwvZm9udD48Zm9udCBz
aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KIDwvZm9udD48Zm9udCBzaXplPTIg
ZmFjZT0iQ291cmllciBOZXciPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
Pg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KRGlNRSBtYWls
aW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9u
dD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4N
CjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86RGlNRUBpZXRmLm9yZz48Zm9udCBzaXplPTIgY29s
b3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+RGlNRUBpZXRmLm9yZzwvdT48L2ZvbnQ+PC9h
Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9
MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHU+PGJyPg0KPC91PjwvZm9udD48
YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZT48Zm9udCBz
aXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9
IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQogPGJyPg0KIDxicj4NCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+
DQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBp
bmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzDQpvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu
dCBkb25jPGJyPg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh
dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleg0KcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZl
dWlsbGV6IGxlIHNpZ25hbGVyPGJyPg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu
c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzDQplbGVjdHJvbmlxdWVzIGV0
YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPGJyPg0KT3JhbmdlIGRlY2xpbmUgdG91dGUg
cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUNCm91IGZh
bHNpZmllLiBNZXJjaS48YnI+DQo8YnI+DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50
cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KaW5mb3JtYXRpb24gdGhh
dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp
YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQpJZiB5b3Ug
aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k
ZXIgYW5kDQpkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPGJyPg0KQXMg
ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg
dGhhdCBoYXZlIGJlZW4NCm1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48YnI+DQpUaGFu
ayB5b3UuPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1FIG1haWxp
bmcgbGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9t
YW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86RGlNRUBpZXRmLm9yZz48Zm9u
dCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+RGlNRUBpZXRmLm9yZzwv
dT48L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21h
biI+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vZGltZT48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5l
dyI+PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC91PjwvZm9u
dD48L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPGJyPg0KPGJy
Pg0KPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1FIG1haWxpbmcg
bGlzdDwvZm9udD48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4i
Pjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86RGlNRUBpZXRmLm9yZz48Zm9udCBz
aXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+PHU+RGlNRUBpZXRmLm9yZzwvdT48
L2ZvbnQ+PC9hPjxmb250IHNpemU9MyBjb2xvcj1ibHVlIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+
PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vZGltZT48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJDb3VyaWVyIE5ldyI+
PHU+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lPC91PjwvZm9udD48
L2E+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGJyPg0KPC9mb250Pjxmb250
IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpEaU1FIG1haWxpbmcgbGlzdDxicj4NCkRpTUVA
aWV0Zi5vcmc8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3IFJv
bWFuIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9kaW1lPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkNvdXJpZXIg
TmV3Ij48dT5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L3U+PC9m
b250PjwvYT4NCjxicj4NCg==
--=_alternative 006185D785257C91_=--


From nobody Tue Mar  4 09:56: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 110FD1A0255 for ; Tue,  4 Mar 2014 09:56:19 -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 oE6ovxER-jQB for ; Tue,  4 Mar 2014 09:56:12 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 682521A024A for ; Tue,  4 Mar 2014 09:56:11 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 58C0E22C6AA; Tue,  4 Mar 2014 18:56:07 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 0901727C06F; Tue,  4 Mar 2014 18:56:07 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 4 Mar 2014 18:56:06 +0100
From: 
To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , 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/EteSAD4lZZwkPErMq2A4lZTnEDErLODgIlZVFNQkrKjP4ClZTCjoMrKTt0AlZRpcHA=
Date: Tue, 4 Mar 2014 17:56:05 +0000
Message-ID: <2734_1393955767_531613B7_2734_2790_1_6B7134B31289DC4FAF731D844122B36E4DFC1D@PEXCVZYM13.corporate.adroot.infra.ftgroup>
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> <5315F4B0.9010902@usdonovans.com>
In-Reply-To: <5315F4B0.9010902@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.3]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4DFC1DPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.4.111816
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/PJ6acF_UlcJgymHywQongODRDEg
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 17:56:19 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4DFC1DPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

If (i said "if") I can correctly remember my own statement, I'm ok with OC-=
Supported-Features AVP in every answer.

However, it is not so clear what would its value, depending on the presence=
 of the OLR in the answer... Always all the supported algos or the selected=
 algo(s) when one OLR is present?

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mardi 4 mars 2014 16:44
=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc : dime@ietf.org list
Objet : Re: [Dime] Issue#30 status

Ulrich,

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

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

1) To be consistent with the pattern already established for feature capabi=
lities 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 DOI=
C capable nodes.

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

The case where some servers support DOIC and some servers do not support DO=
IC.  In this scenario, agents will be expected to take on the roll of the r=
eporting node for non supporting servers.  For the servers that support DOI=
C 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 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








___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4DFC1DPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











If (i said=
 "if") I can correctly remember my own statement, I'm ok with OC-=
Supported-Features AVP in every answer.


 =
;


However, i=
t is not so clear what would its value, depending on the presence of the OL=
R in the answer… Always all the supported algos or the selected
 algo(s) when one OLR is present?


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mardi 4 mars 2014 16:44

=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell

Cc : dime@ietf.org list

Objet : Re: [Dime] Issue#30 status






 


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 capabi=
lities 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 DOI=
C capable nodes.



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



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



Steve




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






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




 


 




 




 




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4DFC1DPEXCVZYM13corpora_--


From nobody Tue Mar  4 10:02:27 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 B18991A02AE; Tue,  4 Mar 2014 10:02:18 -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 5X1Ip_l9VePN; Tue,  4 Mar 2014 10:02: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 D61F51A026B; Tue,  4 Mar 2014 10:02:08 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0EECA18C42C; Tue,  4 Mar 2014 19:02:05 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E3F751E407E; Tue,  4 Mar 2014 19:02:04 +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 19:02:04 +0100
From: 
To: Janet P Gunn , Maria Cruz Bartolome 
Thread-Topic: [Dime] #52: Throttling not needed to be based on previous history - conclusion
Thread-Index: AQHPN9GHP5QHW/x8CUOHnvtRuBuUzprRJ0gw
Date: Tue, 4 Mar 2014 18:02:03 +0000
Message-ID: <3720_1393956125_5316151C_3720_2856_1_6B7134B31289DC4FAF731D844122B36E4DFC45@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B9209784017@ESESSMB101.ericsson.se> <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>  <087A34937E64E74E848732CFF8354B920978871D@ESESSMB101.ericsson.se> 
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.4.101818
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vOcyEcc1zzcEDuwUYGakyQIk_C8
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: Tue, 04 Mar 2014 18:02:19 -0000

SSdtIG9rIHdpdGggYm90aC4gUGljayBvbmUhIDopDQoNCkxpb25lbA0KDQpEZcKgOiBKYW5ldCBQ
IEd1bm4gW21haWx0bzpqZ3VubjZAY3NjLmNvbV0gDQpFbnZvecOpwqA6IG1hcmRpIDQgbWFycyAy
MDE0IDE4OjQ1DQrDgMKgOiBNYXJpYSBDcnV6IEJhcnRvbG9tZQ0KQ2PCoDogZGltZUBpZXRmLm9y
ZzsgRGlNRTsgU3RldmUgRG9ub3Zhbg0KT2JqZXTCoDogUkU6IFtEaW1lXSAjNTI6IFRocm90dGxp
bmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lv
bg0KDQpJIHRoaW5rIHRoZSBpbnRlbnQsIGluIGNoYW5naW5nIGZyb20gImhhcyBiZWVuIHNlbmRp
bmcgwqAxMDAgcmVxdWVzdHMgcGVyIHNlY29uZCIgdG8gIndvdWxkIG5vcm1hbGx5IHNlbmQgMTAw
IHJlcXVlc3RzIiB3YXMgdG8gZ2V0IHJpZCBvZiB0aGUgcmVmZXJlbmNlIHRvIGEgwqAiaGlzdG9y
aWNhbCDCoHRyYW5zbWlzc2lvbiByYXRlIi4gDQoNClRoZSBwaHJhc2UsICJ3b3VsZCBub3JtYWxs
eSBzZW5kIiBzdGlsbCBoYXMgdGhlIGNvbm5vdGF0aW9uIChmb3IgbWUgYW55d2F5KSBvZiBhICJo
aXN0b3JpY2FsIMKgdHJhbnNtaXNzaW9uIHJhdGUiLiANCg0KUG9zc2libGUgc3VnZ2VzdGlvbnMg
YXJlIA0KIndvdWxkLCB3aXRob3V0IG92ZXJsb2FkIGNvbnRyb2wsIHNlbmQgMTAwIHJlcXVlc3Rz
IiANCm9yIA0KIndvdWxkIG90aGVyd2lzZSBzZW5kIDEwMCByZXF1ZXN0cyIgKHdoaWNoIGlzIGNv
bnNpc3RlbnQgd2l0aCB0aGUgd29yZGluZyBpbiA0LjcpLiANCg0KSnVzdCB0cnlpbmcgdG8gbWFr
ZSBpdCBjbGVhcmVyIHRvIGZ1dHVyZSByZWFkZXJzLiANCg0KVGhhbmtzIA0KDQpKYW5ldA0KDQpU
aGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVj
aXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1
cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mg
b2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8g
YW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3
cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1p
dHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4gDQoNCg0KDQpGcm9tOiDC
oCDCoCDCoCDCoE1hcmlhIENydXogQmFydG9sb21lIDxtYXJpYS5jcnV6LmJhcnRvbG9tZUBlcmlj
c3Nvbi5jb20+IA0KVG86IMKgIMKgIMKgIMKgSmFuZXQgUCBHdW5uL1VTQS9DU0NAQ1NDLCBTdGV2
ZSBEb25vdmFuIDxzcmRvbm92YW5AdXNkb25vdmFucy5jb20+IA0KQ2M6IMKgIMKgIMKgIMKgRGlN
RSA8ZGltZS1ib3VuY2VzQGlldGYub3JnPiwgImRpbWVAaWV0Zi5vcmciIDxkaW1lQGlldGYub3Jn
PiANCkRhdGU6IMKgIMKgIMKgIMKgMDMvMDMvMjAxNCAwNjowMyBQTSANClN1YmplY3Q6IMKgIMKg
IMKgIMKgUkU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBv
biBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbiANCl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCg0KDQoNCkhlbGxvIEphbmV0LCBhbGwsIA0KwqAgDQpUaGUgcHJl
LWFncmVlZCBwcm9wb3NhbCBpcyB0aGUgZm9sbG93aW5nOiANCsKgIA0KTm93IChjaGFwdGVyIDQu
Nyk6IA0KwqAgVGhlIE9DLVJlZHVjdGlvbi1QZXJjZW50YWdlIEFWUCAoQVZQIGNvZGUgVEJEOCkg
aXMgdHlwZSBvZiBVbnNpZ25lZDMyIA0KwqAgYW5kIGRlc2NyaWJlcyB0aGUgcGVyY2VudGFnZSBv
ZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMgDQrCoCByZXF1ZXN0ZWQgdG8gcmVkdWNl
LCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3VsZCBoYXZlIHNlbnQuIA0KDQpQcm9w
b3NhbDogDQrCoFRoZSBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSBBVlAgKEFWUCBjb2RlIFRCRDgp
IGlzIHR5cGUgb2YgVW5zaWduZWQzMiDCoCANCsKgYW5kIGRlc2NyaWJlcyB0aGUgcGVyY2VudGFn
ZSBvZiB0aGUgdHJhZmZpYyB0aGF0IHRoZSBzZW5kZXIgaXMgwqAgDQrCoHJlcXVlc3RlZCB0byBy
ZWR1Y2UsIGNvbXBhcmVkIHRvIHdoYXQgaXQgb3RoZXJ3aXNlIHdvdWxkIHNlbmQuIMKgIMKgIMKg
IMKgIMKgIMKgIMKgIMKgIA0KDQrCoCANCk5vdyAoY2hhcHRlciA1LjUuMik6IA0KwqAgwqAgSW5k
aWNhdGVzIHRoYXQgdGhlIHJlcG9ydGluZyBub2RlIHVyZ2VzIHRoZSByZWFjdGluZyBub2RlIHRv
IA0KwqAgwqAgcmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2VudGFnZS4gwqBGb3Ig
ZXhhbXBsZSBpZiB0aGUgDQrCoCDCoCByZWFjdGluZyBub2RlIGhhcyBiZWVuIHNlbmRpbmcgMTAw
IHBhY2tldHMgcGVyIHNlY29uZCB0byB0aGUgDQrCoCDCoCByZXBvcnRpbmcgbm9kZSwgdGhlbiBh
IHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSANCsKgIMKgIG9mIDEw
IHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIG9ubHkg
c2VuZCANCsKgIMKgIDkwIHBhY2tldHMgcGVyIHNlY29uZC4gwqBIb3cgdGhlIHJlYWN0aW5nIG5v
ZGUgYWNoaWV2ZXMgdGhlICJ0cnVlIA0KwqAgwqAgcmVkdWN0aW9uIiB0cmFuc2FjdGlvbnMgbGVh
ZGluZyB0byB0aGUgc2VudCByZXF1ZXN0IG1lc3NhZ2VzIGlzIHVwIA0KwqAgwqAgdG8gdGhlIGlt
cGxlbWVudGF0aW9uLiDCoFRoZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeSAN
CsKgIMKgIDEwdGggcGFja2V0IGZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5l
cmljIGFwcGxpY2F0aW9uIA0KwqAgwqAgbG9naWMgdHJ5IHRvIHJlY292ZXIgZnJvbSBpdC4gDQrC
oCANClByb3Bvc2FsOiANCsKgIMKgIEluZGljYXRlcyB0aGF0IHRoZSByZXBvcnRpbmcgbm9kZSB1
cmdlcyB0aGUgcmVhY3Rpbmcgbm9kZSB0byANCsKgIMKgIHJlZHVjZSBpdHMgdHJhZmZpYyBieSBh
IGdpdmVuIHBlcmNlbnRhZ2UuIEZvciBleGFtcGxlIGlmIGFuIA0KwqAgwqAgT0MtUmVkdWN0aW9u
LVBlcmNlbnRhZ2UgdmFsdWUgb2YgwqAxMCBoYXMgYmVlbiByZWNlaXZlZCwgDQrCoCDCoCB0aGUg
cmVhY3Rpbmcgbm9kZSB3aGljaCDCoHdvdWxkIG5vcm1hbGx5IHNlbmQgMTAwIHJlcXVlc3RzIA0K
wqAgwqAgTVVTVCBvbmx5IHNlbmQgOTAgcmVxdWVzdHMgdG8gdGhlIHJlcG9ydGluZyBub2RlLiAN
CsKgIMKgIEhvdyB0aGUgcmVhY3Rpbmcgbm9kZSBhY2hpZXZlcyB0aGUgInRydWUgDQrCoCDCoCBy
ZWR1Y3Rpb24iIHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRoZSBzZW50IHJlcXVlc3QgbWVzc2Fn
ZXMgaXMgdXAgDQrCoCDCoCB0byB0aGUgaW1wbGVtZW50YXRpb24uIFRoZSByZWFjdGluZyBub2Rl
IE1BWSBzaW1wbHkgZHJvcCBldmVyeSAxMHRoIA0KwqAgwqByZXF1ZXN0IGZyb20gaXRzIG91dHB1
dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9uIGxvZ2ljIA0KwqAgwqB0cnkg
dG8gcmVjb3ZlciBmcm9tIGl0LiANCsKgIA0KwqAgDQpMZXQgbWUga25vdyBpZiB0aGlzIHRleHQg
Y292ZXJzIHlvdXIgY29uY2VybnMuIA0KSSB0b29rIHByb2ZpdCB0byByZXBsYWNlIHBhY2tldCBi
eSByZXF1ZXN0LiANCsKgIA0KQmVzdCByZWdhcmRzIA0KL01DcnV6IA0KwqAgDQpGcm9tOiBEaU1F
IFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFuZXQgUCBHdW5u
DQpTZW50OiBsdW5lcywgMDMgZGUgbWFyem8gZGUgMjAxNCAyMTowOA0KVG86IFN0ZXZlIERvbm92
YW4NCkNjOiBEaU1FOyBkaW1lQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0RpbWVdICM1MjogVGhy
b3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25j
bHVzaW9uIA0KwqAgDQpPSywgSSBhZG1pdCB0byBiZWluZyBjb25mdXNlZC4gDQoNCkluZGVwZW5k
ZW50IG9mIHRoZSBwYWNrZXRzIHZzIHJlcXVlc3RzIGRpc3RpbmN0aW9uLSANCg0KQXNzdW1pbmcg
YSBub2RlIHJlY2VpdmVzIGEgbWVzc2FnZSByZXF1aXJpbmcgMTAlIHJlZHVjdGlvbiwgZG9lcyB0
aGlzIG1lYW4gDQoNCkEgLSBUaGUgbm9kZSB3aWxsIGRyb3Agb25lIG91dCBvZiBldmVyeSAxMCBy
ZXF1ZXN0cyBpdCAid2FudHMiIHRvIHNlbmQgLCB3aGV0aGVyIGl0ICJ3YW50cyIgdG8gc2VuZCAx
MCByZXF1ZXN0cyBvciAxMDAwIHJlcXVlc3RzIHBlciB1bml0IHRpbWUuIA0KDQpvciANCg0KQi0g
SWYgaXQgIm5vcm1hbGx5IiBzZW5kcyAxMDAgbWVzc2FnZXMgcGVyIHVuaXQgdGltZSwgaXQgd2ls
bCByZXN0cmljdCBpdHNlbGYgdG8gOTAgbWVzc2FnZXMgcGVyIHVuaXQgdGltZSwgcmVnYXJkbGVz
cyBvZiB3aGV0aGVyIGl0ICJ3YW50cyIgdG8gc2VuZCAxMCBvciAxMDAwIA0KPyANCg0KIkEiIG1h
a2VzIG1vcmUgc2Vuc2UgdG8gbWUsIGJ1dCB0aGUgcHJvcG9zZWQgdGV4dCAocmVwZWF0ZWQgYmVs
b3cpIHNlZW1zIHRvIGltcGx5ICJCIiAoOTAgcGFja2V0cyBwZXIgc2Vjb25kIGJhc2VkIG9uIHdo
YXQgaXQgImhhcyBiZWVuIHNlbmRpbmciIG9yICJ3b3VsZCBub3JtYWxseSBzZW5kIiBpbmRlcGVu
ZGVudCBvZiB0aGUgbnVtYmVyIHRoZSBub2RlICJ3YW50cyIgdG8gc2VuZCIpLiANCg0KSWYgIkEi
IGlzIGludGVuZGVkLCBJIHN1Z2dlc3QgcmV3b3JkaW5nIHRoZSB0ZXh0IHRvIG1ha2UgaXQgY2xl
YXJlciANCg0KPHF1b3RlZCBmcm9tIGJlbG93Pg0KRm9yIGV4YW1wbGUgaWYgdGhlIHJlYWN0aW5n
IG5vZGUgaGFzIGJlZW4gc2VuZGluZyANCjEwMCBwYWNrZXRzIHBlciBzZWNvbmQgdG8gdGhlIHJl
cG9ydGluZyBub2RlLCB0aGVuIA0KYSByZWNlcHRpb24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRh
Z2UgdmFsdWUgb2YgMTAgDQp3b3VsZCBtZWFuIHRoYXQgZnJvbSBub3cgb24gdGhlIHJlYWN0aW5n
IG5vZGUgTVVTVCANCm9ubHkgc2VuZCA5MCBwYWNrZXRzIHBlciBzZWNvbmQuIA0KDQpNYXliZSBp
dCB3b3VsZCBiZSBldmVuIGVhc2llciB0byByZXZlcnNlIHRoZSBzZW50ZW5jZSBhcyBmb2xsb3c6
IA0KDQpGb3IgZXhhbXBsZSBpZiBhbiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSBvZiAN
CjEwIGhhcyBiZWVuIHJlY2VpdmVkLCB0aGUgcmVhY3Rpbmcgbm9kZSB3aGljaCANCndvdWxkIG5v
cm1hbGx5IHNlbmQgMTAwIHBhY2tldHMgTVVTVCBvbmx5IHNlbmQgOTAgDQpwYWNrZXRzIHRvIHRo
ZSByZXBvcnRpbmcgbm9kZS4gDQo8L3F1b3RlZCBmcm9tIGJlbG93PiANCg0KDQpJdCBpcyBwb3Nz
aWJsZSB0aGF0IHlvdXIgIndvdWxkIG5vcm1hbGx5IHNlbmQiIGlzIHRoZSBzYW1lIGFzIG15ICJ3
YW50cyB0byBzZW5kIiwgYnV0IHRoYXQgaXNuJ3QgdGhlIHdheSBpdCByZWFkcywgYXQgbGVhc3Qg
dG8gbWUuIA0KDQpUaGFua3MsIA0KDQpKYW5ldA0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdl
LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdp
dGhvdXQgY29weWluZyBhbmQga2luZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rh
a2UgaW4gZGVsaXZlcnkuIE5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwg
c2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRy
YWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zl
cm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwg
Zm9yIHN1Y2ggcHVycG9zZS4gDQoNCg0KDQpGcm9tOiDCoCDCoCDCoCDCoFN0ZXZlIERvbm92YW4g
PHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbT4gDQpUbzogwqAgwqAgwqAgwqBkaW1lQGlldGYub3Jn
IA0KRGF0ZTogwqAgwqAgwqAgwqAwMy8wMy8yMDE0IDAxOjUyIFBNIA0KU3ViamVjdDogwqAgwqAg
wqAgwqBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9u
IHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uIA0KU2VudCBieTogwqAgwqAgwqAgwqAiRGlN
RSIgPGRpbWUtYm91bmNlc0BpZXRmLm9yZz4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCg0KDQoNCg0KSmFuZXQsDQoNCkknbSBub3Qgc3VyZSB3aHkgd2UgdXNl
IHRoZSB3b3JkIHBhY2tldHMuIMKgSXQgc2hvdWxkIGJlIHJlcXVlc3RzIGluc3RlYWQuIMKgVGhy
b3R0bGluZyBkb2VzIG5vdCBpbXBhY3QgcGFja2V0cyBjYXJyeWluZyBhbnN3ZXIgbWVzc2FnZXMs
IGZvciBpbnN0YW5jZS4NCg0KV2hhdCBpcyBtZWFudCBpcyB0aGF0IGlmIG5vcm1hbCBoYW5kbGlu
ZyB3b3VsZCBoYXZlIHJlc3VsdGVkIGluIDEwMCByZXF1ZXN0IG1lc3NhZ2VzIGJlaW5nIHNlbnQg
dGhlbiBhbiBvdmVybG9hZCByZXBvcnQgcmVxdWVzdGluZyBhIHJlZHVjdGlvbiBvZiAxMCUgd291
bGQgcmVzdWx0IGluIDkwIHJlcXVlc3QgbWVzc2FnZXMgYmVpbmcgc2VudCBhbmQgMTAgcmVxdWVz
dCBtZXNzYWdlcyBiZWluZyB0aHJvdHRsZWQuIMKgVGhlIGxvc3MgYWxnb3JpdGhtIGlzIGludGVu
dGlvbmFsbHkgc2ltcGxlIGFuZCBzdGF0ZWxlc3MuIMKgVGhlIHByb3Bvc2VkIGltcGxlbWVudGF0
aW9uIGJlaW5nIHRvIGRyb3AgMSBpbiBYIG1lc3NhZ2VzIHdoZXJlIFggaXMgY2FsY3VsYXRlZCBi
YXNlZCBvbiB0aGUgcmVxdWVzdGVkIHBlcmNlbnRhZ2UgcmVkdWN0aW9uIHJlY2VpdmVkIGluIHRo
ZSBvdmVybG9hZCByZXBvcnQuIMKgVGhpcyBpcyBtZWFudCB0byBiZSBpbmRlcGVuZGVudCBvZiBh
bnkgaHlzdGVyZXNpcyBhbmQgaW5kZXBlbmRlbnQgb2YgdGhlIGFycml2YWwgcmF0ZSBvZiBzZXJ2
aWNlIHJlcXVlc3RzLiANCg0KU3RldmUNCg0KT24gMy8zLzE0IDY6MDggUE0sIEphbmV0IFAgR3Vu
biB3cm90ZTogDQpJdCBzZWVtcyB0byBtZSB0aGlzIGJlZ3MgdGhlIHF1ZXN0aW9uOiANCldoYXQg
ZG9lcyAibm9ybWFsbHkgc2VuZHMgMTAwIHBhY2tldHMiIGFjdHVhbGx5IE1FQU4/IMKgSG93IGlz
IHRoZSBudW1iZXIgb2YgcGFja2V0cyBpdCAibm9ybWFsbHkgc2VuZHMiIGNhbGN1bGF0ZWQ/IA0K
DQpKYW5ldA0KDQpUaGlzIGlzIGEgUFJJVkFURSBtZXNzYWdlLiBJZiB5b3UgYXJlIG5vdCB0aGUg
aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHdpdGhvdXQgY29weWluZyBhbmQga2lu
ZGx5IGFkdmlzZSB1cyBieSBlLW1haWwgb2YgdGhlIG1pc3Rha2UgaW4gZGVsaXZlcnkuIE5PVEU6
IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwgdGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8g
YmluZCBDU0MgdG8gYW55IG9yZGVyIG9yIG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0
byBleHBsaWNpdCB3cml0dGVuIGFncmVlbWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhw
cmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVzZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4gDQoN
Cg0KDQpGcm9tOiDCoCDCoCDCoCDCoDxsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20+IA0KVG86IMKg
IMKgIMKgIMKgSm91bmkgS29yaG9uZW4gPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+LCAiZGltZUBp
ZXRmLm9yZyIgPGRpbWVAaWV0Zi5vcmc+IA0KRGF0ZTogwqAgwqAgwqAgwqAwMi8yOC8yMDE0IDA4
OjU5IEFNIA0KU3ViamVjdDogwqAgwqAgwqAgwqBSZTogW0RpbWVdICM1MjogVGhyb3R0bGluZyBu
b3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3VzIGhpc3RvcnkgLSBjb25jbHVzaW9uIA0K
U2VudCBieTogwqAgwqAgwqAgwqAiRGlNRSIgPGRpbWUtYm91bmNlc0BpZXRmLm9yZz4gDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCg0KSm91bmksIEkn
bSBhc3N1bWluZyB0aGF0IHlvdSBhcmUgT0sgd2l0aCB0aGUgY29uY2x1c2lvbiBnaXZlbiBoZXJl
IHRvbywgcmlnaHQ/IOKYuiANCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYu
b3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlhIENydXogQmFydG9sb21lDQpFbnZvecOpIDogbWVyY3Jl
ZGkgMjYgZsOpdnJpZXIgMjAxNCAxMzo1Ng0Kw4AgOiBkaW1lQGlldGYub3JnDQpPYmpldCA6IFJl
OiBbRGltZV0gIzUyOiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlv
dXMgaGlzdG9yeSAtIGNvbmNsdXNpb24gDQoNCkZpbmUgDQoNCkZyb206IERpTUUgW21haWx0bzpk
aW1lLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUUk9UVElOLCBKRUFOLUpBQ1FVRVMg
KEpFQU4tSkFDUVVFUykNClNlbnQ6IG1pw6lyY29sZXMsIDI2IGRlIGZlYnJlcm8gZGUgMjAxNCA4
OjQzDQpUbzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxp
bmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lv
biANCg0KSGkgDQoNClJlbW92ZSDigJxmcm9tIG5vdyBvbuKAnSBpcyBhY2NlcHRhYmxlIGZvciBt
ZSwgYnV0IMKgSSBoYXZlIGEgcHJlZmVyZW5jZSBmb3IgdGhlIHJldmVyc2Ugd29yZGluZyBMaW9u
ZWwgcHJvcG9zZXMsIHdoaWNoIGlzIHNob3J0ZXIgYW5kIGJyaW5ncyB0aGUgY2xhcmlmaWNhdGlv
biBJIHdhcyBsb29raW5nIGZvciw6IA0KRm9yIGV4YW1wbGUgaWYgYW4gT0MtUmVkdWN0aW9uLVBl
cmNlbnRhZ2UgdmFsdWUgb2YgDQoxMCBoYXMgYmVlbiByZWNlaXZlZCwgdGhlIHJlYWN0aW5nIG5v
ZGUgd2hpY2ggDQp3b3VsZCBub3JtYWxseSBzZW5kIDEwMCBwYWNrZXRzIE1VU1Qgb25seSBzZW5k
IDkwIA0KcGFja2V0cyB0byB0aGUgcmVwb3J0aW5nIG5vZGUuIA0KDQoNCkJlc3QgcmVnYXJkcyAN
Cg0KSkphY3F1ZXMgDQoNCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4NCkVudm95w6kgOiBsdW5kaSAyNCBmw6l2cmll
ciAyMDE0IDE3OjAwDQrDgCA6IGRpbWVAaWV0Zi5vcmcNCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6
IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0g
Y29uY2x1c2lvbiANCg0KSSdtIHdpdGggTGlvbmVsLiDCoEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkg
dGhlIHByb3Bvc2VkIHdvcmRpbmcgaXMgY29uZnVzaW5nLiDCoFJlYWN0aW5nIG5vZGVzIGFsd2F5
cyBvbmx5IGFwcGx5IHRoZSByZWR1Y3Rpb24gcGVyY2VudGFnZSBmb3IgdGhlIHBlcmlvZCBvZiB0
aW1lIHRoYXQgdGhlIHNwZWNpZmljIG92ZXJsb2FkIHJlcG9ydCBpcyBhY3RpdmUuIMKgVGhhdCBw
ZXJpb2QgZWl0aGVyIGVuZHMgd2hlbiBhIG5ldyBvdmVybG9hZCByZXBvcnQgaXMgcmVjZWl2ZWQg
b3Igd2hlbiB0aGUgb3ZlcmxvYWQgcmVwb3J0IGV4cGlyZXMuDQoNClRoYXQgc2FpZCwgSSdtIGhh
cHB5IHdpdGgganVzdCByZW1vdmluZyB0aGUgd29yZHMgImZyb20gbm8gb24iIGFzIHByb3Bvc2Vk
IGJ5IExpb25lbCBiZWxvdy4NCg0KU3RldmUNCg0KT24gMi8yNC8xNCA3OjI2IEFNLCBsaW9uZWwu
bW9yYW5kQG9yYW5nZS5jb20gd3JvdGU6IA0KSSBkb24ndCBzZWUgdGhlIGlzc3VlLCBhcyBleHBs
YWluZWQgaW4gbXkgbWFpbCBidXQgT0sgdG8gcmVtb3ZlIGl0LiANCg0KSWYgImZvciBub3ciIGlz
IHJlbW92ZWQsIHRoZSByZXN1bHRpbmcgdGV4dCB3b3VsZCBiZTogDQoNCkZvciBleGFtcGxlIGlm
IHRoZSByZWFjdGluZyBub2RlIGhhcyBiZWVuIHNlbmRpbmcgDQoxMDAgcGFja2V0cyBwZXIgc2Vj
b25kIHRvIHRoZSByZXBvcnRpbmcgbm9kZSwgdGhlbiANCmEgcmVjZXB0aW9uIG9mIE9DLVJlZHVj
dGlvbi1QZXJjZW50YWdlIHZhbHVlIG9mIDEwIA0Kd291bGQgbWVhbiB0aGF0IGZyb20gbm93IG9u
IHRoZSByZWFjdGluZyBub2RlIE1VU1QgDQpvbmx5IHNlbmQgOTAgcGFja2V0cyBwZXIgc2Vjb25k
LiANCg0KTWF5YmUgaXQgd291bGQgYmUgZXZlbiBlYXNpZXIgdG8gcmV2ZXJzZSB0aGUgc2VudGVu
Y2UgYXMgZm9sbG93OiANCg0KRm9yIGV4YW1wbGUgaWYgYW4gT0MtUmVkdWN0aW9uLVBlcmNlbnRh
Z2UgdmFsdWUgb2YgDQoxMCBoYXMgYmVlbiByZWNlaXZlZCwgdGhlIHJlYWN0aW5nIG5vZGUgd2hp
Y2ggDQp3b3VsZCBub3JtYWxseSBzZW5kIDEwMCBwYWNrZXRzIE1VU1Qgb25seSBzZW5kIDkwIA0K
cGFja2V0cyB0byB0aGUgcmVwb3J0aW5nIG5vZGUuIA0KDQoNCkJ1dCBJJ20gZmluZSBpZiB0aGUg
aW5pdGlhbCBwcm9wb3NlZCByZXZpc2VkIHRleHQgaXMga2VwdC4gDQoNCkxpb25lbCANCg0KRGUg
OiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIE1hcmlh
IENydXogQmFydG9sb21lIA0KRW52b3nDqSA6IGx1bmRpIDI0IGbDqXZyaWVyIDIwMTQgMTQ6MTMg
DQrDgCA6IGRpbWVAaWV0Zi5vcmcgDQpPYmpldCA6IFJlOiBbRGltZV0gIzUyOiBUaHJvdHRsaW5n
IG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNvbmNsdXNpb24g
DQoNCkhlbGxvLCANCg0KSSBhZ3JlZSB3aXRoIFVscmljaCdzIHByb3Bvc2FsIA0KQ2hlZXJzIA0K
L01DcnV6IA0KDQpGcm9tOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3JnXSBPbiBC
ZWhhbGYgT2YgV2llaGUsIFVscmljaCAoTlNOIC0gREUvTXVuaWNoKSANClNlbnQ6IGx1bmVzLCAy
NCBkZSBmZWJyZXJvIGRlIDIwMTQgMTA6NDYgDQpUbzogZXh0IFRST1RUSU4sIEpFQU4tSkFDUVVF
UyAoSkVBTi1KQUNRVUVTKTsgZGltZUBpZXRmLm9yZyANClN1YmplY3Q6IFJlOiBbRGltZV0gIzUy
OiBUaHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAt
IGNvbmNsdXNpb24gDQoNCkkgc2hhcmUgSkphY3F1ZXMgY29uY2Vybi4gUmVwbGFjaW5nICJmcm9t
IG5vdyBvbiIgd2l0aCAiZm9yIHRoZSBwZXJpb2QgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlz
IGFjdGl2ZSIgDQppcyBtaXNsZWFkaW5nLiBNYXkgYmUgaXRzIGJldHRlciB0byBzaW1wbHkgcmVt
b3ZlICJmcm9tIG5vdyBvbiIuIA0KDQpVbHJpY2ggDQoNCg0KDQoNCg0KRnJvbTogRGlNRSBbbWFp
bHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBUUk9UVElOLCBKRUFO
LUpBQ1FVRVMgKEpFQU4tSkFDUVVFUykgDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIxLCAyMDE0
IDc6MTEgUE0gDQpUbzogZGltZUBpZXRmLm9yZyANClN1YmplY3Q6IFJlOiBbRGltZV0gIzUyOiBU
aHJvdHRsaW5nIG5vdCBuZWVkZWQgdG8gYmUgYmFzZWQgb24gcHJldmlvdXMgaGlzdG9yeSAtIGNv
bmNsdXNpb24gDQoNCkhpIE1DcnV6LCBTdGV2ZSANCg0KSSBhbHNvIGFncmVlIG9uIHRoZSAid291
bGQgc2VuZCAiIGluc3RlYWQgb2YgdGhlICJ3b3VsZCBoYXZlIHNlbnQiIMKgZm9yIHN1cmUuIMKg
QnV0IEkgaGF2ZSDCoGEgc21hbGwgY29uY2Vybi8gY2xhcmlmaWNhdGlvbiDCoGFib3V0IHRoZSBT
dGV2ZSBjb21tZW50IG9uIMKgICJmb3IgdGhlIHBlcmlvZCB0aGF0IHRoZSBvdmVybG9hZCByZXBv
cnQgaXMgYWN0aXZlIiBhbmQgdGhlIGV4YW1wbGUgdG8gd2hpY2ggaXQgcmVmZXJzLiANCg0KRHVy
aW5nIHRoZSB0aW1lIHRoZSBPTFIgaXMgYWN0aXZlLCB3aGljaCBtYXkgYmUgcmF0aGVyIGxvbmcs
IMKgdGhlIHRyYWZmaWMgdGhlIHJlYWN0aW5nIG5vZGUgd291bGQgc2VuZCBtYXkgYmUgMTAwIHBh
Y2tldCDCoHdoZW4gaXQgaGFzIGp1c3QgcmVjZWl2ZWQgdGhlIE9MUi4gQSBiaXQgbGF0ZXIsIHRo
ZSB0cmFmZmljIGl0IHdvdWxkIHNlbmQgY291bGQgYmUgMTIwIChvciA4MCksIGFuZCBmcm9tIHRo
ZSBPTFIgZGVmaW5pdGlvbiwgwqAgaXQgd291bGQgc2VuZCAxMjB4MCw5IChvciA4MCogMCw5KSBw
YWNrZXRzLCBvbiDCoHdoaWNoIEkgYWdyZWUuIFRoaXMgaXMgaW4gbGluZSDCoHdpdGggdGhlIGV2
ZXJ5IDEwdGggcGFja2V0IGRyb3BwaW5nIMKgb24gd2hpY2ggSSBhbHNvIGFncmVlLiANCg0KQXMg
dGhlIHRleHQgwqAgd291bGQgwqBiZSB3cml0dGVuIHdpdGggdGhlIFN0ZXZlIG1vZGlmaWNhdGlv
biAsIHdlIG1heSB1bmRlcnN0YW5kIGl0IGlzIMKgODAgUGFja2V0IGR1cmluZyBhbGwgdGhlIHRp
bWUgwqB0aGUgT0xSIGlzIGFjdGl2ZS4gTm90IHlldCB0aGluayB0byBhbiBhbHRlcm5hdGl2ZSB0
ZXh0LCBidXQgZmlyc3QgdG8gc2VlIGlmIHlvdSBhZ3JlZSB3aXRoIG15IHJlbWFyay4gDQoNCkpK
YWNxdWVzIA0KDQoNCkRlIDogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10gRGUg
bGEgcGFydCBkZSBsaW9uZWwubW9yYW5kQG9yYW5nZS5jb20gDQpFbnZvecOpIDogdmVuZHJlZGkg
MjEgZsOpdnJpZXIgMjAxNCAxODozMyANCsOAIDogU3RldmUgRG9ub3ZhbjsgZGltZUBpZXRmLm9y
ZyANCk9iamV0IDogUmU6IFtEaW1lXSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBi
YXNlZCBvbiBwcmV2aW91cyBoaXN0b3J5IC0gY29uY2x1c2lvbiANCg0KKzEgKGluY2x1ZGluZyBT
dGV2ZSBjb21tZW50KSANCg0KRGUgOiBEaU1FIFttYWlsdG86ZGltZS1ib3VuY2VzQGlldGYub3Jn
XSBEZSBsYSBwYXJ0IGRlIFN0ZXZlIERvbm92YW4gDQpFbnZvecOpIDogdmVuZHJlZGkgMjEgZsOp
dnJpZXIgMjAxNCAxNjozNyANCsOAIDogZGltZUBpZXRmLm9yZyANCk9iamV0IDogUmU6IFtEaW1l
XSAjNTI6IFRocm90dGxpbmcgbm90IG5lZWRlZCB0byBiZSBiYXNlZCBvbiBwcmV2aW91cyBoaXN0
b3J5IC0gY29uY2x1c2lvbiANCg0KTWFyaWEgQ3J1eiwgDQoNCkkgc3VwcG9ydCB5b3VyIHN1Z2dl
c3RlZCBjaGFuZ2VzLiDCoEkgaGF2ZSBvbmUgZnVydGhlciBzdWdnZXN0ZWQgY2hhbmdlIGJlbG93
LiANCg0KU3RldmUgDQpPbiAyLzIxLzE0IDI6NDAgQU0sIE1hcmlhIENydXogQmFydG9sb21lIHdy
b3RlOiANCiM1MjogVGhyb3R0bGluZyBub3QgbmVlZGVkIHRvIGJlIGJhc2VkIG9uIHByZXZpb3Vz
IGhpc3RvcnkgDQoNCkZvbGxvd2luZyBhZ3JlZW1lbnQgaXMgcmVhY2hlZDogDQoNCk5vdyAoY2hh
cHRlciA0LjcpOiANCsKgIFRoZSBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSBBVlAgKEFWUCBjb2Rl
IFRCRDgpIGlzIHR5cGUgb2YgVW5zaWduZWQzMiANCsKgIGFuZCBkZXNjcmliZXMgdGhlIHBlcmNl
bnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzIA0KwqAgcmVxdWVzdGVkIHRv
IHJlZHVjZSwgY29tcGFyZWQgdG8gd2hhdCBpdCBvdGhlcndpc2Ugd291bGQgaGF2ZSBzZW50LiAN
Cg0KUHJvcG9zYWw6IA0KwqBUaGUgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgQVZQIChBVlAgY29k
ZSBUQkQ4KSBpcyB0eXBlIG9mIFVuc2lnbmVkMzIgwqAgDQrCoGFuZCBkZXNjcmliZXMgdGhlIHBl
cmNlbnRhZ2Ugb2YgdGhlIHRyYWZmaWMgdGhhdCB0aGUgc2VuZGVyIGlzIMKgIA0KwqByZXF1ZXN0
ZWQgdG8gcmVkdWNlLCBjb21wYXJlZCB0byB3aGF0IGl0IG90aGVyd2lzZSB3b3VsZCBzZW5kLiDC
oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoDwtLS0tIA0KDQoNCk5vdyAoY2hhcHRlciA1LjUuMik6
IA0KwqAgwqAgSW5kaWNhdGVzIHRoYXQgdGhlIHJlcG9ydGluZyBub2RlIHVyZ2VzIHRoZSByZWFj
dGluZyBub2RlIHRvIA0KwqAgwqAgcmVkdWNlIGl0cyB0cmFmZmljIGJ5IGEgZ2l2ZW4gcGVyY2Vu
dGFnZS4gwqBGb3IgZXhhbXBsZSBpZiB0aGUgDQrCoCDCoCByZWFjdGluZyBub2RlIGhhcyBiZWVu
IHNlbmRpbmcgMTAwIHBhY2tldHMgcGVyIHNlY29uZCB0byB0aGUgDQrCoCDCoCByZXBvcnRpbmcg
bm9kZSwgdGhlbiBhIHJlY2VwdGlvbiBvZiBPQy1SZWR1Y3Rpb24tUGVyY2VudGFnZSB2YWx1ZSAN
CsKgIMKgIG9mIDEwIHdvdWxkIG1lYW4gdGhhdCBmcm9tIG5vdyBvbiB0aGUgcmVhY3Rpbmcgbm9k
ZSBNVVNUIG9ubHkgc2VuZCANCsKgIMKgIDkwIHBhY2tldHMgcGVyIHNlY29uZC4gwqBIb3cgdGhl
IHJlYWN0aW5nIG5vZGUgYWNoaWV2ZXMgdGhlICJ0cnVlIA0KwqAgwqAgcmVkdWN0aW9uIiB0cmFu
c2FjdGlvbnMgbGVhZGluZyB0byB0aGUgc2VudCByZXF1ZXN0IG1lc3NhZ2VzIGlzIHVwIA0KwqAg
wqAgdG8gdGhlIGltcGxlbWVudGF0aW9uLiDCoFRoZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkg
ZHJvcCBldmVyeSANCsKgIMKgIDEwdGggcGFja2V0IGZyb20gaXRzIG91dHB1dCBxdWV1ZSBhbmQg
bGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9uIA0KwqAgwqAgbG9naWMgdHJ5IHRvIHJlY292ZXIg
ZnJvbSBpdC4wIDwgdmFsdWUgPCAxMDAgDQoNClByb3Bvc2FsOiANCkluZGljYXRlcyB0aGF0IHRo
ZSByZXBvcnRpbmcgbm9kZSB1cmdlcyB0aGUgcmVhY3Rpbmcgbm9kZSB0byByZWR1Y2UgDQppdHMg
dHJhZmZpYyBieSBhIGdpdmVuIHBlcmNlbnRhZ2UuIEZvciBleGFtcGxlIGlmIHRoZSANCnJlYWN0
aW5nIG5vZGUgd291bGQgc2VuZCAxMDAgcGFja2V0cyB0byB0aGUgwqAgwqAgwqAgwqAgwqAgwqAg
wqAgwqAgwqAgwqAgwqAgwqAgwqA8LS0tIA0KcmVwb3J0aW5nIG5vZGUsIHRoZW4gYSByZWNlcHRp
b24gb2YgT0MtUmVkdWN0aW9uLVBlcmNlbnRhZ2UgdmFsdWUgb2YgDQoxMCB3b3VsZCBtZWFuIHRo
YXQgZnJvbSBub3cgb24gdGhlIHJlYWN0aW5nIG5vZGUgTVVTVCBvbmx5IHNlbmQgDQo5MCBwYWNr
ZXRzIGluc3RlYWQgb2YgMTAwLiBIb3cgdGhlIHJlYWN0aW5nIG5vZGUgYWNoaWV2ZXMgdGhlICJ0
cnVlIMKgIMKgIMKgIDwtLS0gDQpyZWR1Y3Rpb24iIHRyYW5zYWN0aW9ucyBsZWFkaW5nIHRvIHRo
ZSBzZW50IHJlcXVlc3QgbWVzc2FnZXMgaXMgdXAgdG8gDQp0aGUgaW1wbGVtZW50YXRpb24uIFRo
ZSByZWFjdGluZyBub2RlIE1BWSBzaW1wbHkgZHJvcCBldmVyeSAxMHRoIA0KcGFja2V0IGZyb20g
aXRzIG91dHB1dCBxdWV1ZSBhbmQgbGV0IHRoZSBnZW5lcmljIGFwcGxpY2F0aW9uIGxvZ2ljIHRy
eSANCnRvIHJlY292ZXIgZnJvbSBpdC4gDQpTUkQ+IFJlcGxhY2UgImZyb20gbm93IG9uIiBpbiB0
aGUgYWJvdmUgd2l0aCAiZm9yIHRoZSBwZXJpb2QgdGhhdCB0aGUgb3ZlcmxvYWQgcmVwb3J0IGlz
IGFjdGl2ZSIgDQoNCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fIA0KRGlNRSBtYWlsaW5nIGxpc3QgDQpEaU1FQGlldGYub3JnIA0KaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaW1lIA0KDQoNCl9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gDQoN
CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu
Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg
ZG9uYyANCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp
c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6
IGxlIHNpZ25hbGVyIA0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl
cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw
dGlibGVzIGQnYWx0ZXJhdGlvbiwgDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0
ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2ku
IA0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl
bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg
bGF3OyANCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0
aG91dCBhdXRob3Jpc2F0aW9uLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLiANCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz
IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk
IG9yIGZhbHNpZmllZC4gDQpUaGFuayB5b3UuIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIA0KDQpDZSBtZXNzYWdlIGV0
IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29u
ZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgDQpwYXMgZXRy
ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91
cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciAN
CmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50
ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy
YXRpb24sIA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn
ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLiANCg0KVGhpcyBtZXNz
YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp
bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgDQp0aGV5IHNo
b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh
dGlvbi4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht
ZW50cy4gDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv
ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu
IA0KVGhhbmsgeW91LiANCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18gDQpEaU1FIG1haWxpbmcgbGlzdCANCkRpTUVAaWV0Zi5vcmcgDQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUgDQoNCg0KX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBtZXNz
YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv
bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCnBh
cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT
aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h
bGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq
b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh
bHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVz
c2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlzIG1l
c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp
dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhleSBz
aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz
YXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug
bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht
ZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y
IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4N
ClRoYW5rIHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQpEaU1FIG1haWxpbmcgbGlzdA0KRGlNRUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9kaW1lDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QNCkRpTUVAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGltZQ0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxpc3QN
CkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlt
ZSANCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv
bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl
dCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMg
c2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1
ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWlu
c2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRh
bnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u
c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu
IE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29u
ZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk
IGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3
aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g
ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBh
bmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu
b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv
ciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg==


From nobody Tue Mar  4 23:52: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 D9DD01A033F for ; Tue,  4 Mar 2014 23:36:01 -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 NeSXDkLrv_oL for ; Tue,  4 Mar 2014 23:35:45 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id C0E971A02C7 for ; Tue,  4 Mar 2014 23:35:44 -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 s257Zcqr001416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Mar 2014 01:35:39 -0600 (CST)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s257ZbRg018019 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 08:35:38 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 5 Mar 2014 08:35:37 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0D/9p5E0P/tHNMw/9nRdqA=
Date: Wed, 5 Mar 2014 07:35:36 +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>  <087A34937E64E74E848732CFF8354B9209789198@ESESSMB101.ericsson.se> <16317_1393952811_5316082B_16317_4358_1_6B7134B31289DC4FAF731D844122B36E4DF9F3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <16317_1393952811_5316082B_16317_4358_1_6B7134B31289DC4FAF731D844122B36E4DF9F3@PEXCVZYM13.corporate.adroot.infra.ftgroup>
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_E194C2E18676714DACA9C3A2516265D20266D9A9FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gITgYzKqQbTz7GZwUhZ-yXbsdN0
X-Mailman-Approved-At: Tue, 04 Mar 2014 23:52: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: Wed, 05 Mar 2014 07:36:02 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266D9A9FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I share the Lionel's view about the added value this optimization may  brin=
g  versus  the extra  costs it has.  I also feel  uncomfortable when we bre=
ak the  principle of the independency of the DOIC associations. When we bre=
ak it, this  has  consequences (cf my mail), but in the future it may have =
some unexpected others.

Best regards

JJacques


De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Envoy=E9 : mardi 4 mars 2014 18:07
=C0 : Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf=
.org
Objet : RE: [Dime] Issue#35 conclusion

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_E194C2E18676714DACA9C3A2516265D20266D9A9FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

I share the Lionel’=
s view about the added value this optimization may  bring  versus=
  the extra  costs it has.  I also feel  uncomfortable =
when we break the 
 principle of the independency of the DOIC associations. When we break it, =
this  has  consequences (cf my mail), but in the future it may ha=
ve some unexpected others.



 <=
/p>

Best regards<=
o:p>


 


JJacques



 


 






De =
: lionel.morand@orange.=
com [mailto:lionel.morand@orange.com]


Envoy=E9 : mardi 4 mars 2014 18:07

=C0 : Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES=
); dime@ietf.org

Objet : RE: [Dime] Issue#35 conclusion






 


Hi,


 <=
/p>

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 w=
ill have to expect to store OLR for specific non-supporting DOIC nodes anyw=
ay. So OK, with the new type, time to time, you will be
 able to optimize a little bit.


But this comes with some =
extra cost as you have now to manage possible interactions between two flav=
ors of the same OLR.


 <=
/p>

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,


 <=
/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 [ma=
ilto: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




 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






--_000_E194C2E18676714DACA9C3A2516265D20266D9A9FR712WXCHMBA12z_--


From nobody Wed Mar  5 00:04: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 CD6A31A0360 for ; Wed,  5 Mar 2014 00:04: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 Xq9YCQ6eEaG6 for ; Wed,  5 Mar 2014 00:04:46 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3C1A0351 for ; Wed,  5 Mar 2014 00:04:46 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2584foB018256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Mar 2014 02:04:42 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2584cvo030628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 09:04:40 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 5 Mar 2014 09:04:38 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
Thread-Index: AQHPMw0JGtrTRsliJUeEVr/FYOo8wprSKLcg
Date: Wed, 5 Mar 2014 08:04:37 +0000
Message-ID: 
References: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org>
In-Reply-To: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Nt6Fj3QesT1YS4xnpvqUkkjMlB8
Subject: Re: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
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: Wed, 05 Mar 2014 08:04:49 -0000

Hi=20

If several DAS are producing realm OLRs, I think they have to ensure the co=
nsistency of the realm overload value they produced. Putting  a new Diamete=
r Identity still adds complexity. Clients are not aware of the DAs deployed=
 , they only know the peer DAs with which they have  a connection.  Then if=
 a client receives two different realm overload reports from two DAS,  what=
 does the client do with these two realm OLRs?

I would also remind a point I did in Porto: a client is aware of the overlo=
ad or non overload of the different servers with which it has traffic, and =
can do an average (even weighted by the traffic it has with these servers) =
to infer a realm overload value that may be relevant when sending the reque=
sts with only realm destination. . This possibility should be allowed for m=
e. I do not say it should be the only way as I am OK to have a realm OL com=
ing from  DA that could be more accurate.=20

Best regards

JJacques   =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoy=E9=A0: mercredi 26 f=E9vrier 2014 17:06
=C0=A0: ulrich.wiehe@nsn.com
Cc=A0: dime@ietf.org
Objet=A0: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nod=
es for realm-routed-request type reports

#58: Multiple Reporting Nodes for realm-routed-request type reports

 In deployments where more than one node is configured to take the role of =
 a reporting node for realm-routed-request reports, reacting nodes may  rec=
eive  in different answer messages different realm-routed-request type OLRs=
  inserted by the different reporting nodes. Although it is expected that  =
the different reporting nodes report more or less the same content, it  can=
not be expected that reports are 100% synchronized. Especially sequence  nu=
mbers may differ.
 To allow reacting nodes correctly detect outdates/replays/freshness of  OL=
Rs in this scenario, it is proposed that realm-routed-request type OLRs  ar=
e extended to contain the Diameter Identity of the reporting node that  ins=
erted the realm-routed-request type OLR. (e.g. as already proposed in  draf=
t-donovan-dime-agent-overload-01).
 Reporting nodes that insert realm-routed-request type OLRs to answer  mess=
ages MUST also insert their Diameter Identity.
 Reacting nodes MUST take the Diameter Identity received within the OLR  in=
to account in order to detect outdates/replays/freshness.

--=20
-----------------------------------+--------------------------
 Reporter:  ulrich.wiehe@nsn.com   |      Owner:  Ulrich Wiehe
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  draft-docdt-dime-ovli  |    Version:  1.0
 Severity:  Active WG Document     |   Keywords:
-----------------------------------+--------------------------

Ticket URL: 
dime 

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


From nobody Wed Mar  5 00:34: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 C6CF61A023B for ; Wed,  5 Mar 2014 00:33:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 UPBtBIYgYlDx for ; Wed,  5 Mar 2014 00:33:57 -0800 (PST)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC8A1A034A for ; Wed,  5 Mar 2014 00:33:56 -0800 (PST)
Received: by mail-we0-f177.google.com with SMTP id u57so761147wes.8 for ; Wed, 05 Mar 2014 00:33:53 -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 :content-transfer-encoding:message-id:references:to; bh=4LA0Iti71h3RfnVdJAkCl2w1ALOMyFTADVVYXsj8Q8o=; b=GzhSA5L/u/BrS5OxpJdnVc19wdOerPJhb0B7ITr8iG3W82moD6cF6F7RYiXVGoxlbI WJLpnsTih5pX/tREstYKKtmtdkDSkIGBm4BH4mms681ysJWKZbHdaj8gHu84XgBLLMK+ zPM1SNfn5kSMwwz5WTcNuEgGQSDI+DUIAO9k0PW0g+OUcMMSQzdSDvX7Hhj/2TI1BMw9 nwn/G+BCyM0ByWbJOUy0VeD/KuqoHYPt75tHh7Mmap6QZEILRhyPRx5SFamuSYJ7+qSU xn6KAYuWRRecjiyVf73bJAcVL3W3K0Mnn8amJjtacPyyWbyI+17MxdMxZIrdL09ziO0Z LFeQ==
X-Received: by 10.194.58.180 with SMTP id s20mr6490300wjq.54.1394008433044; Wed, 05 Mar 2014 00:33:53 -0800 (PST)
Received: from dhcp-hotel-wifi-158-c9.meeting.ietf.org ([130.129.158.201]) by mx.google.com with ESMTPSA id ju6sm8198501wjc.1.2014.03.05.00.33.49 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 00:33:49 -0800 (PST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net>
Date: Wed, 5 Mar 2014 08:33:48 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com>
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 > <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , ext Ben Campbell , "ext Askerup, Anders" , "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3BdeX0aH0GwRx0ewLMUqxu_CXmM
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: Wed, 05 Mar 2014 08:33:59 -0000

So. are we OK to agree and close the issue #30 for the part that was
proposed here: =
http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
i.e. OC-Supported-Features is in every answer message? I am not sure =
anymore
since the discussion got exploded again to multiple directions.

Yes or yes? ;-)

If yes, we can close issue #30, document the conclusion and the changed =
text
snippets into the issue tracker, and then concentrate tearing apart the =
rest
of the functionality and implications based on the above decision in =
another
issue and thread?

- Jouni


On Mar 4, 2014, at 2:58 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Steve,
> I m trying to progress this.
> =20
> As you say we don=92t have consensus on the question  whether =
capability exchange should be kept separate from overload reports or =
not.
> =20
> Let=92s focus on this issue.
> =20
> 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)
> =20
> Ulrich
> =20
> =20
> =20
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> 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
> =20
> Ulrich,
>=20
> We've already discussed this.
>=20
> I understand that you don't think that the OC-Supported-Features AVP =
should be required in all answer messages.
>=20
> Others of us think that it should be.  We can't make progress if we =
have to re-debate every point multiple times.
>=20
> I suggest that we follow Jouni's guidance made a few emails back and =
move on.
>=20
> Steve
>=20
> On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> 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
> =20
> 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. =85so that the =
the reacting node can =96 based on that information =96 do =
what?
>=20
> 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?
>=20
> Steve
>=20
> On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> I agree with Ben
> =20
> But then again: which purpose does OC-Supported-Features I answer =
serve?
> Ulrich
> =20
> -----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.org list
> Subject: Re: [Dime] Issue#30 status
> =20
> =20
> On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
> =20
> 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.
> =20
> 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
> =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).
> =20
> 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
> =20
> Ulrich
> =20
> =20
> =20
> =20


From nobody Wed Mar  5 01:15:04 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 B46371A02AD for ; Wed,  5 Mar 2014 01:15:01 -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 U21NGZYsRzQA for ; Wed,  5 Mar 2014 01:14:58 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0B21A029E for ; Wed,  5 Mar 2014 01:14:58 -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 s259EcJm088361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 03:14:40 -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: <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com>
Date: Wed, 5 Mar 2014 09:14:38 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <169D3829-5224-43C0-BD7E-DAB61BF8D7E3@nostrum.com>
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@usdon! ovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7vPvdcdDeo8nH9LRdxJ3UZWYeUo
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: Wed, 05 Mar 2014 09:15:02 -0000

On Mar 5, 2014, at 8:33 AM, Jouni Korhonen  =
wrote:

>=20
> So. are we OK to agree and close the issue #30 for the part that was
> proposed here: =
http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
> i.e. OC-Supported-Features is in every answer message? I am not sure =
anymore
> since the discussion got exploded again to multiple directions.
>=20
> Yes or yes? ;-)

Yes for me.

>=20
> If yes, we can close issue #30, document the conclusion and the =
changed text
> snippets into the issue tracker, and then concentrate tearing apart =
the rest
> of the functionality and implications based on the above decision in =
another
> issue and thread?
>=20
> - Jouni
>=20


From nobody Wed Mar  5 01:28:20 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 BF0DC1A0199 for ; Wed,  5 Mar 2014 01:27:26 -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 ni4UUBASEcem for ; Wed,  5 Mar 2014 01:27:14 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 7698A1A00F2 for ; Wed,  5 Mar 2014 01:27:14 -0800 (PST)
Received: from dhcp-a343.meeting.ietf.org ([31.133.163.67]:55079) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WL86S-00055Q-ML for dime@ietf.org; Wed, 05 Mar 2014 01:27:11 -0800
Message-ID: <5316EDEB.9080606@usdonovans.com>
Date: Wed, 05 Mar 2014 09:27:07 +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: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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: 
Content-Type: multipart/alternative; boundary="------------070704080309000008080207"
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/jT3Qys36YkW6FgVezjiKSnEdLXA
X-Mailman-Approved-At: Wed, 05 Mar 2014 01:28:14 -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: Wed, 05 Mar 2014 09:27:27 -0000

This is a multi-part message in MIME format.
--------------070704080309000008080207
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJacques,

See my comments inline.

Steve

On 3/4/14 1:34 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> 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 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  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 rule 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 sure the story is finished., if later the 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  sending 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 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, the OLR type(1) applies to this client.   
>
SRD> It doesn't need to be this complex.  The rule should be that when a
reporting node starts to use a per client report for an individual
client then the reporting node must continue to use per client reports
for the duration of the occurrence of overload.  This removes any
confusion about what the reacting node should do.
>
>  
>
>  
>
> 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 those 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 brought 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?
>
SRD> I guess I don't understand.  The type 1 report will have a sequence
number.  Each type 0 report will have its own sequence number.  As long
as those follow the defined behavior for sequence numbers then there
should be no issue.
>
>  
>
> 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 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 value would be (0). Views?
>
SRD> Again, I don't understand.  What mandatory OLR?  An OLR is only
sent when the reacting node is actually in an overload state.  It will
send no OLR when it is no longer overloaded. 
>
>  
>
> 4)      Regarding DOIC association, here we have an information (OLR
> with type (1)  exchanged inside  a DOIC association that applies to
> many DOIC associations.  It is possible but it should be highlighted .
>
SRD> What is the issue?
>
>  
>
> 5)      I also saw Mcruz had a preferencee for another OLR type and
> not a new AVP, have  we concluded on this .
>
SRD> I don't have a strong preference but adding a scope or type AVP to
the OLR AVP seems to work.
>
>  
>
> What are your 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 need to add the right rules to avoid unexpected 
> situations and  misunderstanding
>
SRD> I don't see this as an optimization.  Adding per client reports is
a new feature.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* jeudi 27 février 2014 21:11
> *À :* 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
> shall apply the OLR or type (0) for traffic from that client. The old
> OLR of type (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 "all 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 the 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 Bartolome
>     *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 same 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 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 regards
>
>     /MCruz
>
>      
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Wiehe,
>     Ulrich (NSN - DE/Munich)
>     *Sent:* miércoles, 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 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't think there are impacts on sequence number handling,
>     report types or 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 support the "optimization" and want to use it;
>
>     Reporting nodes that better like B) could allways send (1) unless
>     they support 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 the 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 client 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-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
>
>      
>
>     On my side,  I agree with Lionel.
>
>      
>
>     I  have not the  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 the OLR can be different  for another
>     DOIC association. The basic (or "default") principle is that each
>     DOIC association has its "own 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 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 supporting 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 fact a set of clients are considered for me
>     as a pool regarding  DOIC where only one OLR applies and where
>     throttling  applies  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 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 "collateral " effect of the
>     optimization. I would also think that, instead 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.
>
>      
>
>     Ulrich  also mentioned that for realm OLRs we may also have  a
>     different realm  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 the same reason  to have  an
>     optimization  where all clients receives  the  same realm OLR, but
>     to also see the collateral effects.
>
>      
>
>     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 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é :* mardi 25 février 2014 10:09
>     *À :* 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.org 
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>     Lionel,
>
>     The question is whether the reporting node is sending the overload
>     report per client or it is sending a global overload report that
>     applies to all clients. 
>
>     I still believe that the default behavior of a reporting node will
>     be to have a single overload reduction value for the application
>     and that that overload reduction value will apply to all clients. 
>     If this is the case then there 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 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
>
>          
>
>         What about the DOIC association? What about my assumption
>         about agent maintaining overload control state for non-DOIC
>         enabled client?
>
>         So for me, the proposal from Ulrich is a clarification on the
>         agent behavior 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 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 the way the OLR is handled by reacting
>         nodes.
>
>          
>
>         Lionel
>
>          
>
>         *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
>         Steve Donovan
>         *Envoyé :* lundi 24 février 2014 19:50
>         *À :* dime@ietf.org 
>         *Objet :* Re: [Dime] Issue#35 conclusion
>
>          
>
>         Maria Cruz,
>
>         To the degree possible we should minimize the per application
>         overload logic required.  To this end, it would be better to
>         have this as part of the 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 Origin-Host 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 mitigation 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
>             overload 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
>
>              
>
>             *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 host 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 OLR 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 reporting 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, reacting node
>             when then global reduction percentage doesn't do the job.
>
>             In addition, if the normal case is that reporting nodes
>             have a single global 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 adds
>             no value.
>
>             My proposal is the following:
>
>             - Add an optional AVP (call it something like
>             Single-Node???) to overload reports that indicate when an
>             overload report applies to a specific reacting node.
>
>             - Absence of the AVP indicates that the report applies to
>             all reacting nodes (clients and agents acting on behalf of
>             non-DOIC clients).
>
>             - Reporting nodes should only include the Single-Node AVP
>             if the overload report 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 that when making
>             throttling decisions, the agent does not differentiate
>             which non supporting client originated the request.
>
>             - DOIC-supporting agents receiving an OLR with the
>             Single-Node AVP for a transaction 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 the -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:
>
>                 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 client 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 always put this AVP in every answer, even if the OLR is the same for all the clients.
>
>                  
>
>                 Regards,
>
>                  
>
>                 Lionel
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
>
>                 Envoyé : lundi 24 février 2014 14:27
>
>                 À : 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 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 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 from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction 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 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.
>
>                  
>
>                 Best regards
>
>                 Ulrich
>
>                  
>
>                 -----Original Message-----
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
>
>                 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 which 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 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."
>
>                  
>
>                 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-JACQUES (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" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
>
>                 Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .
>
>                  
>
>                 For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.
>
>                  
>
>                 Best regards
>
>                  
>
>                 Jacques 
>
>                  
>
>                    
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : 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 server answer shall be marked:
>
>                  
>
>                 a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
>
>                 Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
>
>                 But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
>
>                 Then, this is why the proposal is to add following clarification about agent 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 which 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 Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following 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 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-Host" in the request) from which traffic reduction shall apply.
>
>                 With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.
>
>                  
>
>                 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 agents 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 request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting 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 transaction.  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 for 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 that are specific to just the Origin-Host in the request.  Absence of the "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.
>
>                 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 want to differentiate, and therefore allow agents not to do the binding to the client.     
>
>                  
>
>                 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 for 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 which corresponds to the answer containing the OLR. 
>
>                  
>
>                 This would cover not only the case where an agent takes the role of the 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.
>
>                  
>
>                 b) There is no binding of the OLR to the orig-host of the client Here I disagree. 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.
>
>                  
>
>                 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 client not supporting DOIC, this agent needs to bind the received OLR to the origin-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 whether it's the client or an agent on the path that takes the role of the reacting node  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>
>                  the binding is always there, regardless of DOIC support at the client
>
>                  
>
>                  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 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 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
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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


--------------070704080309000008080207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJacques,

      

      See my comments inline.

      

      Steve

      

    
    
On 3/4/14 1:34 PM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
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 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  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 rule 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
            sure the story is finished., if later the 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 
            sending 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 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, the OLR type(1)
            applies to this client.   
          

      

    

    SRD> It doesn't need to be this complex.  The rule should be that
    when a reporting node starts to use a per client report for an
    individual client then the reporting node must continue to use per
    client reports for the duration of the occurrence of overload.  This
    removes any confusion about what the reacting node should do. 

    

      

        

        
 

        
 

        

          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 those 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 brought 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?

      

    

    SRD> I guess I don't understand.  The type 1 report will have a
    sequence number.  Each type 0 report will have its own sequence
    number.  As long as those follow the defined behavior for sequence
    numbers then there should be no issue.

    

      

        

        
 

        

          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 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 value would be (0). Views?

      

    

    SRD> Again, I don't understand.  What mandatory OLR?  An OLR is
    only sent when the reacting node is actually in an overload state. 
    It will send no OLR when it is no longer overloaded.  

    

      

        

        
 

        

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

      

    

    SRD> What is the issue?

    

      

        

        
 

        

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

      

    

    SRD> I don't have a strong preference but adding a scope or type
    AVP to the OLR AVP seems to work.

    

      

        

        
 

        
What
            are your 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 need to
            add the right rules to avoid unexpected  situations and 
            misunderstanding
          

      

    

    SRD> I don't see this as an optimization.  Adding per client
    reports is a new feature.

    

      

        

        
 

        
Best regards

        
 

        
JJacques
            

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : jeudi 27 février 2014 21:11

                À : 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 shall apply the OLR or type (0) for traffic
          from that client. The old OLR of type (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 "all 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 the 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 Bartolome

                  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 same 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 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
              regards

          
/MCruz

          
 

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

                  Sent: miércoles, 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 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’t think there are impacts on sequence number handling,
              report types or 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 support the “optimization” and want to use it;

          
Reporting
              nodes that better like B) could allways send (1) unless
              they support 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 the 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 client 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-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

          
 

          
On
              my side,  I agree with Lionel.

          
 

          
I
               have not the  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 the OLR can be
              different  for another DOIC association. The basic (or
              “default”) principle is that each DOIC association has its
              “own 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 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
              supporting 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 fact a set of clients
              are considered for me as a pool regarding  DOIC where only
              one OLR applies and where throttling  applies  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 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 “collateral “
              effect of the optimization. I would also think that,
              instead 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.

          
 

          
Ulrich
               also mentioned that for realm OLRs we may also have  a
              different realm  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
              the same reason  to have  an optimization  where all
              clients receives  the  same realm OLR, but to also see the
              collateral effects.
            

          
 

          
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 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é : mardi 25 février 2014 10:09

                  À : 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.org

                  Subject: Re: [Dime] Issue#35 conclusion

            

          

          
 

          
Lionel,

            

            The question is whether the reporting node is sending the
            overload report per client or it is sending a global
            overload report that applies to all clients. 
            

            

            I still believe that the default behavior of a reporting
            node will be to have a single overload reduction value for
            the application and that that overload reduction value will
            apply to all clients.  If this is the case then there 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 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

            
 

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

            
So
                for me, the proposal from Ulrich is a clarification on
                the agent behavior 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 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 the way the OLR is handled by
                reacting nodes.

            
 

            
Lionel

            
 

            

              

                
De : DiME [mailto:dime-bounces@ietf.org]
                    De la part de Steve Donovan

                    Envoyé : lundi 24 février 2014 19:50

                    À : dime@ietf.org

                    Objet : Re: [Dime] Issue#35 conclusion

              

            

            
 

            
Maria
              Cruz,

              

              To the degree possible we should minimize the per
              application overload logic required.  To this end, it
              would be better to have this as part of the 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 Origin-Host 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 mitigation 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 overload 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

              
 

              

                

                  
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 host 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 OLR 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 reporting 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,
                reacting node when then global reduction percentage
                doesn't do the job.

                

                In addition, if the normal case is that reporting nodes
                have a single global 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
                adds no value.

                

                My proposal is the following:

                

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

                

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

                

                - Reporting nodes should only include the Single-Node
                AVP if the overload report 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 that when making
                throttling decisions, the agent does not differentiate
                which non supporting client originated the request.

                

                - DOIC-supporting agents receiving an OLR with the
                Single-Node AVP for a transaction 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 the -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:

              

              

                
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 client 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 always put this AVP in every answer, even if the OLR is the same for all the clients.

                
 

                
Regards,

                
 

                
Lionel

                
 

                
-----Message d'origine-----

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

                
Envoyé : lundi 24 février 2014 14:27

                
À : 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 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 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 from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction 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 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

                
 

                
Best regards

                
Ulrich

                
 

                
-----Original Message-----

                
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome

                
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 which 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 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."

                
 

                
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-JACQUES (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" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 

                
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

                
 

                
For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

                
 

                
Best regards

                
 

                
Jacques 

                
 

                
   

                
 

                
-----Message d'origine-----

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : 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 server answer shall be marked:

                
 

                
a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.

                
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.

                
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.

                
Then, this is why the proposal is to add following clarification about agent 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 which 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 Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following 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 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-Host" in the request) from which traffic reduction shall apply.

                
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

                
 

                
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 agents 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 request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.

                
<Ulrich>I fully agree</Ulrich>

                
 

                
 

                
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 transaction.  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.

                
<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>

                
 

                
My 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.

                
<Ulrich> I agree </Ulrich>

                
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "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.

                
<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 want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

                
 

                
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 for 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 which corresponds to the answer containing the OLR. 

                
 

                
This would cover not only the case where an agent takes the role of the 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.

                
 

                
b) There is no binding of the OLR to the orig-host of the client Here I disagree. 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.

                
 

                
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) <ulrich.wiehe@nsn.com> 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 client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

                
 

                
I do not agree.

                
 

                
You proposal implies that the server's OLR only applies to that client.

                
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.

                
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

                
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

                
 

                
 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 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 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

            

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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


    

    

  


--------------070704080309000008080207--


From nobody Wed Mar  5 01:37: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 A87FA1A02F2 for ; Wed,  5 Mar 2014 01:37:37 -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 FuPDiTBArgKS for ; Wed,  5 Mar 2014 01:37:31 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 75EF41A00F2 for ; Wed,  5 Mar 2014 01:37:31 -0800 (PST)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id F2337374642; Wed,  5 Mar 2014 10:37:26 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id D8EEC18012D; Wed,  5 Mar 2014 10:37:26 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Mar 2014 10:37:26 +0100
From: 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
Thread-Index: AQHPMw0JGtrTRsliJUeEVr/FYOo8wprSKLcggAAdpAA=
Date: Wed, 5 Mar 2014 09:37:26 +0000
Message-ID: <29386_1394012246_5316F056_29386_11289_1_6B7134B31289DC4FAF731D844122B36E4E172C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> 
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.1]
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.4.80315
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zvM3rjtCPraIMO_6yhGsfC2WE_I
Subject: Re: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
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: Wed, 05 Mar 2014 09:37:37 -0000

The response to this issue is simple: no realm indication if you cannot ens=
ure that this info is valid for the entire realm.
Anything else is out of scope.

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
Envoy=E9=A0: mercredi 5 mars 2014 09:05
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting=
 Nodes for realm-routed-request type reports

Hi=20

If several DAS are producing realm OLRs, I think they have to ensure the co=
nsistency of the realm overload value they produced. Putting  a new Diamete=
r Identity still adds complexity. Clients are not aware of the DAs deployed=
 , they only know the peer DAs with which they have  a connection.  Then if=
 a client receives two different realm overload reports from two DAS,  what=
 does the client do with these two realm OLRs?

I would also remind a point I did in Porto: a client is aware of the overlo=
ad or non overload of the different servers with which it has traffic, and =
can do an average (even weighted by the traffic it has with these servers) =
to infer a realm overload value that may be relevant when sending the reque=
sts with only realm destination. . This possibility should be allowed for m=
e. I do not say it should be the only way as I am OK to have a realm OL com=
ing from  DA that could be more accurate.=20

Best regards

JJacques=20=20=20=20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoy=E9=A0: mercredi 26 f=E9vrier 2014 17:06
=C0=A0: ulrich.wiehe@nsn.com
Cc=A0: dime@ietf.org
Objet=A0: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nod=
es for realm-routed-request type reports

#58: Multiple Reporting Nodes for realm-routed-request type reports

 In deployments where more than one node is configured to take the role of =
 a reporting node for realm-routed-request reports, reacting nodes may  rec=
eive  in different answer messages different realm-routed-request type OLRs=
  inserted by the different reporting nodes. Although it is expected that  =
the different reporting nodes report more or less the same content, it  can=
not be expected that reports are 100% synchronized. Especially sequence  nu=
mbers may differ.
 To allow reacting nodes correctly detect outdates/replays/freshness of  OL=
Rs in this scenario, it is proposed that realm-routed-request type OLRs  ar=
e extended to contain the Diameter Identity of the reporting node that  ins=
erted the realm-routed-request type OLR. (e.g. as already proposed in  draf=
t-donovan-dime-agent-overload-01).
 Reporting nodes that insert realm-routed-request type OLRs to answer  mess=
ages MUST also insert their Diameter Identity.
 Reacting nodes MUST take the Diameter Identity received within the OLR  in=
to account in order to detect outdates/replays/freshness.

--=20
-----------------------------------+--------------------------
 Reporter:  ulrich.wiehe@nsn.com   |      Owner:  Ulrich Wiehe
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  draft-docdt-dime-ovli  |    Version:  1.0
 Severity:  Active WG Document     |   Keywords:
-----------------------------------+--------------------------

Ticket URL: 
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.


From nobody Wed Mar  5 01:54: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 411631A0394 for ; Wed,  5 Mar 2014 01:54:19 -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 uXgzy2yv6v-M for ; Wed,  5 Mar 2014 01:54:18 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 131861A0283 for ; Wed,  5 Mar 2014 01:54:18 -0800 (PST)
Received: from dhcp-a343.meeting.ietf.org ([31.133.163.67]:49184) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WL8WZ-0001jQ-EG; Wed, 05 Mar 2014 01:54:13 -0800
Message-ID: <5316F43E.2070304@usdonovans.com>
Date: Wed, 05 Mar 2014 09:54:06 +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: Ben Campbell ,  Jouni Korhonen 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@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@usdon! ovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <169D3829-5224-43C0-BD7E-DAB61BF8D7E3@nostrum.com>
In-Reply-To: <169D3829-5224-43C0-BD7E-DAB61BF8D7E3@nostrum.com>
Content-Type: multipart/alternative; boundary="------------090801060709080503010602"
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/WFDu_H50kiqJkyXwur4sD3S-qCE
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: Wed, 05 Mar 2014 09:54:19 -0000

This is a multi-part message in MIME format.
--------------090801060709080503010602
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Yes and yes for me.

On 3/5/14 9:14 AM, Ben Campbell wrote:
> On Mar 5, 2014, at 8:33 AM, Jouni Korhonen  wrote:
>
>> So. are we OK to agree and close the issue #30 for the part that was
>> proposed here: http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
>> i.e. OC-Supported-Features is in every answer message? I am not sure anymore
>> since the discussion got exploded again to multiple directions.
>>
>> Yes or yes? ;-)
> Yes for me.
>
>> If yes, we can close issue #30, document the conclusion and the changed text
>> snippets into the issue tracker, and then concentrate tearing apart the rest
>> of the functionality and implications based on the above decision in another
>> issue and thread?
>>
>> - Jouni
>>


--------------090801060709080503010602
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 7bit


  
    
  
  
    Yes and yes for me.

      

    
    
On 3/5/14 9:14 AM, Ben Campbell wrote:

    

    

      
On Mar 5, 2014, at 8:33 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:



      

        
So. are we OK to agree and close the issue #30 for the part that was
proposed here: http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
i.e. OC-Supported-Features is in every answer message? I am not sure anymore
since the discussion got exploded again to multiple directions.

Yes or yes? ;-)


      

      
Yes for me.



      

        
If yes, we can close issue #30, document the conclusion and the changed text
snippets into the issue tracker, and then concentrate tearing apart the rest
of the functionality and implications based on the above decision in another
issue and thread?

- Jouni



      

      

    

    

  


--------------090801060709080503010602--


From nobody Wed Mar  5 01:54:30 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 B1A871A03A3 for ; Wed,  5 Mar 2014 01:54:25 -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 M3g3NwZcIg9w for ; Wed,  5 Mar 2014 01:54:24 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 748191A039C for ; Wed,  5 Mar 2014 01:54:24 -0800 (PST)
Received: from dhcp-a343.meeting.ietf.org ([31.133.163.67]:49189) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WL8Wq-00022e-9A for dime@ietf.org; Wed, 05 Mar 2014 01:54:21 -0800
Message-ID: <5316F44F.5080104@usdonovans.com>
Date: Wed, 05 Mar 2014 09:54:23 +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: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070007050706080109090303"
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/AZJe9xf7s5QHdp_ZibJVOFBa1dk
Subject: Re: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
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: Wed, 05 Mar 2014 09:54:25 -0000

This is a multi-part message in MIME format.
--------------070007050706080109090303
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJacques,

Please see my comments inline.

Steve

On 3/5/14 8:04 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi 
>
> If several DAS are producing realm OLRs, I think they have to ensure the consistency of the realm overload value they produced. Putting  a new Diameter Identity still adds complexity. Clients are not aware of the DAs deployed , they only know the peer DAs with which they have  a connection.  Then if a client receives two different realm overload reports from two DAS,  what does the client do with these two realm OLRs?
SRD> It is clearly the case that we need wording on how to handle the
fact that Realm-Routed-Request (RRR) reports and the newly proposed
Realm reports can be sent from multiple places.  I'm preparing some
slides for use in the working group meeting to start to address this
point.  I'll put them on the mailing list when they are ready, probably
later today.

SRD> I have proposed that a reacting node only listen to one source of
the RRR and Realm reports for any overload occurrence.  This likely
requires including the source of the report in the report itself.  Can
you explain why it is an issue that a reacting node doesn't what about a
DA in advance of receiving the report?
> I would also remind a point I did in Porto: a client is aware of the overload or non overload of the different servers with which it has traffic, and can do an average (even weighted by the traffic it has with these servers) to infer a realm overload value that may be relevant when sending the requests with only realm destination. . This possibility should be allowed for me. I do not say it should be the only way as I am OK to have a realm OL coming from  DA that could be more accurate. 
SRD> Clients do not have a full view of the network, so relying on
clients to guess when the realm is very unlikely to ever work well for
networks of any real complexity.  That said, clients can clearly do so
if they want.  There is no protocol that needs to be defined as part of
DOIC to allow this to happen so it is out of scope for DOIC. 
> Best regards
>
> JJacques    
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
> Envoyé : mercredi 26 février 2014 17:06
> À : ulrich.wiehe@nsn.com
> Cc : dime@ietf.org
> Objet : [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
>
> #58: Multiple Reporting Nodes for realm-routed-request type reports
>
>  In deployments where more than one node is configured to take the role of  a reporting node for realm-routed-request reports, reacting nodes may  receive  in different answer messages different realm-routed-request type OLRs  inserted by the different reporting nodes. Although it is expected that  the different reporting nodes report more or less the same content, it  cannot be expected that reports are 100% synchronized. Especially sequence  numbers may differ.
>  To allow reacting nodes correctly detect outdates/replays/freshness of  OLRs in this scenario, it is proposed that realm-routed-request type OLRs  are extended to contain the Diameter Identity of the reporting node that  inserted the realm-routed-request type OLR. (e.g. as already proposed in  draft-donovan-dime-agent-overload-01).
>  Reporting nodes that insert realm-routed-request type OLRs to answer  messages MUST also insert their Diameter Identity.
>  Reacting nodes MUST take the Diameter Identity received within the OLR  into account in order to detect outdates/replays/freshness.
>


--------------070007050706080109090303
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJacques,

      

      Please see my comments inline.

      

      Steve

      

    
    
On 3/5/14 8:04 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
Hi 

If several DAS are producing realm OLRs, I think they have to ensure the consistency of the realm overload value they produced. Putting  a new Diameter Identity still adds complexity. Clients are not aware of the DAs deployed , they only know the peer DAs with which they have  a connection.  Then if a client receives two different realm overload reports from two DAS,  what does the client do with these two realm OLRs?

    

    SRD> It is clearly the case that we need wording on how to handle
    the fact that Realm-Routed-Request (RRR) reports and the newly
    proposed Realm reports can be sent from multiple places.  I'm
    preparing some slides for use in the working group meeting to start
    to address this point.  I'll put them on the mailing list when they
    are ready, probably later today.

    

    SRD> I have proposed that a reacting node only listen to one
    source of the RRR and Realm reports for any overload occurrence. 
    This likely requires including the source of the report in the
    report itself.  Can you explain why it is an issue that a reacting
    node doesn't what about a DA in advance of receiving the report? 

    

      
I would also remind a point I did in Porto: a client is aware of the overload or non overload of the different servers with which it has traffic, and can do an average (even weighted by the traffic it has with these servers) to infer a realm overload value that may be relevant when sending the requests with only realm destination. . This possibility should be allowed for me. I do not say it should be the only way as I am OK to have a realm OL coming from  DA that could be more accurate. 

    

    SRD> Clients do not have a full view of the network, so relying
    on clients to guess when the realm is very unlikely to ever work
    well for networks of any real complexity.  That said, clients can
    clearly do so if they want.  There is no protocol that needs to be
    defined as part of DOIC to allow this to happen so it is out of
    scope for DOIC.  

    

      
Best regards

JJacques    


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : mercredi 26 février 2014 17:06
À : ulrich.wiehe@nsn.com
Cc : dime@ietf.org
Objet : [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports

#58: Multiple Reporting Nodes for realm-routed-request type reports

 In deployments where more than one node is configured to take the role of  a reporting node for realm-routed-request reports, reacting nodes may  receive  in different answer messages different realm-routed-request type OLRs  inserted by the different reporting nodes. Although it is expected that  the different reporting nodes report more or less the same content, it  cannot be expected that reports are 100% synchronized. Especially sequence  numbers may differ.
 To allow reacting nodes correctly detect outdates/replays/freshness of  OLRs in this scenario, it is proposed that realm-routed-request type OLRs  are extended to contain the Diameter Identity of the reporting node that  inserted the realm-routed-request type OLR. (e.g. as already proposed in  draft-donovan-dime-agent-overload-01).
 Reporting nodes that insert realm-routed-request type OLRs to answer  messages MUST also insert their Diameter Identity.
 Reacting nodes MUST take the Diameter Identity received within the OLR  into account in order to detect outdates/replays/freshness.



    

    

  


--------------070007050706080109090303--


From nobody Wed Mar  5 01:56: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 BF8BE1A03A7 for ; Wed,  5 Mar 2014 01:56:04 -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 duKLS8AHQZYg for ; Wed,  5 Mar 2014 01:56:01 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D701B1A0394 for ; Wed,  5 Mar 2014 01:56:00 -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 s259tqIE012706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Mar 2014 10:55:52 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s259tpx6017259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 10:55:52 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 5 Mar 2014 10:55:50 +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; Wed, 5 Mar 2014 10:55:50 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Jouni Korhonen , ext Steve Donovan , ext Ben Campbell , "ext Askerup, Anders" , "dime@ietf.org list" 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EvEWgP4lzthw/EteSAD4lZZwkPErMq2A4lZTnEDErLODgIlZVFNQkrKjP4ClZTCjoMrJNKcAlZJPX3A=
Date: Wed, 5 Mar 2014 09:55:49 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@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> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com>
In-Reply-To: <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.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: 6365
X-purgate-ID: 151667::1394013352-00003660-F45DF80C/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/FKz3U2xHX5m6oXFzo1CowrLWtVA
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: Wed, 05 Mar 2014 09:56:05 -0000

Jouni,

I would like to see the complete picture.
There seems to be a majority in favour of the following:

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.=20

2. OC-Supported-Features in answer messages indicate all features the repor=
ting node supports (NOT all featues the reporting node and the reacting nod=
e commonly support; NOT the selected features selected by the reporting nod=
e out of the advertized features supported by the reacting node). The selec=
ted feature(s) would be somehow implicitly or explicitly part of the OC-OLR=
.

3. When receiving an answer, the reacting node, which supports only OLR_DEF=
AULT_ALGO and no other feature, can safely ignore the OC-Supported-Features=
 AVP. This may be different for reacting nodes which support other features=
 than just OLR_DEFAULT_ALGO.

Is this agreeable?
=20
In order to make progress I'm ok to agree on this, but especially on 1. my =
agreement is "although I think there is no good reason"; other people may a=
gree "because they think there is good reason". We don't need to re-discuss=
 the reason.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, March 05, 2014 9:34 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; ext Ben Campbell; e=
xt Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


So. are we OK to agree and close the issue #30 for the part that was
proposed here: http://www.ietf.org/mail-archive/web/dime/current/msg06998.h=
tml
i.e. OC-Supported-Features is in every answer message? I am not sure anymor=
e
since the discussion got exploded again to multiple directions.

Yes or yes? ;-)

If yes, we can close issue #30, document the conclusion and the changed tex=
t
snippets into the issue tracker, and then concentrate tearing apart the res=
t
of the functionality and implications based on the above decision in anothe=
r
issue and thread?

- Jouni


On Mar 4, 2014, at 2:58 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> Steve,
> I m trying to progress this.
> =20
> As you say we don't have consensus on the question  whether capability ex=
change should be kept separate from overload reports or not.
> =20
> Let's focus on this issue.
> =20
> Once this issue is resolved we will know whether
> a) OC-Supported-Features conveys the selected features and is used togeth=
er with the OLR to interprete the meaning of the OLR, or
> b) OC-Supported-Features conveys the supported features (and would be sen=
t for information, the reason being just because people decided so)
> =20
> Ulrich
> =20
> =20
> =20
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> 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
> =20
> Ulrich,
>=20
> We've already discussed this.
>=20
> I understand that you don't think that the OC-Supported-Features AVP shou=
ld be required in all answer messages.
>=20
> Others of us think that it should be.  We can't make progress if we have =
to re-debate every point multiple times.
>=20
> I suggest that we follow Jouni's guidance made a few emails back and move=
 on.
>=20
> Steve
>=20
> On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> =20
> =20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> 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
> =20
> 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 algorith=
m that the reporting node will be using. ...so that the the reactin=
g node can - based on that information - do what?
>=20
> I agree that capability exchange should be kept separate from overload re=
ports.  We don't, however, have consensus on this point.Is it only =
Jouni who wants this  dependency?
>=20
> Steve
>=20
> On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> I agree with Ben
> =20
> But then again: which purpose does OC-Supported-Features I answer serve?
> Ulrich
> =20
> -----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=
.org list
> Subject: Re: [Dime] Issue#30 status
> =20
> =20
> On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
> =20
> 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.
> =20
> IMO, OC-Supported-Features should be treated as a) in all cases. If we ne=
ed information about the specific selections made for a particular OLR, tha=
t info belongs in the OLR.
> =20
> =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).
> =20
> 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 no=
t change in a way that makes the OLR no longer valid.
> =20
> =20
> Ulrich
> =20
> =20
> =20
> =20


From nobody Wed Mar  5 01:59:09 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 5BD971A039E for ; Wed,  5 Mar 2014 01:59:07 -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 19AK3rPIaA3x for ; Wed,  5 Mar 2014 01:58:57 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id F2B501A01C2 for ; Wed,  5 Mar 2014 01:58:56 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id D13DAC03A9; Wed,  5 Mar 2014 10:58:52 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 77862384182; Wed,  5 Mar 2014 10:58:52 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Mar 2014 10:58:52 +0100
From: 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Jouni Korhonen" , ext Steve Donovan , ext Ben Campbell , "ext Askerup, Anders" , "dime@ietf.org list" 
Thread-Topic: [Dime] Issue#30 status
Thread-Index: Ac8tWQX7CYmMbh1xRs+Dq0AnmWwb3v//9tOA///eBNCACKHgAIAALzmA//25bzCABLwtgP//7WrwAAOBfgD//+2wIP//yo4A//+UCAD//XVsAP/56E0A//N6SID/4mVioP/EzBmA/4l7r8D/EvEWgP4lzthw/EteSAD4lZZwkPErMq2A4lZTnEDErLODgIlZVFNQkrKjP4ClZTCjoMrJNKcAlZJPX3CrJJArAA==
Date: Wed, 5 Mar 2014 09:58:51 +0000
Message-ID: <23578_1394013532_5316F55C_23578_8559_1_6B7134B31289DC4FAF731D844122B36E4E1854@PEXCVZYM13.corporate.adroot.infra.ftgroup>
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> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
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.4.80315
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/TPs3HMuJ9PqC1pHa_At5CYdOonU
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: Wed, 05 Mar 2014 09:59:07 -0000

ok

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: mercredi 5 mars 2014 10:56
=C0=A0: ext Jouni Korhonen; ext Steve Donovan; ext Ben Campbell; ext Askeru=
p, Anders; dime@ietf.org list
Objet=A0: Re: [Dime] Issue#30 status

Jouni,

I would like to see the complete picture.
There seems to be a majority in favour of the following:

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.=20

2. OC-Supported-Features in answer messages indicate all features the repor=
ting node supports (NOT all featues the reporting node and the reacting nod=
e commonly support; NOT the selected features selected by the reporting nod=
e out of the advertized features supported by the reacting node). The selec=
ted feature(s) would be somehow implicitly or explicitly part of the OC-OLR.

3. When receiving an answer, the reacting node, which supports only OLR_DEF=
AULT_ALGO and no other feature, can safely ignore the OC-Supported-Features=
 AVP. This may be different for reacting nodes which support other features=
 than just OLR_DEFAULT_ALGO.

Is this agreeable?
=20
In order to make progress I'm ok to agree on this, but especially on 1. my =
agreement is "although I think there is no good reason"; other people may a=
gree "because they think there is good reason". We don't need to re-discuss=
 the reason.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Wednesday, March 05, 2014 9:34 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; ext Ben Campbell; e=
xt Askerup, Anders; dime@ietf.org list
Subject: Re: [Dime] Issue#30 status


So. are we OK to agree and close the issue #30 for the part that was
proposed here: http://www.ietf.org/mail-archive/web/dime/current/msg06998.h=
tml
i.e. OC-Supported-Features is in every answer message? I am not sure anymore
since the discussion got exploded again to multiple directions.

Yes or yes? ;-)

If yes, we can close issue #30, document the conclusion and the changed text
snippets into the issue tracker, and then concentrate tearing apart the rest
of the functionality and implications based on the above decision in another
issue and thread?

- Jouni


On Mar 4, 2014, at 2:58 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:

> Steve,
> I m trying to progress this.
>=20=20
> As you say we don't have consensus on the question  whether capability ex=
change should be kept separate from overload reports or not.
>=20=20
> Let's focus on this issue.
>=20=20
> Once this issue is resolved we will know whether
> a) OC-Supported-Features conveys the selected features and is used togeth=
er with the OLR to interprete the meaning of the OLR, or
> b) OC-Supported-Features conveys the supported features (and would be sen=
t for information, the reason being just because people decided so)
>=20=20
> Ulrich
>=20=20
>=20=20
>=20=20
>=20=20
>=20=20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> 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
>=20=20
> Ulrich,
>=20
> We've already discussed this.
>=20
> I understand that you don't think that the OC-Supported-Features AVP shou=
ld be required in all answer messages.
>=20
> Others of us think that it should be.  We can't make progress if we have =
to re-debate every point multiple times.
>=20
> I suggest that we follow Jouni's guidance made a few emails back and move=
 on.
>=20
> Steve
>=20
> On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>=20=20
>=20=20
> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
> 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
>=20=20
> 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 algorith=
m that the reporting node will be using. ...so that the the reactin=
g node can - based on that information - do what?
>=20
> I agree that capability exchange should be kept separate from overload re=
ports.  We don't, however, have consensus on this point.Is it only =
Jouni who wants this  dependency?
>=20
> Steve
>=20
> On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> I agree with Ben
>=20=20
> But then again: which purpose does OC-Supported-Features I answer serve?
> Ulrich
>=20=20
> -----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=
.org list
> Subject: Re: [Dime] Issue#30 status
>=20=20
>=20=20
> On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich)  wrote:
>=20=20
> 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.
>=20=20
> IMO, OC-Supported-Features should be treated as a) in all cases. If we ne=
ed information about the specific selections made for a particular OLR, tha=
t info belongs in the OLR.
>=20=20
>=20=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).
>=20=20
> 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 no=
t change in a way that makes the OLR no longer valid.
>=20=20
>=20=20
> Ulrich
>=20=20
>=20=20
>=20=20
>=20=20

_______________________________________________
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 Wed Mar  5 02:03: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 CE5491A000D for ; Wed,  5 Mar 2014 02:03:37 -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 RPqhz-iX3WCL for ; Wed,  5 Mar 2014 02:03:35 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 690371A03AA for ; Wed,  5 Mar 2014 02:03:35 -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 s25A3D2j093646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 04:03:17 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net>
Date: Wed, 5 Mar 2014 10:03:12 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F532496-15F7-42F1-BE39-511373062016@nostrum.com>
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@usdon! ovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@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/sRQ8ODUFmliqbnqYJkiwYDbj1VA
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: Wed, 05 Mar 2014 10:03:38 -0000

On Mar 5, 2014, at 9:55 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:

> Jouni,
>=20
> I would like to see the complete picture.
> There seems to be a majority in favour of the following:
>=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

+1

>=20
> 2. OC-Supported-Features in answer messages indicate all features the =
reporting node supports (NOT all featues the reporting node and the =
reacting node commonly support; NOT the selected features selected by =
the reporting node out of the advertized features supported by the =
reacting node). The selected feature(s) would be somehow implicitly or =
explicitly part of the OC-OLR.

I've got mixed feelings on whether the OC-Supported-Features would =
represent everything the answerer supports, everything the answerer =
supports in common with the requestor, or everything the answerer =
actually might do.

I concur that any indication of what features are used in any particular =
OLR belong in the OLR. I think the question of how is orthogonal to this =
particular discussion.

>=20
> 3. When receiving an answer, the reacting node, which supports only =
OLR_DEFAULT_ALGO and no other feature, can safely ignore the =
OC-Supported-Features AVP. This may be different for reacting nodes =
which support other features than just OLR_DEFAULT_ALGO.

I'm not comfortable asserting that. At a minimum, the receiver probably =
(lower case) should not ignore the fact that the OC-Supported-Features =
AVP is present or not present. But if it really turns out to be =
irrelevant to a particular reacting node implementation, then it's =
irrelevant. But that's implementation specific.

And in general, we should not use normative language to state =
observations of fact.  Stating that you can ignore an =
OC-Supported-Features that does happens not to constrain your behavior =
sounds like an observation. It might be okay to put it in a =
parenthetical (i.e. indented) note.

>=20
> Is this agreeable?
>=20
> In order to make progress I'm ok to agree on this, but especially on =
1. my agreement is "although I think there is no good reason"; other =
people may agree "because they think there is good reason". We don't =
need to re-discuss the reason.
>=20
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Wednesday, March 05, 2014 9:34 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; ext Ben =
Campbell; ext Askerup, Anders; dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>=20
>=20
> So. are we OK to agree and close the issue #30 for the part that was
> proposed here: =
http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
> i.e. OC-Supported-Features is in every answer message? I am not sure =
anymore
> since the discussion got exploded again to multiple directions.
>=20
> Yes or yes? ;-)
>=20
> If yes, we can close issue #30, document the conclusion and the =
changed text
> snippets into the issue tracker, and then concentrate tearing apart =
the rest
> of the functionality and implications based on the above decision in =
another
> issue and thread?
>=20
> - Jouni
>=20
>=20
> On Mar 4, 2014, at 2:58 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> Steve,
>> I m trying to progress this.
>>=20
>> As you say we don't have consensus on the question  whether =
capability exchange should be kept separate from overload reports or =
not.
>>=20
>> Let's focus on this issue.
>>=20
>> 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)
>>=20
>> Ulrich
>>=20
>>=20
>>=20
>>=20
>>=20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> 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
>>=20
>> Ulrich,
>>=20
>> We've already discussed this.
>>=20
>> I understand that you don't think that the OC-Supported-Features AVP =
should be required in all answer messages.
>>=20
>> Others of us think that it should be.  We can't make progress if we =
have to re-debate every point multiple times.
>>=20
>> I suggest that we follow Jouni's guidance made a few emails back and =
move on.
>>=20
>> Steve
>>=20
>> On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>=20
>>=20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> 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
>>=20
>> 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?
>>=20
>> 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?
>>=20
>> Steve
>>=20
>> On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> I agree with Ben
>>=20
>> But then again: which purpose does OC-Supported-Features I answer =
serve?
>> Ulrich
>>=20
>> -----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.org list
>> Subject: Re: [Dime] Issue#30 status
>>=20
>>=20
>> On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>>=20
>> 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.
>>=20
>> 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
>>=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).
>>=20
>> 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
>>=20
>> Ulrich
>>=20
>>=20
>>=20
>>=20
>=20


From nobody Wed Mar  5 02:32:40 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 1257A1A03BB for ; Wed,  5 Mar 2014 02:32:39 -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 uGb_74WIgpI1 for ; Wed,  5 Mar 2014 02:32:37 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 413311A0391 for ; Wed,  5 Mar 2014 02:32:37 -0800 (PST)
Received: from dhcp-a343.meeting.ietf.org ([31.133.163.67]:49749) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WL97o-0006b9-3G; Wed, 05 Mar 2014 02:32:33 -0800
Message-ID: <5316FD3D.2040207@usdonovans.com>
Date: Wed, 05 Mar 2014 10:32:29 +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 , ext Ben Campbell ,  "ext Askerup, Anders" , "dime@ietf.org list" 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@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> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060005070802090907040809"
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/wdcHVQI4QvZWRZBggjvvE565SvU
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: Wed, 05 Mar 2014 10:32:39 -0000

This is a multi-part message in MIME format.
--------------060005070802090907040809
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Please see comments inline.

Steve

On 3/5/14 9:55 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Jouni,
>
> I would like to see the complete picture.
> There seems to be a majority in favour of the following:
>
> 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. 
SRD> Agreed.
>
> 2. OC-Supported-Features in answer messages indicate all features the reporting node supports (NOT all featues the reporting node and the reacting node commonly support; NOT the selected features selected by the reporting node out of the advertized features supported by the reacting node). The selected feature(s) would be somehow implicitly or explicitly part of the OC-OLR.
SRD> There is an advantage for the reporting node indicating which
abatement algorithm will be used if overload happens.  Assume the
reporting node supports both loss and rate, for instance, and assume
rate requires the client keep track of what has been sent prior to the
overload report to handle the overload report.

SRD> If the reporting node returns an indication that it supports both
loss and rate then the client will be forced to be prepared for a rate
report.  If the reporting node returns an indication that it will be
using loss then the client can avoid that work.
>
> 3. When receiving an answer, the reacting node, which supports only OLR_DEFAULT_ALGO and no other feature, can safely ignore the OC-Supported-Features AVP. This may be different for reacting nodes which support other features than just OLR_DEFAULT_ALGO.
SRD> I agree with this statement and I also agree with Ben that this
should be included as an indented note.
>
> Is this agreeable?
>  
> In order to make progress I'm ok to agree on this, but especially on 1. my agreement is "although I think there is no good reason"; other people may agree "because they think there is good reason". We don't need to re-discuss the reason.
>
> Ulrich
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: Wednesday, March 05, 2014 9:34 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; ext Ben Campbell; ext Askerup, Anders; dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>
>
> So. are we OK to agree and close the issue #30 for the part that was
> proposed here: http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
> i.e. OC-Supported-Features is in every answer message? I am not sure anymore
> since the discussion got exploded again to multiple directions.
>
> Yes or yes? ;-)
>
> If yes, we can close issue #30, document the conclusion and the changed text
> snippets into the issue tracker, and then concentrate tearing apart the rest
> of the functionality and implications based on the above decision in another
> issue and thread?
>
> - Jouni
>
>
>


--------------060005070802090907040809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Please see comments inline.

      

      Steve

      

    
    
On 3/5/14 9:55 AM, Wiehe, Ulrich (NSN -
      DE/Munich) wrote:

    

    

      
Jouni,

I would like to see the complete picture.
There seems to be a majority in favour of the following:

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. 

    

    SRD> Agreed.

    

      

2. OC-Supported-Features in answer messages indicate all features the reporting node supports (NOT all featues the reporting node and the reacting node commonly support; NOT the selected features selected by the reporting node out of the advertized features supported by the reacting node). The selected feature(s) would be somehow implicitly or explicitly part of the OC-OLR.

    

    SRD> There is an advantage for the reporting node indicating
    which abatement algorithm will be used if overload happens.  Assume
    the reporting node supports both loss and rate, for instance, and
    assume rate requires the client keep track of what has been sent
    prior to the overload report to handle the overload report.

    

    SRD> If the reporting node returns an indication that it supports
    both loss and rate then the client will be forced to be prepared for
    a rate report.  If the reporting node returns an indication that it
    will be using loss then the client can avoid that work.

    

      

3. When receiving an answer, the reacting node, which supports only OLR_DEFAULT_ALGO and no other feature, can safely ignore the OC-Supported-Features AVP. This may be different for reacting nodes which support other features than just OLR_DEFAULT_ALGO.

    

    SRD> I agree with this statement and I also agree with Ben that
    this should be included as an indented note.

    

      

Is this agreeable?
 
In order to make progress I'm ok to agree on this, but especially on 1. my agreement is "although I think there is no good reason"; other people may agree "because they think there is good reason". We don't need to re-discuss the reason.

Ulrich

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


So. are we OK to agree and close the issue #30 for the part that was
proposed here: http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
i.e. OC-Supported-Features is in every answer message? I am not sure anymore
since the discussion got exploded again to multiple directions.

Yes or yes? ;-)

If yes, we can close issue #30, document the conclusion and the changed text
snippets into the issue tracker, and then concentrate tearing apart the rest
of the functionality and implications based on the above decision in another
issue and thread?

- Jouni





    

    

  


--------------060005070802090907040809--


From nobody Wed Mar  5 02:37:34 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 226421A03D7 for ; Wed,  5 Mar 2014 02:37:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level: 
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] 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 4vN0Vv0FGxDJ for ; Wed,  5 Mar 2014 02:37:32 -0800 (PST)
Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id DA11E1A03B9 for ; Wed,  5 Mar 2014 02:37:31 -0800 (PST)
Received: by mail-wg0-f49.google.com with SMTP id b13so963522wgh.8 for ; Wed, 05 Mar 2014 02:37:28 -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=wznLZvzGxXpBUi0DUCnwR3CdsT9fQKeYH06zTXwR+vU=; b=SPA+xP2BTho2QKhbGf0sjOxh7LlbOxXW28yknFDgOU9vn1a+dN+zMqHeYk6J8w+znc EaxQ3eg/ft5VvXDZEcdQhHV+umbCdm3qnzSECCY3dVQAn9Dosdqwq+Lu0HMmr9ZNKgdw RHQbEvhIF7K+nrwvLu1Ihwe0jj66RyPfllBCc+L334DUcR1ETYLZ6YIv5wYqqrdjdgZb o5eYHp1/Co7n2RymfSazHYobCvgyt7HgjD/urBZLc7dmGr7qh03t88D/rbXRD8QGLhJ9 2WY3DBRwVO7h+zzQzvh99Xotgo4dSO3gPeRWyiKMayEkWfpXY/JbaWKz9At32+u30P6i M56A==
X-Received: by 10.194.174.100 with SMTP id br4mr3898548wjc.83.1394015842473; Wed, 05 Mar 2014 02:37:22 -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 dd3sm9721230wjb.9.2014.03.05.02.37.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Mar 2014 02:37:19 -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: <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net>
Date: Wed, 5 Mar 2014 10:37:17 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
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 > <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@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/iD9HJRoZy2ZRYXy9_lnJZ21yaIU
Cc: "dime@ietf.org list" , ext Ben Campbell 
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: Wed, 05 Mar 2014 10:37:34 -0000

On Mar 5, 2014, at 9:55 AM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Jouni,
>=20
> I would like to see the complete picture.
> There seems to be a majority in favour of the following:
>=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

Agree on 1). And this I want to close.

> 2. OC-Supported-Features in answer messages indicate all features the =
reporting node supports (NOT all featues the reporting node and the =
reacting node commonly support; NOT the selected features selected by =
the reporting node out of the advertized features supported by the =
reacting node). The selected feature(s) would be somehow implicitly or =
explicitly part of the OC-OLR.

This 2) I still do not agree because I want to understand the ground =
reasons and implications for behaviour implied by 2). And this I want to =
discuss separately from above 1) agreement.

> 3. When receiving an answer, the reacting node, which supports only =
OLR_DEFAULT_ALGO and no other feature, can safely ignore the =
OC-Supported-Features AVP. This may be different for reacting nodes =
which support other features than just OLR_DEFAULT_ALGO.

Agree on 3). But this is IMHO again separate from 1) decision.

- Jouni


> Is this agreeable?
>=20
> In order to make progress I'm ok to agree on this, but especially on =
1. my agreement is "although I think there is no good reason"; other =
people may agree "because they think there is good reason". We don't =
need to re-discuss the reason.
>=20
> Ulrich
>=20
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
> Sent: Wednesday, March 05, 2014 9:34 AM
> To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; ext Ben =
Campbell; ext Askerup, Anders; dime@ietf.org list
> Subject: Re: [Dime] Issue#30 status
>=20
>=20
> So. are we OK to agree and close the issue #30 for the part that was
> proposed here: =
http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
> i.e. OC-Supported-Features is in every answer message? I am not sure =
anymore
> since the discussion got exploded again to multiple directions.
>=20
> Yes or yes? ;-)
>=20
> If yes, we can close issue #30, document the conclusion and the =
changed text
> snippets into the issue tracker, and then concentrate tearing apart =
the rest
> of the functionality and implications based on the above decision in =
another
> issue and thread?
>=20
> - Jouni
>=20
>=20
> On Mar 4, 2014, at 2:58 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:
>=20
>> Steve,
>> I m trying to progress this.
>>=20
>> As you say we don't have consensus on the question  whether =
capability exchange should be kept separate from overload reports or =
not.
>>=20
>> Let's focus on this issue.
>>=20
>> 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)
>>=20
>> Ulrich
>>=20
>>=20
>>=20
>>=20
>>=20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> 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
>>=20
>> Ulrich,
>>=20
>> We've already discussed this.
>>=20
>> I understand that you don't think that the OC-Supported-Features AVP =
should be required in all answer messages.
>>=20
>> Others of us think that it should be.  We can't make progress if we =
have to re-debate every point multiple times.
>>=20
>> I suggest that we follow Jouni's guidance made a few emails back and =
move on.
>>=20
>> Steve
>>=20
>> On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>=20
>>=20
>> From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> 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
>>=20
>> 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?
>>=20
>> 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?
>>=20
>> Steve
>>=20
>> On 3/4/14 11:43 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>> I agree with Ben
>>=20
>> But then again: which purpose does OC-Supported-Features I answer =
serve?
>> Ulrich
>>=20
>> -----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.org list
>> Subject: Re: [Dime] Issue#30 status
>>=20
>>=20
>> On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) =
 wrote:
>>=20
>> 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.
>>=20
>> 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
>>=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).
>>=20
>> 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
>>=20
>> Ulrich
>>=20
>>=20
>>=20
>>=20
>=20


From nobody Wed Mar  5 02:38: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 EDF741A03B9 for ; Wed,  5 Mar 2014 02:38:41 -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 FgtU88sdiBCZ for ; Wed,  5 Mar 2014 02:38:40 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 99E4C1A03A3 for ; Wed,  5 Mar 2014 02:38:40 -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 s25AcLPu097117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 04:38:24 -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: <5316FD3D.2040207@usdonovans.com>
Date: Wed, 5 Mar 2014 10:38:20 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@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> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net> <5316FD3D.2040207@usdonovans.! com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/R4bKGX7yPBhA4ZX3c-b8ysveKqA
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: Wed, 05 Mar 2014 10:38:42 -0000

On Mar 5, 2014, at 10:32 AM, Steve Donovan  =
wrote:

>>=20
>> 2. OC-Supported-Features in answer messages indicate all features the =
reporting node supports (NOT all featues the reporting node and the =
reacting node commonly support; NOT the selected features selected by =
the reporting node out of the advertized features supported by the =
reacting node). The selected feature(s) would be somehow implicitly or =
explicitly part of the OC-OLR.
> SRD> There is an advantage for the reporting node indicating which =
abatement algorithm will be used if overload happens.  Assume the =
reporting node supports both loss and rate, for instance, and assume =
rate requires the client keep track of what has been sent prior to the =
overload report to handle the overload report.
>=20
> SRD> If the reporting node returns an indication that it supports both =
loss and rate then the client will be forced to be prepared for a rate =
report.  If the reporting node returns an indication that it will be =
using loss then the client can avoid that work.
>=20

That supports the idea of OC-Supported-Features in an answer indicating =
the algorithms that the reporting node reasonably might use with the =
particular reacting node, so that the reacting node can be prepared to =
invoke potentially stateful algorithms. OTOH, would you treat features =
that are different from algorithms the same?

Have we reached any conclusion on whether a reporting node is able to =
change algorithms?=


From nobody Wed Mar  5 02:40:29 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 6D8A51A03FA for ; Wed,  5 Mar 2014 02:40:27 -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 XuJKeuXQDC4w for ; Wed,  5 Mar 2014 02:40:26 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C10C1A03EA for ; Wed,  5 Mar 2014 02:40:26 -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 s25Ae6A3097276 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 04:40:11 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: 
Date: Wed, 5 Mar 2014 10:40:05 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AF52103-68A5-4365-85CC-F998433E572B@nostrum.com>
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@usdon! ovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net> 
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ec2i3jbKOB62y4KEnanE6_w1piw
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: Wed, 05 Mar 2014 10:40:27 -0000

On Mar 5, 2014, at 10:37 AM, Jouni Korhonen  =
wrote:

>>=20
>> 3. When receiving an answer, the reacting node, which supports only =
OLR_DEFAULT_ALGO and no other feature, can safely ignore the =
OC-Supported-Features AVP. This may be different for reacting nodes =
which support other features than just OLR_DEFAULT_ALGO.
>=20
> Agree on 3). But this is IMHO again separate from 1) decision.

I agree it is separate from the decision whether to require OC-S-F in =
each response. In fact, none of the conversations on point 1 or 2 seem =
to change that.=


From nobody Wed Mar  5 03:01:39 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 8972E1A0439 for ; Wed,  5 Mar 2014 03:01:37 -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 0CSlliBe2KSx for ; Wed,  5 Mar 2014 03:01:36 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4CE1A0431 for ; Wed,  5 Mar 2014 03:01:36 -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 s25B1IDW008293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 05:01:24 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <6AF52103-68A5-4365-85CC-F998433E572B@nostrum.com>
Date: Wed, 5 Mar 2014 11:01:18 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <390F756D-A2B2-44C9-90EC-78F7D4C660DC@nostrum.com>
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@usdon! ! ovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B559F@DEMUMBX014.nsn-intra.net> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net>  <6AF52103-68A5-4365-85CC-F998433E572B@nostrum.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/72mk4VskGuPaNnC4aKe1ytkXEpk
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: Wed, 05 Mar 2014 11:01:37 -0000

On Mar 5, 2014, at 10:40 AM, Ben Campbell  wrote:

>=20
> On Mar 5, 2014, at 10:37 AM, Jouni Korhonen  =
wrote:
>=20
>>>=20
>>> 3. When receiving an answer, the reacting node, which supports only =
OLR_DEFAULT_ALGO and no other feature, can safely ignore the =
OC-Supported-Features AVP. This may be different for reacting nodes =
which support other features than just OLR_DEFAULT_ALGO.
>>=20
>> Agree on 3). But this is IMHO again separate from 1) decision.
>=20
> I agree it is separate from the decision whether to require OC-S-F in =
each response. In fact, none of the conversations on point 1 or 2 seem =
to change that.

Oops, I mean to say conversations on points 2 or 3.


From nobody Wed Mar  5 03:10: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 96B241A046F for ; Wed,  5 Mar 2014 03:10:13 -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 6OlFbAUl9PS6 for ; Wed,  5 Mar 2014 03:10:12 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E45081A0488 for ; Wed,  5 Mar 2014 03:10:10 -0800 (PST)
Received: from dhcp-a343.meeting.ietf.org ([31.133.163.67]:50193) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WL9i7-0000le-Tt; Wed, 05 Mar 2014 03:10:06 -0800
Message-ID: <53170607.6060701@usdonovans.com>
Date: Wed, 05 Mar 2014 11:09:59 +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: Ben Campbell 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@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> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net> <5316FD3D.2040207@usdonovans.! com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
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: srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6iUsh8D7QneTOpU6w-9jJ4yJMII
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: Wed, 05 Mar 2014 11:10:13 -0000

On 3/5/14 10:38 AM, Ben Campbell wrote:
> On Mar 5, 2014, at 10:32 AM, Steve Donovan  wrote:
>
>>> 2. OC-Supported-Features in answer messages indicate all features the reporting node supports (NOT all featues the reporting node and the reacting node commonly support; NOT the selected features selected by the reporting node out of the advertized features supported by the reacting node). The selected feature(s) would be somehow implicitly or explicitly part of the OC-OLR.
>> SRD> There is an advantage for the reporting node indicating which abatement algorithm will be used if overload happens.  Assume the reporting node supports both loss and rate, for instance, and assume rate requires the client keep track of what has been sent prior to the overload report to handle the overload report.
>>
>> SRD> If the reporting node returns an indication that it supports both loss and rate then the client will be forced to be prepared for a rate report.  If the reporting node returns an indication that it will be using loss then the client can avoid that work.
>>
> That supports the idea of OC-Supported-Features in an answer indicating the algorithms that the reporting node reasonably might use with the particular reacting node, so that the reacting node can be prepared to invoke potentially stateful algorithms. OTOH, would you treat features that are different from algorithms the same?
SRD> I think it should be up to the definition of the feature to define
what the reporting node sends in response to an advertisement of that
feature.
>
> Have we reached any conclusion on whether a reporting node is able to change algorithms?
SRD> I don't think we have.  I would propose that a reporting node
cannot change algorithms during an overload occurrence.  In other words,
a report for algorithm foo cannot be sent if there is an active report
for type bar.  We should probably go as far as to say that the reacting
node should ignore an OLR that specifies an algorithm different then the
algorithm for a valid OLR.

SRD> It should also be possible for a reporting node to use the loss
algorithm for one occurrence of overload and then use rate for the next
occurrence of overload.


From nobody Wed Mar  5 06:37:59 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 318D41A021D for ; Wed,  5 Mar 2014 06:37:57 -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 hDOqaOWOZ3xA for ; Wed,  5 Mar 2014 06:37:54 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 895FC1A0197 for ; Wed,  5 Mar 2014 06:37:35 -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 s25EbRAL001141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Mar 2014 15:37:27 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s25EbQ4q027307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 15:37:27 +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; Wed, 5 Mar 2014 15:37:26 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , 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/EteSAD4lZZwkPErMq2A4lZTnEDErLODgIlZVFNQkrKjP4ClZTCjoMrJNKcAlZJPX3CrJJeEgNZJLWYArJJR9IDZJFmKIA==
Date: Wed, 5 Mar 2014 14:37:26 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B58FD@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3BCF@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> <1C20EB72-5348-4CB6-98BD-B016FCD82646@gmail.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B57F6@DEMUMBX014.nsn-intra.net> <5316FD3D.2040207@usdonovans.! com>  <53170607.6060701@usdonovans.com>
In-Reply-To: <53170607.6060701@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: 3918
X-purgate-ID: 151667::1394030247-00005322-EEC5BBC1/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RIkdEqLNlPy16v9sLbm6fMiSfSM
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: Wed, 05 Mar 2014 14:37:57 -0000

Let me try again.

We agree that we want it although we don't know what it is and how it is us=
ed.

I would like to focus first on DOIC nodes that support just OLR_DEFAULT_ALG=
O  but no other feature:

A reporting node (that supports  OLR_DEFAULT_ALGO but no other feature) whe=
n receiving are request that
a)  contains an OC-Supported-Features AVP MUST include  an OC-Supported-Fea=
ture-AVP indicating support of OLR_DEFAULT_ALGO (but not support of any oth=
er feature) in the corresponding answer;
b) contains no OC-Supported-Features MUST NOT include an OC-Supported-Featu=
res-AVP in the corresponding answer.

For a reacting node (that supports  OLR_DEFAULT_ALGO but no other feature) =
we don't have a requirement to behave differently based on the presence/abs=
ence of an OC-Supported-Features AVP received in an answer, so this AVP may=
 simply be ignored by the reacting node; (of course the reacting node may d=
o some implementation specific differentiation, but that is out of scope).


When it comes to other DOIC nodes (i.e. DOIC nodes  that are supporting at =
least one feature different from   OLR_DEFAULT_ALGO) let me propose not to =
describe those node's behaviour in draft-ietf-dime-ovli  .  We should leave=
 that to the I.D. that introduces the other feature. =20

Ulrich

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


On 3/5/14 10:38 AM, Ben Campbell wrote:
> On Mar 5, 2014, at 10:32 AM, Steve Donovan  wro=
te:
>
>>> 2. OC-Supported-Features in answer messages indicate all features the r=
eporting node supports (NOT all featues the reporting node and the reacting=
 node commonly support; NOT the selected features selected by the reporting=
 node out of the advertized features supported by the reacting node). The s=
elected feature(s) would be somehow implicitly or explicitly part of the OC=
-OLR.
>> SRD> There is an advantage for the reporting node indicating which abate=
ment algorithm will be used if overload happens.  Assume the reporting node=
 supports both loss and rate, for instance, and assume rate requires the cl=
ient keep track of what has been sent prior to the overload report to handl=
e the overload report.
>>
>> SRD> If the reporting node returns an indication that it supports both l=
oss and rate then the client will be forced to be prepared for a rate repor=
t.  If the reporting node returns an indication that it will be using loss =
then the client can avoid that work.
>>
> That supports the idea of OC-Supported-Features in an answer indicating t=
he algorithms that the reporting node reasonably might use with the particu=
lar reacting node, so that the reacting node can be prepared to invoke pote=
ntially stateful algorithms. OTOH, would you treat features that are differ=
ent from algorithms the same?
SRD> I think it should be up to the definition of the feature to define
what the reporting node sends in response to an advertisement of that
feature.
>
> Have we reached any conclusion on whether a reporting node is able to cha=
nge algorithms?
SRD> I don't think we have.  I would propose that a reporting node
cannot change algorithms during an overload occurrence.  In other words,
a report for algorithm foo cannot be sent if there is an active report
for type bar.  We should probably go as far as to say that the reacting
node should ignore an OLR that specifies an algorithm different then the
algorithm for a valid OLR.

SRD> It should also be possible for a reporting node to use the loss
algorithm for one occurrence of overload and then use rate for the next
occurrence of overload.


From nobody Wed Mar  5 08:01:04 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 B40581A01C2 for ; Wed,  5 Mar 2014 01:30:51 -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 gT4RmtJJWZKq for ; Wed,  5 Mar 2014 01:30:36 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 26D671A000D for ; Wed,  5 Mar 2014 01:30:36 -0800 (PST)
Received: from dhcp-a343.meeting.ietf.org ([31.133.163.67]:55082) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WL89i-0000Qs-28 for dime@ietf.org; Wed, 05 Mar 2014 01:30:32 -0800
Message-ID: <5316EEB5.9000100@usdonovans.com>
Date: Wed, 05 Mar 2014 09:30:29 +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: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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> <16317_1393952811_5316082B_16317_4358_1_6B7134B31289DC4FAF731D844122B36E4DF9F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070806020403070809080005"
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/DwOLesk3gLnZexZTqhJaVJj5Jpk
X-Mailman-Approved-At: Wed, 05 Mar 2014 08:01:02 -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: Wed, 05 Mar 2014 09:30:52 -0000

This is a multi-part message in MIME format.
--------------070806020403070809080005
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Hi,

Well, first, the new functionality being proposed is to allow the loss
reports to apply to a single client. 

The use of global (type 1) reports will generally be most of the time,
as it is likely that a reporting node will send the same overload level
to all clients the vast majority of the time.  And, while there will
clearly be a transition period when there are both supporting and non
supporting reacting nodes that will require special agent processing,
this will reasonably quickly stabilize into all reacting nodes
supporting DOIC. 

Changing the meaning of the loss report to be per client forces agents
into tracking overload state per client 100% of the time.  That is not
an insignificant impact.

Next, the interaction between per client and global report types is
trivially simple -- use the more specific version received.

And finally, I don't understand JJacques point about breaking the
principle of independency of the DOIC associations. 

Steve

On 3/5/14 7:35 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi
>
>  
>
> I share the Lionel's view about the added value this optimization may 
> bring  versus  the extra  costs it has.  I also feel  uncomfortable
> when we break the  principle of the independency of the DOIC
> associations. When we break it, this  has  consequences (cf my mail),
> but in the future it may have some unexpected others.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> *Envoyé :* mardi 4 mars 2014 18:07
> *À :* Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES);
> dime@ietf.org
> *Objet :* RE: [Dime] Issue#35 conclusion
>
>  
>
> 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-supporting DOIC nodes anyway. So OK, with the new type, time to
> time, you will be able to optimize a little bit.
>
> But this comes with some extra cost as you have now to manage possible
> interactions between two flavors of the same OLR.
>
>  
>
> Regards,
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 4 mars 2014 16:44
> *À :* 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 defined 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 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), 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-client" it solves the issue you highlighted.
>
>  
>
> About 3, I agree that taking into account endpoint definition, default
> value 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-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 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 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  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 rule 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 sure the story is finished., if later the 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  sending 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 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, 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 those 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 brought 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 where there are only DOIC clients, why to continue to send a
> mandatory OLR which  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 value would be (0). Views?
>
>  
>
> 4)      Regarding DOIC association, here we have an information (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 type and
> not a new AVP, have  we concluded on this .
>
>  
>
> What are your 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 need to add 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é :* jeudi 27 février 2014 21:11
> *À :* 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
> shall apply the OLR or type (0) for traffic from that client. The old
> OLR of type (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 "all 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 the 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 Bartolome
>     *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 same 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 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 regards
>
>     /MCruz
>
>      
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Wiehe,
>     Ulrich (NSN - DE/Munich)
>     *Sent:* miércoles, 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 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't think there are impacts on sequence number handling,
>     report types or 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 support the "optimization" and want to use it;
>
>     Reporting nodes that better like B) could allways send (1) unless
>     they support 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 the 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 client 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-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
>
>      
>
>     On my side,  I agree with Lionel.
>
>      
>
>     I  have not the  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 the OLR can be different  for another
>     DOIC association. The basic (or "default") principle is that each
>     DOIC association has its "own 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 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 supporting 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 fact a set of clients are considered for me
>     as a pool regarding  DOIC where only one OLR applies and where
>     throttling  applies  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 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 "collateral " effect of the
>     optimization. I would also think that, instead 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.
>
>      
>
>     Ulrich  also mentioned that for realm OLRs we may also have  a
>     different realm  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 the same reason  to have  an
>     optimization  where all clients receives  the  same realm OLR, but
>     to also see the collateral effects.
>
>      
>
>     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 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é :* mardi 25 février 2014 10:09
>     *À :* 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.org 
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>     Lionel,
>
>     The question is whether the reporting node is sending the overload
>     report per client or it is sending a global overload report that
>     applies to all clients. 
>
>     I still believe that the default behavior of a reporting node will
>     be to have a single overload reduction value for the application
>     and that that overload reduction value will apply to all clients. 
>     If this is the case then there 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 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
>
>          
>
>         What about the DOIC association? What about my assumption
>         about agent maintaining overload control state for non-DOIC
>         enabled client?
>
>         So for me, the proposal from Ulrich is a clarification on the
>         agent behavior 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 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 the way the OLR is handled by reacting
>         nodes.
>
>          
>
>         Lionel
>
>          
>
>         *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
>         Steve Donovan
>         *Envoyé :* lundi 24 février 2014 19:50
>         *À :* dime@ietf.org 
>         *Objet :* Re: [Dime] Issue#35 conclusion
>
>          
>
>         Maria Cruz,
>
>         To the degree possible we should minimize the per application
>         overload logic required.  To this end, it would be better to
>         have this as part of the 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 Origin-Host 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 mitigation 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
>             overload 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
>
>              
>
>             *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 host 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 OLR 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 reporting 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, reacting node
>             when then global reduction percentage doesn't do the job.
>
>             In addition, if the normal case is that reporting nodes
>             have a single global 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 adds
>             no value.
>
>             My proposal is the following:
>
>             - Add an optional AVP (call it something like
>             Single-Node???) to overload reports that indicate when an
>             overload report applies to a specific reacting node.
>
>             - Absence of the AVP indicates that the report applies to
>             all reacting nodes (clients and agents acting on behalf of
>             non-DOIC clients).
>
>             - Reporting nodes should only include the Single-Node AVP
>             if the overload report 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 that when making
>             throttling decisions, the agent does not differentiate
>             which non supporting client originated the request.
>
>             - DOIC-supporting agents receiving an OLR with the
>             Single-Node AVP for a transaction 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 the -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:
>
>                 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 client 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 always put this AVP in every answer, even if the OLR is the same for all the clients.
>
>                  
>
>                 Regards,
>
>                  
>
>                 Lionel
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
>
>                 Envoyé : lundi 24 février 2014 14:27
>
>                 À : 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 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 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 from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction 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 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.
>
>                  
>
>                 Best regards
>
>                 Ulrich
>
>                  
>
>                 -----Original Message-----
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
>
>                 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 which 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 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."
>
>                  
>
>                 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-JACQUES (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" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 
>
>                 Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .
>
>                  
>
>                 For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.
>
>                  
>
>                 Best regards
>
>                  
>
>                 Jacques 
>
>                  
>
>                    
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : 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 server answer shall be marked:
>
>                  
>
>                 a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.
>
>                 Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.
>
>                 But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.
>
>                 Then, this is why the proposal is to add following clarification about agent 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 which 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 Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following 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 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-Host" in the request) from which traffic reduction shall apply.
>
>                 With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.
>
>                  
>
>                 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 agents 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 request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting 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 transaction.  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 for 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 that are specific to just the Origin-Host in the request.  Absence of the "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.
>
>                 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 want to differentiate, and therefore allow agents not to do the binding to the client.     
>
>                  
>
>                 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 for 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 which corresponds to the answer containing the OLR. 
>
>                  
>
>                 This would cover not only the case where an agent takes the role of the 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.
>
>                  
>
>                 b) There is no binding of the OLR to the orig-host of the client Here I disagree. 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.
>
>                  
>
>                 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 client not supporting DOIC, this agent needs to bind the received OLR to the origin-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 whether it's the client or an agent on the path that takes the role of the reacting node  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.
>
>                  the binding is always there, regardless of DOIC support at the client
>
>                  
>
>                  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 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 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
>
>          
>
>         _________________________________________________________________________________________________________________________
>
>          
>
>         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


--------------070806020403070809080005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

      

      Well, first, the new functionality being proposed is to allow the
      loss reports to apply to a single client.  

      

      The use of global (type 1) reports will generally be most of the
      time, as it is likely that a reporting node will send the same
      overload level to all clients the vast majority of the time.  And,
      while there will clearly be a transition period when there are
      both supporting and non supporting reacting nodes that will
      require special agent processing, this will reasonably quickly
      stabilize into all reacting nodes supporting DOIC.  

      

      Changing the meaning of the loss report to be per client forces
      agents into tracking overload state per client 100% of the time. 
      That is not an insignificant impact.

      

      Next, the interaction between per client and global report types
      is trivially simple -- use the more specific version received.

      

      And finally, I don't understand JJacques point about breaking the
      principle of independency of the DOIC associations.  

      

      Steve

      

    
    
On 3/5/14 7:35 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi

        
 

        
I
            share the Lionel’s view about the added value this
            optimization may  bring  versus  the extra  costs it has.  I
            also feel  uncomfortable when we break the  principle of the
            independency of the DOIC associations. When we break it,
            this  has  consequences (cf my mail), but in the future it
            may have some unexpected others.
            

        
 

        
Best regards

        
 

        
JJacques
            

        
 

        
 

        

          

            
De : lionel.morand@orange.com
                [mailto:lionel.morand@orange.com]
                

                Envoyé : mardi 4 mars 2014 18:07

                À : Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES); dime@ietf.org

                Objet : RE: [Dime] Issue#35 conclusion

          

        

        
 

        
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-supporting DOIC nodes anyway. So OK, with the
            new type, time to time, you will be able to optimize a
            little bit.

        
But
            this comes with some extra cost as you have now to manage
            possible interactions between two flavors of the same OLR.

        
 

        
Regards,

        
 

        
Lionel

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : mardi 4 mars 2014 16:44

                À : 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 defined 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 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), 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-client” it solves the issue you
            highlighted.

        
 

        
About
            3, I agree that taking into account endpoint definition,
            default value 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-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 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 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  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 rule 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 sure
            the story is finished., if later the 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  sending
            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
            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, 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 those 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 brought 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
            where there are only DOIC clients, why to continue to send a
            mandatory OLR which  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 value would be (0). Views?

        
 

        

          4)     
              Regarding
            DOIC association, here we have an information (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 type and
            not a new AVP, have  we concluded on this .
            

        
 

        
What
            are your 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 need to
            add 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é : jeudi 27 février 2014 21:11

                À : 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 shall apply the OLR or type (0) for traffic
          from that client. The old OLR of type (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 "all 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 the 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 Bartolome

                  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 same 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 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
              regards

          
/MCruz

          
 

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

                  Sent: miércoles, 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 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’t think there are impacts on sequence number handling,
              report types or 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 support the “optimization” and want to use it;

          
Reporting
              nodes that better like B) could allways send (1) unless
              they support 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 the 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 client 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-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

          
 

          
On
              my side,  I agree with Lionel.

          
 

          
I
               have not the  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 the OLR can be
              different  for another DOIC association. The basic (or
              “default”) principle is that each DOIC association has its
              “own 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 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
              supporting 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 fact a set of clients
              are considered for me as a pool regarding  DOIC where only
              one OLR applies and where throttling  applies  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 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 “collateral “
              effect of the optimization. I would also think that,
              instead 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.

          
 

          
Ulrich
               also mentioned that for realm OLRs we may also have  a
              different realm  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
              the same reason  to have  an optimization  where all
              clients receives  the  same realm OLR, but to also see the
              collateral effects.
            

          
 

          
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 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é : mardi 25 février 2014 10:09

                  À : 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.org

                  Subject: Re: [Dime] Issue#35 conclusion

            

          

          
 

          
Lionel,

            

            The question is whether the reporting node is sending the
            overload report per client or it is sending a global
            overload report that applies to all clients. 
            

            

            I still believe that the default behavior of a reporting
            node will be to have a single overload reduction value for
            the application and that that overload reduction value will
            apply to all clients.  If this is the case then there 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 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

            
 

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

            
So
                for me, the proposal from Ulrich is a clarification on
                the agent behavior 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 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 the way the OLR is handled by
                reacting nodes.

            
 

            
Lionel

            
 

            

              

                
De : DiME [mailto:dime-bounces@ietf.org]
                    De la part de Steve Donovan

                    Envoyé : lundi 24 février 2014 19:50

                    À : dime@ietf.org

                    Objet : Re: [Dime] Issue#35 conclusion

              

            

            
 

            
Maria
              Cruz,

              

              To the degree possible we should minimize the per
              application overload logic required.  To this end, it
              would be better to have this as part of the 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 Origin-Host 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 mitigation 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 overload 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

              
 

              

                

                  
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 host 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 OLR 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 reporting 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,
                reacting node when then global reduction percentage
                doesn't do the job.

                

                In addition, if the normal case is that reporting nodes
                have a single global 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
                adds no value.

                

                My proposal is the following:

                

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

                

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

                

                - Reporting nodes should only include the Single-Node
                AVP if the overload report 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 that when making
                throttling decisions, the agent does not differentiate
                which non supporting client originated the request.

                

                - DOIC-supporting agents receiving an OLR with the
                Single-Node AVP for a transaction 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 the -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:

              

              

                
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 client 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 always put this AVP in every answer, even if the OLR is the same for all the clients.

                
 

                
Regards,

                
 

                
Lionel

                
 

                
-----Message d'origine-----

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome

                
Envoyé : lundi 24 février 2014 14:27

                
À : 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 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 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 from servers S1 and S2 (e.g. S1 requesting 10% reduction from C1 and 20% reduction 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 requesting 20% reduction of traffic from C1 to R, and to C2 requesting 30% reduction of traffic from C2 to R.

                
 

                
Best regards

                
Ulrich

                
 

                
-----Original Message-----

                
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome

                
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 which 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 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."

                
 

                
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-JACQUES (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" node which wants to indicate a realm OLR to clients, and for which will use various (non standardized ) ways to determine among which it can reuse the Host-OLR AVPs received from various servers. But in this case, clients receiving realm OLRs are supporting DOIC. 

                
Here I understand the on going  discussion is about the DA behavior when  clients is not supporting DOIC and to reuse the Host-OLR received for one client for other clients  .

                
 

                
For me I remain on  my previous mail, with a baseline solution. We may always study new extensions, optimizations, but priority should be on the baseline.

                
 

                
Best regards

                
 

                
Jacques 

                
 

                
   

                
 

                
-----Message d'origine-----

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome Envoyé : lundi 24 février 2014 13:21 À : 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 server answer shall be marked:

                
 

                
a) OLR does not need to include anything else Receiver of the answer (and OLR) is the client that sends the request, identified by "Origin-Host" in the request.

                
Then, as long as the reacting node=="Origin-Host", the expected reduction is performed and requirement fulfilled.

                
But, when an agent is acting on behalf of a client as the reacting node, then the "Origin-Host" identifies final client, but not the reacting node.

                
Then, this is why the proposal is to add following clarification about agent 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 which 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 Realm? E.g. C1 and C2 accesses RealmX (S1 + S2) via Agent1. Let's consider following 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 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-Host" in the request) from which traffic reduction shall apply.

                
With this new AVP, reacting node will easy be able to identify when OLR shall be applied to any client or just to the Origin-Host identified by new AVP.

                
 

                
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 agents 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 request must be the reacting node for that non-supporting client.  Subsequent DOIC supporting agents must not be the reacting node for the non-supporting client.

                
<Ulrich>I fully agree</Ulrich>

                
 

                
 

                
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 transaction.  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.

                
<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>

                
 

                
My 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.

                
<Ulrich> I agree </Ulrich>

                
To this end I suggest we add an indication in the OLR marking the reports that are specific to just the Origin-Host in the request.  Absence of the "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.

                
<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 want to differentiate, and therefore allow agents not to do the binding to the client.</Ulrich>     

                
 

                
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 for 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 which corresponds to the answer containing the OLR. 

                
 

                
This would cover not only the case where an agent takes the role of the 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.

                
 

                
b) There is no binding of the OLR to the orig-host of the client Here I disagree. 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.

                
 

                
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) <ulrich.wiehe@nsn.com> 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 client not supporting DOIC, this agent needs to bind the received OLR to the origin-host of the client.

                
 

                
I do not agree.

                
 

                
You proposal implies that the server's OLR only applies to that client.

                
<Ulrich>exactly, that was the intention</Ulrich>  If there's an intervening DOIC agent, then the agent, not the client, is the reacting node from the server's perspective.

                
<Ulrich> the server's perspective is agnostic. The server does not know whether it's the client or an agent on the path that takes the role of the reacting node</Ulrich>  But, short of adding an origin-host type, nothing binds the OLR to a particular client, regardless of DOIC support at the clients.

                
<Ulrich> the binding is always there, regardless of DOIC support at the client</Ulrich>

                
 

                
 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 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 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

            

            
 

            
_________________________________________________________________________________________________________________________

            
 

            
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


    

    

  


--------------070806020403070809080005--


From nobody Wed Mar  5 08:03:14 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 AD9781A0175 for ; Wed,  5 Mar 2014 08:03:12 -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 5sIrdfdkFjlO for ; Wed,  5 Mar 2014 08:03:11 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F161A0119 for ; Wed,  5 Mar 2014 08:03:11 -0800 (PST)
Received: from [10.0.1.2] ([130.129.111.162]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s25G2GFj032911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 5 Mar 2014 10:02:19 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [130.129.111.162] claimed to be [10.0.1.2]
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: <29386_1394012246_5316F056_29386_11289_1_6B7134B31289DC4FAF731D844122B36E4E172C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Date: Wed, 5 Mar 2014 16:02:16 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <062.600cb97f5aa115891e91baed3f682f01@trac.tools.ietf.org>  <29386_1394012246_5316F056_29386_11289_1_6B7134B31289DC4FAF731D844122B36E4E172C@PEXCVZYM13.corporate.adroot.infra.ftgroup>
To: lionel.morand@orange.com
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iXwuB94fy1pCkZ62FJqVn1W_0MI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #58 (draft-docdt-dime-ovli): Multiple Reporting Nodes for realm-routed-request type reports
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: Wed, 05 Mar 2014 16:03:12 -0000

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

> The response to this issue is simple: no realm indication if you =
cannot ensure that this info is valid for the entire realm.
> Anything else is out of scope.

+1. I don't think we care _how_, and don't need to specify it. If we =
decide we need to in the future, it can be a separate effort.=


From nobody Wed Mar  5 08:10: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 CFAE61A075F for ; Wed,  5 Mar 2014 08:08:56 -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 6pWPh-H6SLI9 for ; Wed,  5 Mar 2014 08:08:36 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 021881A06E5 for ; Wed,  5 Mar 2014 08:08:34 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 3F2A93246BA; Wed,  5 Mar 2014 17:08:30 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 1950327C0AD; Wed,  5 Mar 2014 17:08:30 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 5 Mar 2014 17:08:29 +0100
From: 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: AQHPOFWMkE6lHJqaEUSwRUSn1ZjUW5rSqO1A
Date: Wed, 5 Mar 2014 16:08:28 +0000
Message-ID: <27215_1394035710_53174BFE_27215_11359_1_6B7134B31289DC4FAF731D844122B36E4E3D89@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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> <16317_1393952811_5316082B_16317_4358_1_6B7134B31289DC4FAF731D844122B36E4DF9F3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5316EEB5.9000100@usdonovans.com>
In-Reply-To: <5316EEB5.9000100@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4E3D89PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.4.111816
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/nAOBeF-J_NrlGI81yRRT2kFgx3M
X-Mailman-Approved-At: Wed, 05 Mar 2014 08:10:11 -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: Wed, 05 Mar 2014 16:08:57 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4E3D89PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Clarification: I'm not changing the meaning from global OLR to per client O=
LR.
I'm just saying that we can live without in the base solution. The reportin=
g node is sending an OLR in response to the request. End of story.

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 5 mars 2014 10:30
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Hi,

Well, first, the new functionality being proposed is to allow the loss repo=
rts to apply to a single client.

The use of global (type 1) reports will generally be most of the time, as i=
t is likely that a reporting node will send the same overload level to all =
clients the vast majority of the time.  And, while there will clearly be a =
transition period when there are both supporting and non supporting reactin=
g nodes that will require special agent processing, this will reasonably qu=
ickly stabilize into all reacting nodes supporting DOIC.

Changing the meaning of the loss report to be per client forces agents into=
 tracking overload state per client 100% of the time.  That is not an insig=
nificant impact.

Next, the interaction between per client and global report types is trivial=
ly simple -- use the more specific version received.

And finally, I don't understand JJacques point about breaking the principle=
 of independency of the DOIC associations.

Steve
On 3/5/14 7:35 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi

I share the Lionel's view about the added value this optimization may  brin=
g  versus  the extra  costs it has.  I also feel  uncomfortable when we bre=
ak the  principle of the independency of the DOIC associations. When we bre=
ak it, this  has  consequences (cf my mail), but in the future it may have =
some unexpected others.

Best regards

JJacques


De : lionel.morand@orange.com [mailto:lion=
el.morand@orange.com]
Envoy=E9 : mardi 4 mars 2014 18:07
=C0 : Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf=
.org
Objet : RE: [Dime] Issue#35 conclusion

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.




_______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4E3D89PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Clarificat=
ion: I'm not changing the meaning from global OLR to per client OLR.


I'm just s=
aying that we can live without in the base solution. The reporting node is =
sending an OLR in response to the request. End of story.<=
/p>

 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 5 mars 2014 10:30

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Hi,



Well, first, the new functionality being proposed is to allow the loss repo=
rts to apply to a single client. 




The use of global (type 1) reports will generally be most of the time, as i=
t is likely that a reporting node will send the same overload level to all =
clients the vast majority of the time.  And, while there will clearly =
be a transition period when there are
 both supporting and non supporting reacting nodes that will require specia=
l agent processing, this will reasonably quickly stabilize into all reactin=
g nodes supporting DOIC. 




Changing the meaning of the loss report to be per client forces agents into=
 tracking overload state per client 100% of the time.  That is not an =
insignificant impact.



Next, the interaction between per client and global report types is trivial=
ly simple -- use the more specific version received.



And finally, I don't understand JJacques point about breaking the principle=
 of independency of the DOIC associations. 




Steve




On 3/5/14 7:35 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQU=
ES) wrote:






Hi


 <=
/p>

I share the Lionel’=
s view about the added value this optimization may  bring  versus=
  the extra  costs it has.  I also feel  uncomfortable =
when we break the 
 principle of the independency of the DOIC associations. When we break it, =
this  has  consequences (cf my mail), but in the future it may ha=
ve some unexpected others.



 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De :=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Envoy=E9 : mardi 4 mars 2014 18:07

=C0 : Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES=
); 
dime@ietf.org

Objet : RE: [Dime] Issue#35 conclusion






 


Hi,


 <=
/p>

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 w=
ill have to expect to store OLR for specific non-supporting DOIC nodes anyw=
ay. So OK, with the new type, time to time, you will be
 able to optimize a little bit.


But this comes with some =
extra cost as you have now to manage possible interactions between two flav=
ors of the same OLR.


 <=
/p>

Regards,


 <=
/p>

Lionel<=
/p>

 <=
/p>





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,


 <=
/p>

Interesting analysis.


 <=
/p>

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


“The se=
quence 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<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto: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<=
o:p>


 <=
/p>


1)     
Besides the commented  point 3, I have a similar comment for p=
oint 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 cl=
ient (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 soon after  it
 will receive  a new OLR type (0) with 90% but this rule is something =
creating transient  traffic  bursts in an overload situation whic=
h 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 sure the st=
ory is finished., if later the 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  sending 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 client as there is no more specificity



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


-      =
   
the other way is first  to use a OLR type(0) with short validi=
ty 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 OL=
R type (1) exist for other clients, the OLR type(1) applies to this client.=
   



 <=
/p>

 



2)     
A clarification if 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)     
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 which  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 Ho=
st OLR is  per client, default value would be (0).
 Views?


 <=
/p>


4)     
Regarding DOIC association, here we have an information (OLR with t=
ype (1)  exchanged inside  a DOIC association that applies
 to many DOIC associations.  It is possible but it should be highlight=
ed . 



 <=
/p>


5)     
I also saw Mcruz had a preferencee for another OLR type and not a n=
ew AVP, have  we concluded 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>


 <=
/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, 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 cli=
ent 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 client” the base solution and “OLR for al=
l clients” the optimization or



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


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<=
/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 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<=
/p>

 <=
/p>





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;


R=
egards,


&=
nbsp;


L=
ionel


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces=
@ietf.org] De la part de Maria Cruz Bartolome


E=
nvoy=E9 : lundi 24 f=E9vrier 2014 14:27


=
=C0 : dime@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] 


S=
ent: 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)


S=
ent: 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;


B=
est regards


&=
nbsp;


J=
acques 


&=
nbsp;


&=
nbsp;  


&=
nbsp;


-=
----Message d'origine-----


D=
e : 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


&=
nbsp;


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)

S=
ent: 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;


_=
______________________________________________


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;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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;




 


 


_=
______________________________________________


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;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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




 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.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_6B7134B31289DC4FAF731D844122B36E4E3D89PEXCVZYM13corpora_--


From nobody Wed Mar  5 08:16: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 EAD351A00E9 for ; Wed,  5 Mar 2014 08:16:51 -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 D7GNIixw6ZB0 for ; Wed,  5 Mar 2014 08:16:48 -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 38A4E1A058E for ; Wed,  5 Mar 2014 08:16:45 -0800 (PST)
Received: from localhost ([127.0.0.1]:54047 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLEUF-0000dk-3i; Wed, 05 Mar 2014 17:16:03 +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: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com
X-Trac-Project: dime
Date: Wed, 05 Mar 2014 16:16:03 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/dime/trac/ticket/47#comment:1
Message-ID: <072.82736bd71d83e4092bce9f231bd9c45e@trac.tools.ietf.org>
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 47
In-Reply-To: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Nr8LZ_2DKoFYCHsxfdr7YaEaNCo
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #47 (draft-docdt-dime-ovli): reduction percentages greater than 100 should be ignored
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: Wed, 05 Mar 2014 16:16:52 -0000

#47: reduction percentages greater than 100 should be ignored

Changes (by ben@nostrum.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Conclusion: Invalid Reduction-Percentage values are ignored. The section
 4.7 language should say:

 "[Reduction-Percentage] Values greater than 100 are ignored."

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Wed Mar  5 12:17:14 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 E605D1A0240 for ; Wed,  5 Mar 2014 12:17:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, 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 E6ufGX8nAmXs for ; Wed,  5 Mar 2014 12:16:56 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7E91A04F6 for ; Wed,  5 Mar 2014 12:16:55 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s25KGnkj009931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Mar 2014 14:16:50 -0600 (CST)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s25KGndK007687 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 21:16:49 +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; Wed, 5 Mar 2014 21:16:49 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0CACoSUgP//gt7Q//688FA=
Date: Wed, 5 Mar 2014 20:16:48 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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>  <5316EDEB.9080606@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.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266DE45FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/DCyl9y0i3qycPEA2ofOeTnvTseU
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: Wed, 05 Mar 2014 20:17:10 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266DE45FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Steve and all
See my comments in line
Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 5 mars 2014 10:27
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

JJacques,

See my comments inline.

Steve
On 3/4/14 1:34 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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.
SRD> It doesn't need to be this complex.  The rule should be that when a re=
porting node starts to use a per client report for an individual client the=
n the reporting node must continue to use per client reports for the durati=
on of the occurrence of overload.  This removes any confusion about what th=
e reacting node should do. Then for ypur suggestion,

JJacques > I started from the assumption OLR applying to "all nodes", in fa=
ct the rule should  be to "all nodes" except those having an  OLR of type (=
0) active.  Then we can effectively use the rule you mentionned:  "when a r=
eporting node starts to use a per client report for an individual client th=
en the reporting node must continue to use per client reports for the durat=
ion of the occurrence of overload". So the introduction of the AVP generate=
s two rules .


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?
SRD> I guess I don't understand.  The type 1 report will have a sequence nu=
mber.  Each type 0 report will have its own sequence number.  As long as th=
ose follow the defined behavior for sequence numbers then there should be n=
o issue.

JJacques> my point is to clarify if we have a  seq number per DOIC associat=
ion, or one seq number common to all nodes, according the single or all nod=
e AVP value(except nodes with a type (0) active). It also  has  an impact o=
n the expiry timer  that  will have the same value  for all nodes (except n=
odes with a type (0) active). To note this may create simultaneous traffic =
bursts at timer expiration.  If decision to introduce all node case, it wou=
ld ay require clarification text.


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?
SRD> Again, I don't understand.  What mandatory OLR?  An OLR is only sent w=
hen the reacting node is actually in an overload state.  It will send no OL=
R when it is no longer overloaded.

JJacques> sorry for the wording error, I was addressing  the new AVP (singl=
e, All node) in the OLR, please replace "OLR" by "new AVP in the OLR". This=
 new AVP was described  as mandatory in the proposal, so raising my comment



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 .
SRD> What is the issue?
JJacques> I do not say that the All node approach does not work, I only dra=
w some consequences. On point 4 the principle to have independent DOIC asso=
ciations was for me a good principle. With the all node introduction, we ha=
ve some common handling to all DOIC associations  (except those with a type=
 (0) active OLR), atshould 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 .
SRD> I don't have a strong preference but adding a scope or type AVP to the=
 OLR AVP seems to work.

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
SRD> I don't see this as an optimization.  Adding per client reports is a n=
ew feature.
JJacques> If we do not introduce the new AVP, the solution works. Then by i=
ntroducing  this new AVP it allows the DA acting on behalf of all the non s=
upporting DOIC clients, to have a more simple processing in the DA by doing=
 a  global  throttling applied to all the requests of these nodes. So  this=
 is an optimization of the solution without the new AVP and is optional.

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



_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_E194C2E18676714DACA9C3A2516265D20266DE45FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











 


Hi Steve and all


See my comments in line


Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 5 mars 2014 10:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


JJacques,



See my comments inline.



Steve




On 3/4/14 1:34 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQU=
ES) wrote:






Hi all<=
/p>

 <=
/p>

Hereafter several points =
 about some collateral consequences of the Ticket #35 proposal<=
o:p>


 <=
/p>


1)     
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.   





SRD> It doesn't need to be this complex.  Th=
e rule should be that when a reporting node starts to use a per client repo=
rt for an individual client then the reporting node must continue to use pe=
r client reports for the duration of the occurrence
 of overload.  This removes any confusion about what the reacting node=
 should do. Then for ypur suggestion,



 


JJacques
> I started from the assumption OLR appl=
ying to “all nodes”, in fact the rule should  be to “=
;all nodes” except those having an  OLR of type (0) active. =
; Then we can effectively
 use the rule you mentionned:  =
;“when a reporting node starts to use a per client report for an indi=
vidual client then the reporting node must continue to use per client repor=
ts for the duration of the occurrence of overload”.
So the introduction of the AVP generates tw=
o rules .



 



2)     
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?


SRD> I guess I don't understand.  The type 1=
 report will have a sequence number.  Each type 0 report will have its=
 own sequence number.  As long as those follow the defined behavior fo=
r sequence numbers then there should be no issue.


 <=
/p>

JJacques> my point =
is to clarify if we have a  seq number per DOIC association, or one se=
q number common to all nodes, according the single or all node AVP
 value(except nodes with a type (0) active). It also  has  an imp=
act on the expiry timer  that  will have the same value  for=
 all nodes (except nodes with a type (0) active). To note this may create s=
imultaneous traffic bursts at timer expiration.  If decision
 to introduce all node case, it would ay require clarification text.


 <=
/p>


3)     
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?


SRD> Again, I don't understand.  What mandat=
ory OLR?  An OLR is only sent when the reacting node is actually in an=
 overload state.  It will send no OLR when it is no longer overloaded.=
 




JJacques> sorry for the wording error, I w=
as addressing  the new AVP (single, All node) in the OLR, please repla=
ce “OLR” by “new AVP in the OLR”. This new AVP was =
described  as
 mandatory in the proposal, so raising my comment


 


 <=
/p>


4)     
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 . 


SRD> What is the issue?


JJacques> I do not =
say that the All node approach does not work, I only draw some consequences=
. On point 4 the principle to have independent DOIC associations
 was for me a good principle. With the all node introduction, we have some =
common handling to all DOIC associations  (except those with a type (0=
) active OLR), atshould be highlighted.


 <=
/p>

 



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



SRD> I don't have =
a strong preference but adding a scope or type AVP to the OLR AVP seems to =
work.


 <=
/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



SRD> I don't see this as an optimization.  A=
dding per client reports is a new feature.


JJacques> If we do =
not introduce the new AVP, the solution works. Then by introducing  th=
is new AVP it allows the DA acting on behalf of all the non supporting
 DOIC clients, to have a more simple processing in the DA by doing a  =
global  throttling applied to all the requests of these nodes. So &nbs=
p;this is an optimization of the solution without the new AVP and is option=
al.


 <=
/p>

Best regards<=
/span>


 =



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


 










_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 






--_000_E194C2E18676714DACA9C3A2516265D20266DE45FR712WXCHMBA12z_--


From nobody Wed Mar  5 12:24:56 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 521791A024C for ; Wed,  5 Mar 2014 12:10:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, 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 VKDXbgaX2dgO for ; Wed,  5 Mar 2014 12:09:58 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0F07C1A02DB for ; Wed,  5 Mar 2014 12:09:58 -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 s25K9p08004276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 5 Mar 2014 14:09:53 -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 s25K9p7f005241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 5 Mar 2014 21:09:51 +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; Wed, 5 Mar 2014 21:09:51 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0CACoSUgP//gt7Q
Date: Wed, 5 Mar 2014 20:09:50 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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>  <5316EDEB.9080606@usdonovans.com>
In-Reply-To: <5316EDEB.9080606@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.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266DE20FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5KB4CCLi5oyiaUfsvdycuakEGx8
X-Mailman-Approved-At: Wed, 05 Mar 2014 12:24:53 -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: Wed, 05 Mar 2014 20:10:22 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266DE20FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve and all
See my comments in line
Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 5 mars 2014 10:27
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

JJacques,

See my comments inline.

Steve
On 3/4/14 1:34 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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.
SRD> It doesn't need to be this complex.  The rule should be that when a re=
porting node starts to use a per client report for an individual client the=
n the reporting node must continue to use per client reports for the durati=
on of the occurrence of overload.  This removes any confusion about what th=
e reacting node should do. Then for ypur suggestion,

JJacques > I started from the assumption OLR applying to "all nodes", in fa=
ct the rule should  be to "all nodes" except those having an  OLR of type (=
0) active.  Then we can effectively use the rule you mentionned:  "when a r=
eporting node starts to use a per client report for an individual client th=
en the reporting node must continue to use per client reports for the durat=
ion of the occurrence of overload". So the introduction of the AVP generate=
s two rules .



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?
SRD> I guess I don't understand.  The type 1 report will have a sequence nu=
mber.  Each type 0 report will have its own sequence number.  As long as th=
ose follow the defined behavior for sequence numbers then there should be n=
o issue.

JJacques> my point is to clarify if we have a  seq number per DOIC associat=
ion, or one seq number common to all nodes, according the single or all nod=
e AVP value(except nodes with a type (0) active). It also  has  an impact o=
n the expiry timer  that  will have the same value  for all nodes (except n=
odes with a type (0) active). To note this may create simultaneous traffic =
bursts at timer expiration.  If decision to introduce all node case, it wou=
ld ay require clarification text.


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?
SRD> Again, I don't understand.  What mandatory OLR?  An OLR is only sent w=
hen the reacting node is actually in an overload state.  It will send no OL=
R when it is no longer overloaded.

JJacques> sorry for the wording error, I was addressing  the new AVP (singl=
e, All node) in the OLR, please replace "OLR" by "new AVP in the OLR". This=
 new AVP was described  as mandatory in the proposal, so raising my comment



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 .
SRD> What is the issue?
JJacques> I do not say that the All node approach does not work, I only dra=
w some consequences. On point 4 the principle to have independent DOIC asso=
ciations was for me a good principle. With the all node introduction, we ha=
ve some common handling to all DOIC associations  (except those with a type=
 (0) active OLR), atshould 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 .
SRD> I don't have a strong preference but adding a scope or type AVP to the=
 OLR AVP seems to work.


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
SRD> I don't see this as an optimization.  Adding per client reports is a n=
ew feature.
JJacques> If we do not introduce the new AVP, the solution works. Then by i=
ntroducing  this new AVP it allows the DA acting on behalf of all the non s=
upporting DOIC clients, to have a more simple processing in the DA by doing=
 a  global  throttling applied to all the requests of these nodes. So  this=
 is an optimization of the solution without the new AVP and is optional.

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





_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_E194C2E18676714DACA9C3A2516265D20266DE20FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve and all


See my comments in line


Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 5 mars 2014 10:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


JJacques,



See my comments inline.



Steve




On 3/4/14 1:34 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQU=
ES) wrote:






Hi all<=
/p>

 <=
/p>

Hereafter several points =
 about some collateral consequences of the Ticket #35 proposal<=
o:p>


 <=
/p>


1)     
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.   





SRD> It doesn't need to be this complex.  Th=
e rule should be that when a reporting node starts to use a per client repo=
rt for an individual client then the reporting node must continue to use pe=
r client reports for the duration of the occurrence
 of overload.  This removes any confusion about what the reacting node=
 should do. Then for ypur suggestion,



 


JJacques
> I started from the assumption OLR appl=
ying to “all nodes”, in fact the rule should  be to “=
;all nodes” except those having an  OLR of type (0) active. =
; Then we can effectively
 use the rule you mentionned:  =
;“when a reporting node starts to use a per client report for an indi=
vidual client then the reporting node must continue to use per client repor=
ts for the duration of the occurrence of overload”.
So the introduction of the AVP generates tw=
o rules .







 



2)     
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?


SRD> I guess I don't understand.  The type 1=
 report will have a sequence number.  Each type 0 report will have its=
 own sequence number.  As long as those follow the defined behavior fo=
r sequence numbers then there should be no issue.


 <=
/p>

JJacques> my point =
is to clarify if we have a  seq number per DOIC association, or one se=
q number common to all nodes, according the single or all node AVP
 value(except nodes with a type (0) active). It also  has  an imp=
act on the expiry timer  that  will have the same value  for=
 all nodes (except nodes with a type (0) active). To note this may create s=
imultaneous traffic bursts at timer expiration.  If decision
 to introduce all node case, it would ay require clarification text.


 <=
/p>


3)     
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?


SRD> Again, I don't understand.  What mandat=
ory OLR?  An OLR is only sent when the reacting node is actually in an=
 overload state.  It will send no OLR when it is no longer overloaded.=
 




JJacques> sorry for the wording error, I w=
as addressing  the new AVP (single, All node) in the OLR, please repla=
ce “OLR” by “new AVP in the OLR”. This new AVP was =
described  as
 mandatory in the proposal, so raising my comment


 


 <=
/p>


4)     
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 . 


SRD> What is the issue?


JJacques> I do not =
say that the All node approach does not work, I only draw some consequences=
. On point 4 the principle to have independent DOIC associations
 was for me a good principle. With the all node introduction, we have some =
common handling to all DOIC associations  (except those with a type (0=
) active OLR), atshould be highlighted.


 <=
/p>

 



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



SRD> I don't have a strong preference but adding =
a scope or type AVP to the OLR AVP seems to work.






 <=
/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



SRD> I don't see this as an optimization.  A=
dding per client reports is a new feature.


JJacques> If we do =
not introduce the new AVP, the solution works. Then by introducing  th=
is new AVP it allows the DA acting on behalf of all the non supporting
 DOIC clients, to have a more simple processing in the DA by doing a  =
global  throttling applied to all the requests of these nodes. So &nbs=
p;this is an optimization of the solution without the new AVP and is option=
al.


 <=
/p>

Best regards<=
/span>


 =



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-----


De : DiME [mailto:dime-bounces@ietf.org] De la par=
t de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27<=
/pre>

=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-----


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




 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 






--_000_E194C2E18676714DACA9C3A2516265D20266DE20FR712WXCHMBA12z_--


From nobody Wed Mar  5 16:59:28 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 3F1301A004E for ; Wed,  5 Mar 2014 16:59:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.339
X-Spam-Level: 
X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=1.107, RP_MATCHES_RCVD=-0.547] 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 a3piyO0DrcIS for ; Wed,  5 Mar 2014 16:59:21 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8486D1A0035 for ; Wed,  5 Mar 2014 16:59:20 -0800 (PST)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Wed, 5 Mar 2014 19:59:16 -0500
From: Dave Dolson 
To: "draft-ietf-dime-ovli@tools.ietf.org" 
Thread-Topic: draft-ietf-dime-ovli - New suggestion for default algorithm
Thread-Index: Ac841fuFfE+KyIHeRTSqZDlimYct8A==
Date: Thu, 6 Mar 2014 00:59:15 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [176.35.176.240]
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9818AC22AEwtlexchp1sandvi_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/LYw44PnlFnSqcVo71WAOcdjfOfs
Cc: "dime@ietf.org" 
Subject: [Dime] draft-ietf-dime-ovli - New suggestion for default algorithm
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: Thu, 06 Mar 2014 00:59:23 -0000

--_000_E8355113905631478EFF04F5AA706E9818AC22AEwtlexchp1sandvi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Jouni et all,

I'm reading this draft for the first time, so apologies if I've totally mis=
understood...

As I understand the control signal, the reporting node says "reduce current=
 demand by x %"
- I think this would be implemented in the reacting node by turning away x%=
 of requests.

But then there can be an updated message (with a later sequence number), "r=
educe current demand by y%",
- I think this would be implemented in the reacting node by turning away (1=
00 - (1-x/100)*(1-y/100)*100) % of traffic.
- E.g., x=3D20%, y=3D10% --> 28%

There are also complexities in the protocol (sequence checking) to ensure t=
hat it doesn't see the 'x' message twice and apply the 'x' reduction twice.
E.g., reduce by 10%, reduce by 10% (oops) --> 19%
Or what if a message is missed? The reacting node might not be doing what t=
he reporting node thinks it is.

Also, there is no way for the reporting node to reduce the drop by a small =
percent. E.g., to reduce the drop level back down to 10% from 28%. The only=
 mechanism in the protocol completely removes all control.


So, I think it would be a lot simpler for the reporting node to indicate an=
 absolute percentage to turn away vs. the amount to reduce the previous val=
ue by.

In the example above, the reporting node says "shed 10% of demand".
And later it says "shed 28% of demand".
It can also back off a bit by saying "shed 15% of demand"
And it can remove all controls by saying, "shed 0% of demand"
Duplicate commands cause no harm. And if commands are lost we still have ev=
entual consistency when the next message is received.

When conditions are consistently overloaded, the job of the reporting node =
is to hunt for the best steady-state drop numbers. A good control system ca=
nnot be done with all-on/all-off levers.

This protocol change would remove the need for the sequence number (no race=
 conditions to resolve), and rename the OC-Reduction-Percentage to perhaps =
OC-Discard-Percentage.

Thoughts?

David Dolson
Senior Software Architect
Sandvine


--_000_E8355113905631478EFF04F5AA706E9818AC22AEwtlexchp1sandvi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Jouni et all,


 


I’m reading this draft for the first time, so =
apologies if I’ve totally misunderstood…


 


As I understand the control signal, the reporting no=
de says “reduce current demand by x %”


- I think this would be implemented in the reacting =
node by turning away x% of requests.


 


But then there can be an updated message (with a lat=
er sequence number), “reduce current demand by y%”,<=
/p>

- I think this would be implemented in the reacting =
node by turning away (100 - (1-x/100)*(1-y/100)*100) % of traffic.


- E.g., x=3D20%, y=3D10% =E0 28%


 


There are also complexities in the protocol (sequenc=
e checking) to ensure that it doesn’t see the ‘x’ message=
 twice and apply the ‘x’ reduction twice.


E.g., reduce by 10%, reduce by 10% (oops) 
=E0 19%


Or what if a message is missed? The reacting node mi=
ght not be doing what the reporting node thinks it is.


 


Also, there is no way for the reporting node to redu=
ce the drop by a small percent. E.g., to reduce the drop level back down to=
 10% from 28%. The only mechanism in the protocol completely removes all co=
ntrol.


 


 


So, I think it would be a lot simpler for the report=
ing node to indicate an absolute percentage to turn away vs. the amount to =
reduce the previous value by.


 


In the example above, the reporting node says “=
;shed 10% of demand”.


And later it says “shed 28% of demand”.<=
o:p>


It can also back off a bit by saying “shed 15%=
 of demand”


And it can remove all controls by saying, “she=
d 0% of demand”


Duplicate commands cause no harm. And if commands ar=
e lost we still have eventual consistency when the next message is received=
.


 


When conditions are consistently overloaded, the job=
 of the reporting node is to hunt for the best steady-state drop numbers. A=
 good control system cannot be done with all-on/all-off levers.<=
/p>

 


This protocol change would remove the need for the s=
equence number (no race conditions to resolve), and rename the OC-Reduction=
-Percentage to perhaps OC-Discard-Percentage.


 


Thoughts?


 


David Dolson


Senior Software Architect


Sandvine


 






--_000_E8355113905631478EFF04F5AA706E9818AC22AEwtlexchp1sandvi_--


From nobody Wed Mar  5 23:17: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 2DC2D1A00ED for ; Wed,  5 Mar 2014 23:17:39 -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 sXGcmjQ14nd7 for ; Wed,  5 Mar 2014 23:17:35 -0800 (PST)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3D26C1A00CB for ; Wed,  5 Mar 2014 23:17:35 -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 s267HTrg010663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 01:17:30 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s267HR3u009382 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 08:17:27 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 6 Mar 2014 08:17:27 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Dave Dolson , "draft-ietf-dime-ovli@tools.ietf.org" 
Thread-Topic: draft-ietf-dime-ovli - New suggestion for default algorithm
Thread-Index: Ac841fuFfE+KyIHeRTSqZDlimYct8AANO++g
Date: Thu, 6 Mar 2014 07:17:26 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20266DF93FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/kLEbhlUlxPp9lw2WRYX1QdqUTvE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] draft-ietf-dime-ovli - New suggestion for default algorithm
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: Thu, 06 Mar 2014 07:17:39 -0000

--_000_E194C2E18676714DACA9C3A2516265D20266DF93FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Dave

Thanks for your analysis that I share.
The text of the IETF draft was written  according to your hereafter proposa=
l with   the "absolute percentage" in mind
" I think it would be a lot simpler for the reporting node to indicate an a=
bsolute percentage to turn away vs. the amount to reduce the previous value=
 by."
This is the way I read the IETF draft.

Your remark indicates that the current  text in the draft  can be interpret=
ed according to the other way that we must avoid. So I think we have to  ca=
refully review the wording so that there is no more this difference of inte=
rpretation.

Best regards

Jean-Jacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Dave Dolson
Envoy=E9 : jeudi 6 mars 2014 01:59
=C0 : draft-ietf-dime-ovli@tools.ietf.org
Cc : dime@ietf.org
Objet : [Dime] draft-ietf-dime-ovli - New suggestion for default algorithm

Jouni et all,

I'm reading this draft for the first time, so apologies if I've totally mis=
understood...

As I understand the control signal, the reporting node says "reduce current=
 demand by x %"
- I think this would be implemented in the reacting node by turning away x%=
 of requests.

But then there can be an updated message (with a later sequence number), "r=
educe current demand by y%",
- I think this would be implemented in the reacting node by turning away (1=
00 - (1-x/100)*(1-y/100)*100) % of traffic.
- E.g., x=3D20%, y=3D10% --> 28%

There are also complexities in the protocol (sequence checking) to ensure t=
hat it doesn't see the 'x' message twice and apply the 'x' reduction twice.
E.g., reduce by 10%, reduce by 10% (oops) --> 19%
Or what if a message is missed? The reacting node might not be doing what t=
he reporting node thinks it is.

Also, there is no way for the reporting node to reduce the drop by a small =
percent. E.g., to reduce the drop level back down to 10% from 28%. The only=
 mechanism in the protocol completely removes all control.


So, I think it would be a lot simpler for the reporting node to indicate an=
 absolute percentage to turn away vs. the amount to reduce the previous val=
ue by.

In the example above, the reporting node says "shed 10% of demand".
And later it says "shed 28% of demand".
It can also back off a bit by saying "shed 15% of demand"
And it can remove all controls by saying, "shed 0% of demand"
Duplicate commands cause no harm. And if commands are lost we still have ev=
entual consistency when the next message is received.

When conditions are consistently overloaded, the job of the reporting node =
is to hunt for the best steady-state drop numbers. A good control system ca=
nnot be done with all-on/all-off levers.

This protocol change would remove the need for the sequence number (no race=
 conditions to resolve), and rename the OC-Reduction-Percentage to perhaps =
OC-Discard-Percentage.

Thoughts?

David Dolson
Senior Software Architect
Sandvine


--_000_E194C2E18676714DACA9C3A2516265D20266DF93FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Dave


 


Thanks for your analys=
is that I share.


The text of the IETF d=
raft was written  according to your hereafter proposal with  &nbs=
p;the “absolute percentage” in mind


” I think it woul=
d be a lot simpler for the reporting node to indicate an absolute percentag=
e to turn away vs. the amount to reduce the previous value by.”<=
/o:p>


This is the way I read the IETF draft.

 


Your remark indicates that the current  text in=
 the draft  can be interpreted according to the other way that we must=
 avoid. So I think we have to  carefully review the wording so that th=
ere is no more this difference of interpretation.


 


Best regards


 


Jean-Jacques  


 






De : DiME [mailto:dime-bounces@ietf.org]
De la part de Dave Dolson

Envoy=E9 : jeudi 6 mars 2014 01:59

=C0 : draft-ietf-dime-ovli@tools.ietf.org

Cc : dime@ietf.org

Objet : [Dime] draft-ietf-dime-ovli - New suggestion for defaul=
t algorithm






 


Jouni et all,


 


I’m reading this draft for the first time, so =
apologies if I’ve totally misunderstood…


 


As I understand the control signal, the reporting no=
de says “reduce current demand by x %”


- I think this would be implemented in the reacting =
node by turning away x% of requests.


 


But then there can be an updated message (with a lat=
er sequence number), “reduce current demand by y%”,<=
/p>

- I think this would be implemented in the reacting =
node by turning away (100 - (1-x/100)*(1-y/100)*100) % of traffic.


- E.g., x=3D20%, y=3D10% =E0 28%


 


There are also complexities in the protocol (sequenc=
e checking) to ensure that it doesn’t see the ‘x’ message=
 twice and apply the ‘x’ reduction twice.


E.g., reduce by 10%, reduce by 10% (oops) 
=E0 19%


Or what if a message is missed? The reacting node mi=
ght not be doing what the reporting node thinks it is.


 


Also, there is no way for the reporting node to redu=
ce the drop by a small percent. E.g., to reduce the drop level back down to=
 10% from 28%. The only mechanism in the protocol completely removes all co=
ntrol.


 


 


So, I think it would be a lot simpler for the report=
ing node to indicate an absolute percentage to turn away vs. the amount to =
reduce the previous value by.


 


In the example above, the reporting node says “=
;shed 10% of demand”.


And later it says “shed 28% of demand”.<=
o:p>


It can also back off a bit by saying “shed 15%=
 of demand”


And it can remove all controls by saying, “she=
d 0% of demand”


Duplicate commands cause no harm. And if commands ar=
e lost we still have eventual consistency when the next message is received=
.


 


When conditions are consistently overloaded, the job=
 of the reporting node is to hunt for the best steady-state drop numbers. A=
 good control system cannot be done with all-on/all-off levers.<=
/p>

 


This protocol change would remove the need for the s=
equence number (no race conditions to resolve), and rename the OC-Reduction=
-Percentage to perhaps OC-Discard-Percentage.


 


Thoughts?


 


David Dolson


Senior Software Architect


Sandvine


 






--_000_E194C2E18676714DACA9C3A2516265D20266DF93FR712WXCHMBA12z_--


From nobody Wed Mar  5 23:47: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 E30961A0227 for ; Wed,  5 Mar 2014 14:02:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.746
X-Spam-Level: 
X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 f7A93THplsI7 for ; Wed,  5 Mar 2014 14:02:03 -0800 (PST)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 363D21A0175 for ; Wed,  5 Mar 2014 14:02:02 -0800 (PST)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 6de97135.0.2620539.00-2053.7329692.nbfkord-smmo06.seg.att.com (envelope-from );  Wed, 05 Mar 2014 22:01:58 +0000 (UTC)
X-MXL-Hash: 53179ed6005dd712-ce7530028d2e6fb67a4ff899f1c5a0f2cd8d3b5a
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s25M1u5m009384; Wed, 5 Mar 2014 17:01:58 -0500
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s25M1jmB009070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Mar 2014 17:01:56 -0500
Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (MISOUT7MSGHUBAC.itservices.sbc.com [130.9.129.147]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 5 Mar 2014 22:01:30 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0174.001; Wed, 5 Mar 2014 17:01:30 -0500
From: "DOLLY, MARTIN C" 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0D/9p5E0P/tHNMw/9nRdqD/sqJygP9kxxBw
Date: Wed, 5 Mar 2014 22:01:30 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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> <16317_1393952811_5316082B_16317_4358_1_6B7134B31289DC4FAF731D844122B36E4DF9F3@PEXCVZYM13.corporate.adroot.infra.ftgroup>  <5316EEB5.9000100@usdonovans.com>
In-Reply-To: <5316EEB5.9000100@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.175.81.134]
Content-Type: multipart/alternative; boundary="_000_E42CCDDA6722744CB241677169E83656025D73C5MISOUT7MSGUSR9I_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=PetIcFdd c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=ofMgfj31e3cA:10 a=A-m968FHe08A:10 a=BLceEmwcHowA:10 a=zQP]
X-AnalysisOut: [7CpKOAAAA:8 a=XIqpo32RAAAA:8 a=48vgC7mUAAAA:8 a=z9tbli-vAA]
X-AnalysisOut: [AA:8 a=02K0Y2VpAAAA:8 a=Z80JlwQ0AAAA:8 a=08tW4lx5FKoVJ1EFy]
X-AnalysisOut: [CEA:9 a=wPNLvfGTeEIA:10 a=lZB815dzVvQA:10 a=oAXR_kdF8uMA:1]
X-AnalysisOut: [0 a=XldRh3EjJ24Zjdo9:21 a=PF3dVpSiJFv__9fr:21 a=yMhMjlubAA]
X-AnalysisOut: [AA:8 a=SSmOFEACAAAA:8 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 ]
X-AnalysisOut: [a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=eHpiZN_H7Yq44Y9_:21 ]
X-AnalysisOut: [a=sRPCvv4qvJOpaoSS:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7qN-GNLe5-eVptJww2SZ4qKFing
X-Mailman-Approved-At: Wed, 05 Mar 2014 23:47:10 -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: Wed, 05 Mar 2014 22:02:18 -0000

--_000_E42CCDDA6722744CB241677169E83656025D73C5MISOUT7MSGUSR9I_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Choose and move on.... It is not that difficult

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, March 05, 2014 4:30 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi,

Well, first, the new functionality being proposed is to allow the loss repo=
rts to apply to a single client.

The use of global (type 1) reports will generally be most of the time, as i=
t is likely that a reporting node will send the same overload level to all =
clients the vast majority of the time.  And, while there will clearly be a =
transition period when there are both supporting and non supporting reactin=
g nodes that will require special agent processing, this will reasonably qu=
ickly stabilize into all reacting nodes supporting DOIC.

Changing the meaning of the loss report to be per client forces agents into=
 tracking overload state per client 100% of the time.  That is not an insig=
nificant impact.

Next, the interaction between per client and global report types is trivial=
ly simple -- use the more specific version received.

And finally, I don't understand JJacques point about breaking the principle=
 of independency of the DOIC associations.

Steve
On 3/5/14 7:35 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi

I share the Lionel's view about the added value this optimization may  brin=
g  versus  the extra  costs it has.  I also feel  uncomfortable when we bre=
ak the  principle of the independency of the DOIC associations. When we bre=
ak it, this  has  consequences (cf my mail), but in the future it may have =
some unexpected others.

Best regards

JJacques


De : lionel.morand@orange.com [mailto:lion=
el.morand@orange.com]
Envoy=E9 : mardi 4 mars 2014 18:07
=C0 : Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf=
.org
Objet : RE: [Dime] Issue#35 conclusion

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.




_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_E42CCDDA6722744CB241677169E83656025D73C5MISOUT7MSGUSR9I_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Choose and move on…=
. It is not that difficult


 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: Wednesday, March 05, 2014 4:30 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Hi,



Well, first, the new functionality being proposed is to allow the loss repo=
rts to apply to a single client. 




The use of global (type 1) reports will generally be most of the time, as i=
t is likely that a reporting node will send the same overload level to all =
clients the vast majority of the time.  And, while there will clearly =
be a transition period when there are
 both supporting and non supporting reacting nodes that will require specia=
l agent processing, this will reasonably quickly stabilize into all reactin=
g nodes supporting DOIC. 




Changing the meaning of the loss report to be per client forces agents into=
 tracking overload state per client 100% of the time.  That is not an =
insignificant impact.



Next, the interaction between per client and global report types is trivial=
ly simple -- use the more specific version received.



And finally, I don't understand JJacques point about breaking the principle=
 of independency of the DOIC associations. 




Steve




On 3/5/14 7:35 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQU=
ES) wrote:






Hi


 <=
/p>

I share the Lionel’=
s view about the added value this optimization may  bring  versus=
  the extra  costs it has.  I also feel  uncomfortable =
when we break the 
 principle of the independency of the DOIC associations. When we break it, =
this  has  consequences (cf my mail), but in the future it may ha=
ve some unexpected others.



 <=
/p>

Best regards<=
/span>


 =



JJacques



 =



 =







De =
:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Envoy=E9 : mardi 4 mars 2014 18:07

=C0 : Maria Cruz Bartolome; TROTTIN, JEAN-JACQUES (JEAN-JACQUES=
); 
dime@ietf.org

Objet : RE: [Dime] Issue#35 conclusion






 


Hi,


 <=
/p>

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 w=
ill have to expect to store OLR for specific non-supporting DOIC nodes anyw=
ay. So OK, with the new type, time to time, you will be
 able to optimize a little bit.


But this comes with some =
extra cost as you have now to manage possible interactions between two flav=
ors of the same OLR.


 <=
/p>

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,


 <=
/p>

Interesting analysis.


 <=
/p>

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


“The se=
quence 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<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto: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<=
o:p>


 <=
/p>


1)     
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



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


-      &=
nbsp;  
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)     
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)     
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)     
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)     
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<=
/span>


 =



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-----


De : DiME [mailto:dime-bounces@ietf.org] De la par=
t de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27<=
/pre>

=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-----


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




 


____________________________________________________=
_____________________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
o:p>


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,<=
o:p>


Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.iet=
f.org/mailman/listinfo/dime




 






--_000_E42CCDDA6722744CB241677169E83656025D73C5MISOUT7MSGUSR9I_--


From nobody Thu Mar  6 00:00: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 CD2791A0121 for ; Thu,  6 Mar 2014 00:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 TIznOJwMHUwp for ; Wed,  5 Mar 2014 23:59:58 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B571F1A0130 for ; Wed,  5 Mar 2014 23:59:57 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-a6-53182af83762
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id F4.85.04853.8FA28135; Thu,  6 Mar 2014 08:59:53 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 08:59:52 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/MXVwSViOSJ+HwVeoYWkoDw==
Date: Thu, 6 Mar 2014 07:59:51 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se>
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_087A34937E64E74E848732CFF8354B920978A014ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvje5PLYlggzczuC3m9q5gc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxurLe1kLNq5jrHjzv525gfHMLMYuRk4OCQETic0HP7JA2GIS F+6tZ+ti5OIQEjjBKNGw/wmUs4hRovlMJxtIFZuAncSl0y+Yuhg5OEQElCVO/3IACQsLqEvc +X6BFcQWEdCQaHzziR3C1pN49KcbzGYRUJHY8mYmWA2vgK/Eve45YHFGoMXfT61hArGZBcQl bj2ZzwRxkIDEkj3nmSFsUYmXj/+xQthKEmsPb2eBqM+XeHb3KhPETEGJkzOfsExgFJqFZNQs JGWzkJRBxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYySxanFxbnpRgZ6uem5JXqpRZnJ xcX5eXrFqZsYgfFxcMtvox2MJ/fYH2KU5mBREue9zloTJCSQnliSmp2aWpBaFF9UmpNafIiR iYNTqoExVF93i3/E2lrBzKdhpkpLTlrVSHA9Y5si1nJrvkrUAvOODN8nDglPc7t6VvmwpCjN XuiitevT8uKb3+6W+Z6XXbV/z4sNVe+DG1dV/z/4pnXK3DN7jE4bBc9br860959FYvnHXZ7N /lGWjYcVha6f/xOr9/G/s81L3/c33wavYpxya5FbVth1JZbijERDLeai4kQAWD38TF0CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/iJRIeR6t_zGj68gtjHg1d7eRzHs
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: Thu, 06 Mar 2014 08:00:01 -0000

--_000_087A34937E64E74E848732CFF8354B920978A014ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)     We expect the agent to apply the host-report received in an answer t=
o specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)     We expect the agent to apply this host-report to any client that is =
sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz



--_000_087A34937E64E74E848732CFF8354B920978A014ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

 


Dear all,


 <=
/p>

This mail thread started =
proposing new OLR reports to request reduction for one specific client.



However, the discussion c=
larified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is one special case=
 here, when the agent is acting on behalf of the client (i.e. for a non-sup=
porting client or for an agent SFE with topology hiding).
 In this case, the reporting node sends host-report to agent. Here we have =
two options:


 <=
/p>

a)&=
nbsp;   
We expect =
the agent to apply the host-report received in an answer to specifically th=
e client that sent the corresponding request


This requires some=
 extra complexity at agent side.


But here we have o=
ne more option: allow the reporting node to choose whether it prefers to ap=
ply this host-report to “all-client” vs “one-client”=
;. That
 increases again the complexity (at reporting node, protocol-wise, and at a=
gent).


 <=
/span>


b)&=
nbsp;   
We expect =
the agent to apply this host-report to
any client that is sending a request towards this agent


In my opinion, thi=
s is the best approach, it reduces complexity and increases robustness.



 <=
/p>

Therefore, I will be in f=
avor of option b), which does not require any changes to the actual draft.<=
o:p>


 <=
/p>

Let me know your opinions=
.


Best regards


/MCruz<=
/p>

 <=
/p>

 






--_000_087A34937E64E74E848732CFF8354B920978A014ESESSMB101erics_--


From nobody Thu Mar  6 00:01:59 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 2F2691A0121 for ; Wed,  5 Mar 2014 23:57:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_56=0.6, SPF_PASS=-0.001] 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 sb3THOK_jTA9 for ; Wed,  5 Mar 2014 23:57:37 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 537AD1A0130 for ; Wed,  5 Mar 2014 23:57:33 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-c6-53182a68a4ec
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 85.15.04249.86A28135; Thu,  6 Mar 2014 08:57:28 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 08:57:27 +0100
From: Maria Cruz Bartolome 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1Xn9wvmyrSf2I+rd4YT2PBgATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0CACoSUgP//gt7Q//3+5LA=
Date: Thu, 6 Mar 2014 07:57:26 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209789FEE@ESESSMB101.ericsson.se>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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>  <5316EDEB.9080606@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_087A34937E64E74E848732CFF8354B9209789FEEESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrPLMWRmVeSWpSXmKPExsUyM+JvjW6GlkSwwZmFahZze1ewOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+Hv1SwFX5ZxVXz52sXYwPigmbOLkZNDQsBE4vSG98wQtpjE hXvr2UBsIYEjjBKzFnl3MXIB2YsYJfYduwJWxCZgJ3Hp9AumLkYODhEBZYnTvxxAwsIC6hJ3 vl9gBbFFBDQkGt98YoewbzFKtH62ALFZBFQkns+6ClbDK+ArcabnHDvE/MkcElM7jjOCJDgF YiVOTukBa2YEOuj7qTVMIDazgLjErSfzmSAOFZBYsuc81NGiEi8f/2OFsJUk1h7ezgJyG7NA vsSaueYQuwQlTs58wjKBUWQWkkmzEKpmIamCKNGTuDF1ChuErS2xbOFrZghbV2LGv0MsyOIL GNlXMXIUpxYn5aYbGWxiBEbKwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2Mez21OkK7NwZ/2fBYZavGCtMHNutPeai1nMn4qP76/QORryruaqnMggGs KrEB7VmRJjN+18sEJG0pLxSJcrrFcof/4I/TXHk395gnTz1Y5PR07vzWvvjb+xyED1XPCbqk HTXD7tjcMxViLk5lXnv+FtZ4zfWVtv0ouSKoZ78gV9GPkBermU8rsRRnJBpqMRcVJwIAgIAo 5WICAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qvqY6veA0v3kX1mr88yuCkQoiuU
X-Mailman-Approved-At: Thu, 06 Mar 2014 00:01:58 -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: Thu, 06 Mar 2014 07:57:55 -0000

--_000_087A34937E64E74E848732CFF8354B9209789FEEESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)     We expect the agent to apply the host-report received in an answer t=
o specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)     We expect the agent to apply this host-report to any client that is =
sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 05 de marzo de 2014 21:10
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Hi Steve and all
See my comments in line
Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 5 mars 2014 10:27
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

JJacques,

See my comments inline.

Steve
On 3/4/14 1:34 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
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 re=
duction % (90%) , then the  DA receives an OLR client (1) to update % for a=
ll 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 soo=
n after  it will receive  a new OLR type (0) with 90% but this rule is some=
thing 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 t=
ype (1) makes all old type (1) OLRs  invalid and leave unchanged clients wi=
th a OLR type(0)". But not sure the story is finished., if later the specif=
ic peak vanishes and the server wants to handle client A as other nodes,  w=
hat 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 continue=
 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.
SRD> It doesn't need to be this complex.  The rule should be that when a re=
porting node starts to use a per client report for an individual client the=
n the reporting node must continue to use per client reports for the durati=
on of the occurrence of overload.  This removes any confusion about what th=
e reacting node should do. Then for ypur suggestion,

JJacques > I started from the assumption OLR applying to "all nodes", in fa=
ct the rule should  be to "all nodes" except those having an  OLR of type (=
0) active.  Then we can effectively use the rule you mentionned:  "when a r=
eporting node starts to use a per client report for an individual client th=
en the reporting node must continue to use per client reports for the durat=
ion of the occurrence of overload". So the introduction of the AVP generate=
s two rules .


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?
SRD> I guess I don't understand.  The type 1 report will have a sequence nu=
mber.  Each type 0 report will have its own sequence number.  As long as th=
ose follow the defined behavior for sequence numbers then there should be n=
o issue.

JJacques> my point is to clarify if we have a  seq number per DOIC associat=
ion, or one seq number common to all nodes, according the single or all nod=
e AVP value(except nodes with a type (0) active). It also  has  an impact o=
n the expiry timer  that  will have the same value  for all nodes (except n=
odes with a type (0) active). To note this may create simultaneous traffic =
bursts at timer expiration.  If decision to introduce all node case, it wou=
ld ay require clarification text.


3)     Another point: when I consider the target network in the future wher=
e there are only DOIC clients, why to continue to send a mandatory OLR whic=
h  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 p=
resent. As in the target network, the Host OLR is  per client, default valu=
e would be (0). Views?
SRD> Again, I don't understand.  What mandatory OLR?  An OLR is only sent w=
hen the reacting node is actually in an overload state.  It will send no OL=
R when it is no longer overloaded.

JJacques> sorry for the wording error, I was addressing  the new AVP (singl=
e, All node) in the OLR, please replace "OLR" by "new AVP in the OLR". This=
 new AVP was described  as mandatory in the proposal, so raising my comment



4)     Regarding DOIC association, here we have an information (OLR with ty=
pe (1)  exchanged inside  a DOIC association that applies to many DOIC asso=
ciations.  It is possible but it should be highlighted .
SRD> What is the issue?
JJacques> I do not say that the All node approach does not work, I only dra=
w some consequences. On point 4 the principle to have independent DOIC asso=
ciations was for me a good principle. With the all node introduction, we ha=
ve some common handling to all DOIC associations  (except those with a type=
 (0) active OLR), atshould be highlighted.



5)     I also saw Mcruz had a preferencee for another OLR type and not a ne=
w AVP, have  we concluded on this .
SRD> I don't have a strong preference but adding a scope or type AVP to the=
 OLR AVP seems to work.

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
SRD> I don't see this as an optimization.  Adding per client reports is a n=
ew feature.
JJacques> If we do not introduce the new AVP, the solution works. Then by i=
ntroducing  this new AVP it allows the DA acting on behalf of all the non s=
upporting DOIC clients, to have a more simple processing in the DA by doing=
 a  global  throttling applied to all the requests of these nodes. So  this=
 is an optimization of the solution without the new AVP and is optional.

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




_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_087A34937E64E74E848732CFF8354B9209789FEEESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Dear all,


 <=
/p>

This mail thread started =
proposing new OLR reports to request reduction for one specific client.



However, the discussion c=
larified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is one special case=
 here, when the agent is acting on behalf of the client (i.e. for a non-sup=
porting client or for an agent SFE with topology hiding).
 In this case, the reporting node sends host-report to agent. Here we have =
two options:


 <=
/p>


a) &nbs=
p;  
We expect =
the agent to apply the host-report received in an answer to specifically th=
e client that sent the corresponding request


This requires some=
 extra complexity at agent side.


But here we have o=
ne more option: allow the reporting node to choose whether it prefers to ap=
ply this host-report to “all-client” vs “one-client”=
;. That
 increases again the complexity (at reporting node, protocol-wise, and at a=
gent).


 <=
/span>



b) &nbs=
p;  
We expect =
the agent to apply this host-report to
any client that is sending a request towards this agent


In my opinion, thi=
s is the best approach, it reduces complexity and increases robustness.



 <=
/p>

Therefore, I will be in f=
avor of option b), which does not require any changes to the actual draft.<=
o:p>


 <=
/p>

Let me know your opinions=
.


Best regards


/MCruz<=
/p>

 <=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces=
@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 05 de marzo de 2014 21:10

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Hi Steve and all


See my comments in line


Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 5 mars 2014 10:27

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


JJacques,



See my comments inline.



Steve




On 3/4/14 1:34 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQU=
ES) wrote:






Hi all<=
/p>

 <=
/p>

Hereafter several points =
 about some collateral consequences of the Ticket #35 proposal<=
o:p>


 <=
/p>


1)    
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.   





SRD> It doesn't need to be this complex.  Th=
e rule should be that when a reporting node starts to use a per client repo=
rt for an individual client then the reporting node must continue to use pe=
r client reports for the duration of the occurrence
 of overload.  This removes any confusion about what the reacting node=
 should do. Then for ypur suggestion,



 


JJacques
> I started from the assumption OLR appl=
ying to “all nodes”, in fact the rule should  be to “=
;all nodes” except those having an  OLR of type (0) active. =
; Then we can effectively
 use the rule you mentionned:  =
;“when a reporting node starts to use a per client report for an indi=
vidual client then the reporting node must continue to use per client repor=
ts for the duration of the occurrence of overload”.
So the introduction of the AVP generates tw=
o rules .



 



2)    
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?


SRD> I guess I don't understand.  The type 1=
 report will have a sequence number.  Each type 0 report will have its=
 own sequence number.  As long as those follow the defined behavior fo=
r sequence numbers then there should be no issue.


 <=
/p>

JJacques> my point =
is to clarify if we have a  seq number per DOIC association, or one se=
q number common to all nodes, according the single or all node AVP
 value(except nodes with a type (0) active). It also  has  an imp=
act on the expiry timer  that  will have the same value  for=
 all nodes (except nodes with a type (0) active). To note this may create s=
imultaneous traffic bursts at timer expiration.  If decision
 to introduce all node case, it would ay require clarification text.


 <=
/p>


3)    
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?


SRD> Again, I don't understand.  What mandat=
ory OLR?  An OLR is only sent when the reacting node is actually in an=
 overload state.  It will send no OLR when it is no longer overloaded.=
 




JJacques> sorry for the wording error, I w=
as addressing  the new AVP (single, All node) in the OLR, please repla=
ce “OLR” by “new AVP in the OLR”. This new AVP was =
described  as
 mandatory in the proposal, so raising my comment


 


 <=
/p>


4)    
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 . 


SRD> What is the issue?


JJacques> I do not =
say that the All node approach does not work, I only draw some consequences=
. On point 4 the principle to have independent DOIC associations
 was for me a good principle. With the all node introduction, we have some =
common handling to all DOIC associations  (except those with a type (0=
) active OLR), atshould be highlighted.


 <=
/p>

 



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



SRD> I don't have =
a strong preference but adding a scope or type AVP to the OLR AVP seems to =
work.


 <=
/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



SRD> I don't see this as an optimization.  A=
dding per client reports is a new feature.


JJacques> If we do =
not introduce the new AVP, the solution works. Then by introducing  th=
is new AVP it allows the DA acting on behalf of all the non supporting
 DOIC clients, to have a more simple processing in the DA by doing a  =
global  throttling applied to all the requests of these nodes. So &nbs=
p;this is an optimization of the solution without the new AVP and is option=
al.


 <=
/p>

Best regards<=
/span>


 =



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-----


De : DiME [mailto:dime-bounces@ietf.org] De la par=
t de Maria Cruz Bartolome


Envoy=E9 : lundi 24 f=E9vrier 2014 14:27<=
/pre>

=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-----


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




 









_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 






--_000_087A34937E64E74E848732CFF8354B9209789FEEESESSMB101erics_--


From nobody Thu Mar  6 00:11: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 9FAF31A012E for ; Thu,  6 Mar 2014 00:11:55 -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 Uu1HmeOPp_8u for ; Thu,  6 Mar 2014 00:11:52 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDD41A0131 for ; Thu,  6 Mar 2014 00:11:51 -0800 (PST)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 6FA3C1B8269; Thu,  6 Mar 2014 09:11:46 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 1FD9D384084; Thu,  6 Mar 2014 09:11:46 +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; Thu, 6 Mar 2014 09:11:45 +0100
From: 
To: Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac8uORl1kE6lHJqaEUSwRUSn1ZjUWwATUamAABiWF1AACvi8gACOgNbAAAHYfYAAAac4cAAA5h9wAABcWDAAAG750P//+8MAgAAelYCAACgCgIAABcUAgAAC24CAAAHxAIAAB4sAgADmaQD//ugSYIACz7WAgAHjQYCAABptAIAAKB6A//41l0CACoSUgP//gt7QAD7NCQD//+z8YA==
Date: Thu, 6 Mar 2014 08:11:45 +0000
Message-ID: <1387_1394093506_53182DC2_1387_1629_1_6B7134B31289DC4FAF731D844122B36E4E56A7@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3F63@DEMUMBX014.nsn-intra.net> <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>  <5316EDEB.9080606@usdonovans.com>  <087A34937E64E74E848732CFF8354B9209789FEE@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209789FEE@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.6]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E4E56A7PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.19.63615
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/M9GHczOV_34H_CQpVM7i2l9eX_M
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: Thu, 06 Mar 2014 08:11:55 -0000

--_000_6B7134B31289DC4FAF731D844122B36E4E56A7PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I agree on the approach proposed below.

About the "any change to the actual draft", I think that draft needs anyway=
 to reflect this clarification on the agent behavior :)

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : jeudi 6 mars 2014 08:57
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#35 conclusion

Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)      We expect the agent to apply the host-report received in an answer =
to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)      We expect the agent to apply this host-report to any client that is=
 sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz


___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E4E56A7PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I agree on=
 the approach proposed below.


 =
;


About the =
"any change to the actual draft", I think that draft needs anyway=
 to reflect this clarification on the agent behavior
J


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : jeudi 6 mars 2014 08:57

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#35 conclusion






 


Dear all,<=
o:p>


 =
;


This mail =
thread started proposing new OLR reports to request reduction for one speci=
fic client.



However, t=
he discussion clarified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is o=
ne special case here, when the agent is acting on behalf of the client (i.e=
. for a non-supporting client or for an agent SFE with topology
 hiding). In this case, the reporting node sends host-report to agent. Here=
 we have two options:


 =
;


=
a)     
We expect the agent to apply the host-repor=
t received in an answer to specifically the client that sent
 the corresponding request


Thi=
s requires some extra complexity at agent side.


But=
 here we have one more option: allow the reporting node to choose whether i=
t prefers to apply this host-report to “all-client” vs “o=
ne-client”.
 That increases again the complexity (at reporting node, protocol-wise, and=
 at agent).


 


=
b)     
We expect the agent to apply this host-repo=
rt to
any client that is sending a request towards this agent


In =
my opinion, this is the best approach, it reduces complexity and increases =
robustness.



 =
;


Therefore,=
 I will be in favor of option b), which does not require any changes to the=
 actual draft.


 =
;


Let me kno=
w your opinions.


Best regar=
ds


/MCruz


 =
;




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E4E56A7PEXCVZYM13corpora_--


From nobody Thu Mar  6 00:40: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 CAC6F1A015F for ; Thu,  6 Mar 2014 00:40:47 -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 aYKvo4RLPXOT for ; Thu,  6 Mar 2014 00:40:45 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7173E1A0020 for ; Thu,  6 Mar 2014 00:40:45 -0800 (PST)
Received: from dhcp-hotel-wifi-155-bb.meeting.ietf.org (dhcp-hotel-wifi-155-bb.meeting.ietf.org [130.129.155.187] (may be forged)) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s268eSI9067296 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 6 Mar 2014 02:40:32 -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: 
Date: Thu, 6 Mar 2014 08:40:27 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/S_cLtZai6cBWvg2dUMlxXqU33BA
Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] draft-ietf-dime-ovli - New suggestion for default algorithm
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: Thu, 06 Mar 2014 08:40:48 -0000

On Mar 6, 2014, at 7:17 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) =
 wrote:

> Hi Dave
> =20
> Thanks for your analysis that I share.
> The text of the IETF draft was written  according to your hereafter =
proposal with   the =93absolute percentage=94 in mind
> =94 I think it would be a lot simpler for the reporting node to =
indicate an absolute percentage to turn away vs. the amount to reduce =
the previous value by.=94
> This is the way I read the IETF draft.
> =20

Agreed. We didn't mean for the percentages to "stack". It would probably =
be better to describe the percentage reduction as a reduction against =
what you would have sent if no overload conditions had been reported. If =
a second overload report contains a smaller reduction percentage, we =
expect the traffic to increase, not decrease by the additional amount.

> Your remark indicates that the current  text in the draft  can be =
interpreted according to the other way that we must avoid. So I think we =
have to  carefully review the wording so that there is no more this =
difference of interpretation.

Also agreed.

> =20
> Best regards
> =20
> Jean-Jacques =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Dave Dolson
> Envoy=E9 : jeudi 6 mars 2014 01:59
> =C0 : draft-ietf-dime-ovli@tools.ietf.org
> Cc : dime@ietf.org
> Objet : [Dime] draft-ietf-dime-ovli - New suggestion for default =
algorithm
> =20
> Jouni et all,
> =20
> I=92m reading this draft for the first time, so apologies if I=92ve =
totally misunderstood=85
> =20
> As I understand the control signal, the reporting node says =93reduce =
current demand by x %=94
> - I think this would be implemented in the reacting node by turning =
away x% of requests.
> =20
> But then there can be an updated message (with a later sequence =
number), =93reduce current demand by y%=94,
> - I think this would be implemented in the reacting node by turning =
away (100 - (1-x/100)*(1-y/100)*100) % of traffic.
> - E.g., x=3D20%, y=3D10% =E0 28%
> =20
> There are also complexities in the protocol (sequence checking) to =
ensure that it doesn=92t see the =91x=92 message twice and apply the =91x=92=
 reduction twice.
> E.g., reduce by 10%, reduce by 10% (oops) =E0 19%
> Or what if a message is missed? The reacting node might not be doing =
what the reporting node thinks it is.
> =20
> Also, there is no way for the reporting node to reduce the drop by a =
small percent. E.g., to reduce the drop level back down to 10% from 28%. =
The only mechanism in the protocol completely removes all control.
> =20
> =20
> So, I think it would be a lot simpler for the reporting node to =
indicate an absolute percentage to turn away vs. the amount to reduce =
the previous value by.
> =20
> In the example above, the reporting node says =93shed 10% of demand=94.
> And later it says =93shed 28% of demand=94.
> It can also back off a bit by saying =93shed 15% of demand=94
> And it can remove all controls by saying, =93shed 0% of demand=94
> Duplicate commands cause no harm. And if commands are lost we still =
have eventual consistency when the next message is received.
> =20
> When conditions are consistently overloaded, the job of the reporting =
node is to hunt for the best steady-state drop numbers. A good control =
system cannot be done with all-on/all-off levers.
> =20
> This protocol change would remove the need for the sequence number (no =
race conditions to resolve), and rename the OC-Reduction-Percentage to =
perhaps OC-Discard-Percentage.
> =20
> Thoughts?
> =20
> David Dolson
> Senior Software Architect
> Sandvine


From nobody Thu Mar  6 01:12: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 B33F21A019C for ; Thu,  6 Mar 2014 01:11:59 -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 GRzQUPWq4jwd for ; Thu,  6 Mar 2014 01:11:55 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 902171A01A9 for ; Thu,  6 Mar 2014 01:11:38 -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 s269BWKJ007912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 10:11:32 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s269BVwn013721 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 10:11:31 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 6 Mar 2014 10:11:31 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 10:11:31 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/Xn9wvmyrSf2I+rd4YT2PBgAAVchQ
Date: Thu, 6 Mar 2014 09:11:30 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se>
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_5BCBA1FC2B7F0B4C9D935572D9000668151B5A68DEMUMBX014nsnin_"
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: 23643
X-purgate-ID: 151667::1394097092-00003660-A36503EE/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fJkrOoYw6czx3iab3eM5J0oHhuY
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: Thu, 06 Mar 2014 09:12:00 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5A68DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request repor=
ts. Can you please confirm.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4=
.7.  please confirm.

Also proposal b)  impacts the reporting node which must not send client spe=
cific OLRs (with separate sequence number streams for different clients)

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type rep=
ort to any non-DOIC-supporting client that is sending requests towards this=
 host/realm.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but=
 not Steve)  think it is "natural" and "implicit" that agents would do the =
per client behaviour as a default.


An alternative proposal that addresses the complexity argument for agents b=
ut at the same time at least partly addresses the 3GPP requirement would be=
 to make use of a feature flag: clients allways set the flag, agents do not=
 set the flag, reporting nodes may send client specific OLRs when the flag =
in the request was set. This has no big impact to clients (only always set =
the feature flag), no impacts to agents, and allows (if so desired) reporti=
ng nodes to make use of the client specific throttling (at least in some ca=
ses).

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)      We expect the agent to apply the host-report received in an answer =
to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)      We expect the agent to apply this host-report to any client that is=
 sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz



--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5A68DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear MCruz,


 <=
/p>

for my cla=
rification:



what you s=
ay about Host reports is also true for Realm-Routed-Request reports. Can yo=
u please confirm.


 =
;


Proposal b=
) does not address the 3GPP requirement from TR 29.809 clause 6.4.7.  =
please confirm.


 =
;


Also propo=
sal b)  impacts the reporting node which must not send client specific=
 OLRs (with separate sequence number streams for different clients)


 =
;


Also, shou=
ldn’t b) read:


We expect =
the agent to apply this host type / realm-routed-request type report to any
non-DOIC-supporting client that is sending requests towards this hos=
t/realm.


 =
;


Also, you =
say:


b) does no=
t require any changes to the actual draft


 =
;


I guess at=
 least some clarification is required as some (Lionel, Nirav, but not Steve=
)  think it is “natural” and “implicit” that a=
gents would
 do the per client behaviour as a default. 


 =
;


 =
;


An alterna=
tive proposal that addresses the complexity argument for agents but at the =
same time at least partly addresses the 3GPP requirement would
 be to make use of a feature flag: clients allways set the flag, agents do =
not set the flag, reporting nodes may send client specific OLRs when the fl=
ag in the request was set. This has no big impact to clients (only always s=
et the feature flag), no impacts
 to agents, and allows (if so desired) reporting nodes to make use of the c=
lient specific throttling (at least in some cases).


 =
;


Best regar=
ds


Ulrich


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, March 06, 2014 9:00 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


 =
;


 


Dear all,<=
o:p>


 =
;


This mail =
thread started proposing new OLR reports to request reduction for one speci=
fic client.



However, t=
he discussion clarified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is o=
ne special case here, when the agent is acting on behalf of the client (i.e=
. for a non-supporting client or for an agent SFE with topology
 hiding). In this case, the reporting node sends host-report to agent. Here=
 we have two options:


 =
;


=
a)     
We expect the agent to apply the host-report received in an answer to =
specifically the client that sent the corresponding request


Thi=
s requires some extra complexity at agent side.


But=
 here we have one more option: allow the reporting node to choose whether i=
t prefers to apply this host-report to “all-client” vs “o=
ne-client”.
 That increases again the complexity (at reporting node, protocol-wise, and=
 at agent).


 


=
b)     
We expect the agent to apply this host-report to
any client that is sending a request towards this agent


In =
my opinion, this is the best approach, it reduces complexity and increases =
robustness.



 =
;


Therefore,=
 I will be in favor of option b), which does not require any changes to the=
 actual draft.


 =
;


Let me kno=
w your opinions.


Best regar=
ds


/MCruz


 =
;


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5A68DEMUMBX014nsnin_--


From nobody Thu Mar  6 05:58: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 39AE01A0078 for ; Thu,  6 Mar 2014 05:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 f8hLteEKdbGn for ; Thu,  6 Mar 2014 05:58:15 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id DDA3E1A017E for ; Thu,  6 Mar 2014 05:58:13 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-08-53187ef1c40f
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 2E.8F.04853.1FE78135; Thu,  6 Mar 2014 14:58:09 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Thu, 6 Mar 2014 14:58:09 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/MXVwSViOSJ+HwVeoYWkoDwAAaGMAAAI8puA=
Date: Thu, 6 Mar 2014 13:58:08 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@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: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920978A1E3ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7HOolgg5UNchZze1ewWax7u4LJ gcljyZKfTB4/119lD2CK4rJJSc3JLEst0rdL4MrYNPk8Y8HG24wVuyZMY2pgvHSIsYuRk0NC wETiSWczC4QtJnHh3nq2LkYuDiGBE4wSZ383skM4ixglHvw7CNbBJmAncen0CyYQW0QgXuLl mx/MILawgLrEne8XWCHiGhKNbz6xQ9hWEp//XgKzWQRUJKbeOwe2jVfAV6Lx80KwOUICkxkl NjZogdicAgESh/cvZAOxGYEu+n5qDVgNs4C4xK0n85kgLhWQWLLnPDOELSrx8vE/VghbSWLR 7c9Q9fkS+97tYoLYJShxcuYTlgmMIrOQjJqFpGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxm QhZfwMi+ilGyOLW4ODfdyEAvNz23RC+1KDO5uDg/T684dRMjMMoObvlttIPx5B77Q4zSHCxK 4rzXWWuChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBOOWj0YUePYPzryTZb2fIEP2fyHPyv zRLaoerXH6G1ScH+983333Uf/W5M4q+KeW914nTLAYYX2XMc06Y9i1fQ/vD8ZOwD2eTdJxJN xPuWKNw5Zny19l7eni72rKkyMcGvOfL3T56/eKLHot8HfpabbXm8aKWTs5e5206lUrPI/6sq F+Rfc5dUYinOSDTUYi4qTgQAu+wuwoACAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/y7MkivuKWH-LxIE65WMhr81HzKs
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: Thu, 06 Mar 2014 13:58:18 -0000

--_000_087A34937E64E74E848732CFF8354B920978A1E3ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Ulrich,

See below please
Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request repor=
ts. Can you please confirm.
[MCruz] I think this case is different. If we agree that realm reports are =
only generated by agents (as an aggregated report based on host reports and=
 potentially another implementation dependent criteria), then the server it=
self does not require a traffic-to-realm reduction, on the contrary, the ho=
st only requests a traffic-to-host reduction. Agent may or not (I think thi=
s is up in the draft) to  forward back to the original client this host-rep=
ort. Then, not sure if we really need something else here.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4=
.7.  please confirm.
[MCruz] It does address the 3GPP requirement in general, but not for one sp=
ecific case:  "There is one special case here, when the agent is acting on =
behalf of the client (i.e. for a non-supporting client or for an agent SFE =
with topology hiding)".

Also proposal b)  impacts the reporting node which must not send client spe=
cific OLRs (with separate sequence number streams for different clients)
[MCruz] I do not think so. In the case I mentioned, when the agent is actin=
g on behalf of the client, it is always the receiver of the answers (i.e. f=
rom a host perspective, the client is the agent, and then there are not sep=
arate sequence number streams).

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type rep=
ort to any non-DOIC-supporting client that is sending requests towards this=
 host/realm.
[MCruz] Yes, any non-DOIC-supporting client.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but=
 not Steve)  think it is "natural" and "implicit" that agents would do the =
per client behaviour as a default.
[MCruz] Agreed, at least clarification is required.

An alternative proposal that addresses the complexity argument for agents b=
ut at the same time at least partly addresses the 3GPP requirement would be=
 to make use of a feature flag: clients allways set the flag, agents do not=
 set the flag, reporting nodes may send client specific OLRs when the flag =
in the request was set. This has no big impact to clients (only always set =
the feature flag), no impacts to agents, and allows (if so desired) reporti=
ng nodes to make use of the client specific throttling (at least in some ca=
ses).

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)     We expect the agent to apply the host-report received in an answer t=
o specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)     We expect the agent to apply this host-report to any client that is =
sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz



--_000_087A34937E64E74E848732CFF8354B920978A1E3ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear Ulrich,


 <=
/p>

See below please


Best regards


/MCruz<=
/p>

 <=
/p>





From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wi=
ehe@nsn.com]


Sent: jueves, 06 de marzo de 2014 10:12

To: Maria Cruz Bartolome; dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion






 


Dear MCruz,


 


for my clarification:



what you say about Host r=
eports is also true for Realm-Routed-Request reports. Can you please confir=
m.


[MCruz] I think this case=
 is different. If we agree that realm reports are only generated by agents =
(as an aggregated report based on host reports and potentially
 another implementation dependent criteria), then the server itself does no=
t require a traffic-to-realm reduction, on the contrary, the host only requ=
ests a traffic-to-host reduction. Agent may or not (I think this is up in t=
he draft) to  forward back to the
 original client this host-report. Then, not sure if we really need somethi=
ng else here.


 <=
/p>

Proposal b) does not addr=
ess the 3GPP requirement from TR 29.809 clause 6.4.7.  please confirm.=



[MCruz] It does address t=
he 3GPP requirement in general, but not for one specific case:  “=
;There
 is one special case here, when the agent is acting on behalf of the client=
 (i.e. for a non-supporting client or for an agent SFE with topology hiding=
)”.


 <=
/p>

Also proposal b)  im=
pacts the reporting node which must not send client specific OLRs (with sep=
arate sequence number streams for different clients)


[MCruz] I do not think so=
. In the case I mentioned, when the agent is acting on behalf of the client=
, it is always the receiver of the answers (i.e. from a
 host perspective, the client is the agent, and then there are not separate=
 sequence number streams).


 <=
/p>

Also, shouldn’t b) =
read:


We expect the agent to ap=
ply this host type / realm-routed-request type report to any
non-DOIC-supporting client that is sending requests towards this hos=
t/realm.


[MCruz] Yes, any non-DOIC=
-supporting client.


 <=
/p>

Also, you say:=



b) does not require any c=
hanges to the actual draft


 <=
/p>

I guess at least some cla=
rification is required as some (Lionel, Nirav, but not Steve)  think i=
t is “natural” and “implicit” that agents would do =
the per client
 behaviour as a default. 


[MCruz] Agreed, at least =
clarification is required.


 <=
/p>

An alternative proposal t=
hat addresses the complexity argument for agents but at the same time at le=
ast partly addresses the 3GPP requirement would be to make
 use of a feature flag: clients allways set the flag, agents do not set the=
 flag, reporting nodes may send client specific OLRs when the flag in the r=
equest was set. This has no big impact to clients (only always set the feat=
ure flag), no impacts to agents,
 and allows (if so desired) reporting nodes to make use of the client speci=
fic throttling (at least in some cases).


 <=
/p>

Best regards


Ulrich<=
/p>

 <=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, March 06, 2014 9:00 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


 <=
/p>

 


Dear all,


 <=
/p>

This mail thread started =
proposing new OLR reports to request reduction for one specific client.



However, the discussion c=
larified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is one special case=
 here, when the agent is acting on behalf of the client (i.e. for a non-sup=
porting client or for an agent SFE with topology hiding).
 In this case, the reporting node sends host-report to agent. Here we have =
two options:


 <=
/p>

a)&=
nbsp;   
We expect =
the agent to apply the host-report received in an answer to specifically th=
e client that sent the corresponding request


This requires some=
 extra complexity at agent side.


But here we have o=
ne more option: allow the reporting node to choose whether it prefers to ap=
ply this host-report to “all-client” vs “one-client”=
;. That
 increases again the complexity (at reporting node, protocol-wise, and at a=
gent).


 <=
/span>


b)&=
nbsp;   
We expect =
the agent to apply this host-report to
any client that is sending a request towards this agent


In my opinion, thi=
s is the best approach, it reduces complexity and increases robustness.



 <=
/p>

Therefore, I will be in f=
avor of option b), which does not require any changes to the actual draft.<=
o:p>


 <=
/p>

Let me know your opinions=
.


Best regards


/MCruz<=
/p>

 <=
/p>

 






--_000_087A34937E64E74E848732CFF8354B920978A1E3ESESSMB101erics_--


From nobody Thu Mar  6 06:24:50 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 C4F061A03B5 for ; Thu,  6 Mar 2014 06:24:47 -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 U4DaNMgn7EKb for ; Thu,  6 Mar 2014 06:24:45 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4D01A03AA for ; Thu,  6 Mar 2014 06:24:45 -0800 (PST)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.01.0339.001; Thu, 6 Mar 2014 09:24:40 -0500
From: Dave Dolson 
To: Ben Campbell , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
Thread-Topic: draft-ietf-dime-ovli - New suggestion for default algorithm
Thread-Index: Ac841fuFfE+KyIHeRTSqZDlimYct8AANO++gAA2trYAAB4yX8A==
Date: Thu, 6 Mar 2014 14:24:39 +0000
Message-ID: 
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [31.133.167.107]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/guMpwEWHLU-81P8C4-j34krikbU
Cc: "dime@ietf.org" , "draft-ietf-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] draft-ietf-dime-ovli - New suggestion for default algorithm
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: Thu, 06 Mar 2014 14:24:48 -0000

I think the relevant language is in section 4.7:

"... describes the percentage the sender is requested to reduce, compared t=
o what it otherwise would have sent."

How about:

"... prescribes the absolute percentage of application requests the sender =
is requested to suppress, compared to what it would have sent without suppr=
ession."




-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com]=20
Sent: Thursday, March 06, 2014 8:40 AM
To: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc: Dave Dolson; draft-ietf-dime-ovli@tools.ietf.org; dime@ietf.org
Subject: Re: draft-ietf-dime-ovli - New suggestion for default algorithm

On Mar 6, 2014, at 7:17 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES)  wrote:

> Hi Dave
> =20
> Thanks for your analysis that I share.
> The text of the IETF draft was written  according to your hereafter propo=
sal with   the "absolute percentage" in mind
> " I think it would be a lot simpler for the reporting node to indicate an=
 absolute percentage to turn away vs. the amount to reduce the previous val=
ue by."
> This is the way I read the IETF draft.
> =20

Agreed. We didn't mean for the percentages to "stack". It would probably be=
 better to describe the percentage reduction as a reduction against what yo=
u would have sent if no overload conditions had been reported. If a second =
overload report contains a smaller reduction percentage, we expect the traf=
fic to increase, not decrease by the additional amount.

> Your remark indicates that the current  text in the draft  can be interpr=
eted according to the other way that we must avoid. So I think we have to  =
carefully review the wording so that there is no more this difference of in=
terpretation.

Also agreed.

> =20
> Best regards
> =20
> Jean-Jacques =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Dave Dolson
> Envoy=E9 : jeudi 6 mars 2014 01:59
> =C0 : draft-ietf-dime-ovli@tools.ietf.org
> Cc : dime@ietf.org
> Objet : [Dime] draft-ietf-dime-ovli - New suggestion for default algorith=
m
> =20
> Jouni et all,
> =20
> I'm reading this draft for the first time, so apologies if I've totally m=
isunderstood.
> =20
> As I understand the control signal, the reporting node says "reduce curre=
nt demand by x %"
> - I think this would be implemented in the reacting node by turning away =
x% of requests.
> =20
> But then there can be an updated message (with a later sequence number), =
"reduce current demand by y%",
> - I think this would be implemented in the reacting node by turning away =
(100 - (1-x/100)*(1-y/100)*100) % of traffic.
> - E.g., x=3D20%, y=3D10% =E0 28%
> =20
> There are also complexities in the protocol (sequence checking) to ensure=
 that it doesn't see the 'x' message twice and apply the 'x' reduction twic=
e.
> E.g., reduce by 10%, reduce by 10% (oops) =E0 19%
> Or what if a message is missed? The reacting node might not be doing what=
 the reporting node thinks it is.
> =20
> Also, there is no way for the reporting node to reduce the drop by a smal=
l percent. E.g., to reduce the drop level back down to 10% from 28%. The on=
ly mechanism in the protocol completely removes all control.
> =20
> =20
> So, I think it would be a lot simpler for the reporting node to indicate =
an absolute percentage to turn away vs. the amount to reduce the previous v=
alue by.
> =20
> In the example above, the reporting node says "shed 10% of demand".
> And later it says "shed 28% of demand".
> It can also back off a bit by saying "shed 15% of demand"
> And it can remove all controls by saying, "shed 0% of demand"
> Duplicate commands cause no harm. And if commands are lost we still have =
eventual consistency when the next message is received.
> =20
> When conditions are consistently overloaded, the job of the reporting nod=
e is to hunt for the best steady-state drop numbers. A good control system =
cannot be done with all-on/all-off levers.
> =20
> This protocol change would remove the need for the sequence number (no ra=
ce conditions to resolve), and rename the OC-Reduction-Percentage to perhap=
s OC-Discard-Percentage.
> =20
> Thoughts?
> =20
> David Dolson
> Senior Software Architect
> Sandvine


From nobody Thu Mar  6 06:25:29 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 96DE61A0290 for ; Thu,  6 Mar 2014 06:25:27 -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 oAQtFC4-GyAO for ; Thu,  6 Mar 2014 06:25:25 -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 C49721A01AE for ; Thu,  6 Mar 2014 06:25:24 -0800 (PST)
Received: from localhost ([127.0.0.1]:40301 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLZEe-00063c-8k; Thu, 06 Mar 2014 15:25:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Thu, 06 Mar 2014 14:25:20 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/dime/trac/ticket/52#comment:1
Message-ID: <090.fbb6b486376099dd54771cff2d93ec97@trac.tools.ietf.org>
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 52
In-Reply-To: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.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/sH8zZoB6GBXB0_PkH1MhQ__V6ps
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #52 (draft-docdt-dime-ovli): Throttling not needed to be based on previous history
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: Thu, 06 Mar 2014 14:25:27 -0000

#52: Throttling not needed to be based on previous history

Changes (by maria.cruz.bartolome@ericsson.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Text should be modified as follows:

 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.

 Proposal:
     Indicates that the reporting node urges the reacting node to
     reduce its traffic by a given percentage. For example if an
     OC-Reduction-Percentage value of  10 has been received,
     the reacting node which  would otherwise send 100 requests
     MUST only send 90 requests to the reporting node.
     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
    request from its output queue and let the generic application logic
    try to recover from it.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |       Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  major                              |      Status:  closed
Component:  draft-docdt-dime-ovli              |   Milestone:
 Severity:  Active WG Document                 |     Version:  1.0
 Keywords:                                     |  Resolution:  fixed
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Thu Mar  6 06:30:48 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 C36DB1A00FE for ; Thu,  6 Mar 2014 06:30: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 lAzBLCWW_fK4 for ; Thu,  6 Mar 2014 06:30:42 -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 CF6511A0385 for ; Thu,  6 Mar 2014 06:30:41 -0800 (PST)
Received: from localhost ([127.0.0.1]:40486 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLZJh-0000wb-Nx; Thu, 06 Mar 2014 15:30:33 +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: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Thu, 06 Mar 2014 14:30:33 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/dime/trac/ticket/50#comment:1
Message-ID: <090.664c74aa0af94aab34e09e4a26dee33e@trac.tools.ietf.org>
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
X-Trac-Ticket-ID: 50
In-Reply-To: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fHsRmGxz9qwrmHit1J040dnEaWk
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #50 (draft-docdt-dime-ovli): OC-OLR AVP implicit info
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: Thu, 06 Mar 2014 14:30:44 -0000

#50: OC-OLR AVP implicit info

Changes (by maria.cruz.bartolome@ericsson.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Now (chapter 4.3):

     The OC-OLR AVP does not contain explicit information to which
     application it applies to and who inserted the AVP or whom the
     specific OC-OLR AVP concerns to. Both these information is
     implicitly learned from the encapsulating Diameter message/command.
     The application the OC-OLR AVP applies to is the same as the
     Application-Id found in the Diameter message header.  The identity
     the OC-OLR AVP concerns is determined from the Origin-Host AVP found
     from the encapsulating Diameter command.

 Will be replaced by:

 The OC-OLR AVP does not contain explicitly all information needed by the
 reacting node in order to decide whether a subsequent request must undergo
 a throttling process with the received reduction percentage.
 The value of the OC-Report-Type AVP within the OC-OLR AVP indicates which
 implicit information is relevant for this decision (see clause 4.6).

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:  1.0
 Severity:  Active WG Document       |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Thu Mar  6 06:34:27 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 295D91A0416 for ; Thu,  6 Mar 2014 06:34:23 -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 l-HkqPNkSsb6 for ; Thu,  6 Mar 2014 06:34:19 -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 56FEA1A0410 for ; Thu,  6 Mar 2014 06:34:19 -0800 (PST)
Received: from localhost ([127.0.0.1]:40611 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLZNG-00043z-Pn; Thu, 06 Mar 2014 15:34:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Thu, 06 Mar 2014 14:34:14 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/dime/trac/ticket/51#comment:1
Message-ID: <090.7daf3ac4bac85ef3f70396fbf1faab46@trac.tools.ietf.org>
References: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 51
In-Reply-To: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.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/iWNoFzr00mZDkn6esinfgF252gQ
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #51 (draft-docdt-dime-ovli): OC-Supported-Features in requests
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: Thu, 06 Mar 2014 14:34:23 -0000

#51: OC-Supported-Features in requests

Changes (by maria.cruz.bartolome@ericsson.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Now:
  The OC-Supported-Features AVP SHOULD be included into every Diameter
 message a DOIC  supporting node sends (and intends to use for DOIC
 purposes).

 Proposal:
 The OC-Supported-Features AVP MUST be included into every Diameter request
 message a DOIC supporting node sends.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |       Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  major                              |      Status:  closed
Component:  draft-docdt-dime-ovli              |   Milestone:
 Severity:  Active WG Document                 |     Version:  1.0
 Keywords:                                     |  Resolution:  fixed
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Thu Mar  6 06:37:55 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 713DB1A03D9 for ; Thu,  6 Mar 2014 06:37:53 -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 nhabyEfAZypQ for ; Thu,  6 Mar 2014 06:37:51 -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 B67161A0380 for ; Thu,  6 Mar 2014 06:37:51 -0800 (PST)
Received: from localhost ([127.0.0.1]:40746 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLZQh-0005JM-B3; Thu, 06 Mar 2014 15:37:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: maria.cruz.bartolome@ericsson.com
X-Trac-Project: dime
Date: Thu, 06 Mar 2014 14:37:47 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: https://tools.ietf.org/wg/dime/trac/ticket/53#comment:1
Message-ID: <090.c737ef1ce8aed6a56ccc2e02c10d0ff3@trac.tools.ietf.org>
References: <075.7050d926bbf4992a2147612aa862564a@trac.tools.ietf.org>
X-Trac-Ticket-ID: 53
In-Reply-To: <075.7050d926bbf4992a2147612aa862564a@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.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/mTuAk6uYEwmQV2qnMuco5oDn3Sc
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #53 (draft-docdt-dime-ovli): 5.5.2 chapter typo?
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: Thu, 06 Mar 2014 14:37:53 -0000

#53: 5.5.2 chapter typo?

Changes (by maria.cruz.bartolome@ericsson.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 No action requested.
 Chapter 5.5.2 needs updates due to #Issue 29. This will modify referred
 wrong paragraph.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |       Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  minor                              |      Status:  closed
Component:  draft-docdt-dime-ovli              |   Milestone:
 Severity:  Active WG Document                 |     Version:  1.0
 Keywords:                                     |  Resolution:  fixed
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Fri Mar  7 00:07:59 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 D00341A010F for ; Fri,  7 Mar 2014 00:07:56 -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 aYSLa8Yll2C7 for ; Fri,  7 Mar 2014 00:07:51 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0084C1A0113 for ; Fri,  7 Mar 2014 00:07:47 -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 s2787fGX010292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Mar 2014 09:07:41 +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 s2787efZ027662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 09:07:40 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 7 Mar 2014 09:07:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 09:07:39 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Maria Cruz Bartolome , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/Xn9wvmyrSf2I+rd4YT2PBgAAVchQAAoVTgAAJYd7MA==
Date: Fri, 7 Mar 2014 08:07:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.108]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8DEMUMBX014nsnin_"
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: 35985
X-purgate-ID: 151667::1394179661-00002142-15518766/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AuGmBzipnoVQTNfShPQ3U1uS990
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: Fri, 07 Mar 2014 08:07:57 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear MCruz,

please see below

Best regards
Ulrich
From: ext Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]
Sent: Thursday, March 06, 2014 2:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Dear Ulrich,

See below please
Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request repor=
ts. Can you please confirm.
[MCruz] I think this case is different. If we agree that realm reports are =
only generated by agents (as an aggregated report based on host reports and=
 potentially another implementation dependent criteria), then the server it=
self does not require a traffic-to-realm reduction, on the contrary, the ho=
st only requests a traffic-to-host reduction. Agent may or not (I think thi=
s is up in the draft) to  forward back to the original client this host-rep=
ort. Then, not sure if we really need something else here.
 I don't know whether it is still relevant, but I would have though=
t that the agent that generates a realm-routed-request report, when taking =
the host reports received from servers into accout for the aggregation, may=
 e.g. detect that all the severs request reduction of traffic from the same=
 a specific client. Would it not be logical that the aggregated realm-route=
d-request report in this case also only requests reduction from that client=
 (with the aggregated percentage)? 

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4=
.7.  please confirm.
[MCruz] It does address the 3GPP requirement in general, but not for one sp=
ecific case:  "There is one special case here, when the agent is acting on =
behalf of the client (i.e. for a non-supporting client or for an agent SFE =
with topology hiding)".
 I'm not sure, see below

Also proposal b)  impacts the reporting node which must not send client spe=
cific OLRs (with separate sequence number streams for different clients)
[MCruz] I do not think so. In the case I mentioned, when the agent is actin=
g on behalf of the client, it is always the receiver of the answers (i.e. f=
rom a host perspective, the client is the agent
This is not correct. The host (reporting node) does not know whethe=
r the reacting node is the client (identified by orig-host in the request) =
or an agent (acting on behalf of the client and possibly also on behalf of =
other clients); the reporting node receives a request that contains an OC-S=
upported-Features AVP; this indicates to the reporting node that there is a=
 downstream node supporting DOIC. Let me give an example:
Two non-supporting clients C1 and C2 send requests via the same supporting =
agent A to the server. Traffic from C1 increases, so S requests a 10% throt=
tling from C1 (sequence number 1). As the agent A is acting on behalf of C1=
, A will do the throttling. As a not wanted but acceptable side effect A wi=
ll also throttle traffic sent from C2 to S. Now the situation improves and =
S only requests a 5% reduction from C1 (sequence number 2).  Again A will a=
pply the 5% throttling also for traffic from C2, which again is not nice bu=
t acceptable. Now  Traffic from C2 increases (although throttled with 5%) a=
nd S request a 50% throttling from C2 (sequence number 1). 
, and then there are not separate sequence number streams).

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type rep=
ort to any non-DOIC-supporting client that is sending requests towards this=
 host/realm.
[MCruz] Yes, any non-DOIC-supporting client.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but=
 not Steve)  think it is "natural" and "implicit" that agents would do the =
per client behaviour as a default.
[MCruz] Agreed, at least clarification is required.

An alternative proposal that addresses the complexity argument for agents b=
ut at the same time at least partly addresses the 3GPP requirement would be=
 to make use of a feature flag: clients allways set the flag, agents do not=
 set the flag, reporting nodes may send client specific OLRs when the flag =
in the request was set. This has no big impact to clients (only always set =
the feature flag), no impacts to agents, and allows (if so desired) reporti=
ng nodes to make use of the client specific throttling (at least in some ca=
ses).
any comments?

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)      We expect the agent to apply the host-report received in an answer =
to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)      We expect the agent to apply this host-report to any client that is=
 sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz



--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear MCruz,


 <=
/p>

please see below


 <=
/p>

Best regards


Ulrich<=
/p>





From:=
 ext Maria Cruz Bart=
olome [mailto:maria.cruz.bartolome@ericsson.com]


Sent: Thursday, March 06, 2014 2:58 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: RE: [Dime] Issue#35 conclusion






 


Dear Ulric=
h,


 =
;


See below =
please


Best regar=
ds


/MCruz


 =
;






From:=
 Wiehe, Ulrich (NSN =
- DE/Munich)
 [mailto:ulrich.wiehe@nsn.com] =


Sent: jueves, 06 de marzo de 2014 10:12

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: RE: [Dime] Issue#35 conclusion






 


Dear MCruz,


 <=
/p>

for my cla=
rification:



what you s=
ay about Host reports is also true for Realm-Routed-Request reports. Can yo=
u please confirm.


[MCruz] I =
think this case is different. If we agree that realm reports are only gener=
ated by agents (as an aggregated report based on host reports
 and potentially another implementation dependent criteria), then the serve=
r itself does not require a traffic-to-realm reduction, on the contrary, th=
e host only requests a traffic-to-host reduction. Agent may or not (I think=
 this is up in the draft) to  forward
 back to the original client this host-report. Then, not sure if we really =
need something else here.


<Ulrich>=
 I don’t know whether it is still relevant, but I would have thought =
that the agent that generates a realm-routed-request report, when taking
 the host reports received from servers into accout for the aggregation, ma=
y e.g. detect that all the severs request reduction of traffic from the sam=
e a specific client. Would it not be logical that the aggregated realm-rout=
ed-request report in this case also
 only requests reduction from that client (with the aggregated percentage)?=
 </Ulrich>


 =
;


Proposal b=
) does not address the 3GPP requirement from TR 29.809 clause 6.4.7.  =
please confirm.


[MCruz] It=
 does address the 3GPP requirement in general, but not for one specific cas=
e:  “There
 is one special case here, when the agent is acting on behalf of the client=
 (i.e. for a non-supporting client or for an agent SFE with topology hiding=
)”.


<Ulrich>=
 I’m not sure, see below</Ulrich>



 =
;


Also propo=
sal b)  impacts the reporting node which must not send client specific=
 OLRs (with separate sequence number streams for different clients)


[MCruz] I =
do not think so. In the case I mentioned, when the agent is acting on behal=
f of the client, it is always the receiver of the answers
 (i.e. from a host perspective, the client is the agent


<Ulrich>=
This is not correct. The host (reporting node) does not know whether the re=
acting node is the client (identified by orig-host in the request)
 or an agent (acting on behalf of the client and possibly also on behalf of=
 other clients); the reporting node receives a request that contains an OC-=
Supported-Features AVP; this indicates to the reporting node that there is =
a downstream node supporting DOIC.
 Let me give an example:


Two non-suppor=
ting clients C1 and C2 send requests via the same supporting agent A to the=
 server. Traffic from C1 increases, so S requests a 10% throttling
 from C1 (sequence number 1). As the agent A is acting on behalf of C1, A w=
ill do the throttling. As a not wanted but acceptable side effect A will al=
so throttle traffic sent from C2 to S. Now the situation improves and S onl=
y requests a 5% reduction from C1
 (sequence number 2).  Again A will apply the 5% throttling also for t=
raffic from C2, which again is not nice but acceptable. Now  Traffic f=
rom C2 increases (although throttled with 5%) and S request a 50% throttlin=
g from C2 (sequence number 1). </Ulrich>



, and then=
 there are not separate sequence number streams).


 =
;


Also, shou=
ldn’t b) read:


We expect =
the agent to apply this host type / realm-routed-request type report to any
non-DOIC-supporting client that is sending requests towards this hos=
t/realm.


[MCruz] Ye=
s, any non-DOIC-supporting client.


 =
;


Also, you =
say:


b) does no=
t require any changes to the actual draft


 =
;


I guess at=
 least some clarification is required as some (Lionel, Nirav, but not Steve=
)  think it is “natural” and “implicit” that a=
gents would
 do the per client behaviour as a default. 


[MCruz] Ag=
reed, at least clarification is required.


 =
;


An alterna=
tive proposal that addresses the complexity argument for agents but at the =
same time at least partly addresses the 3GPP requirement would
 be to make use of a feature flag: clients allways set the flag, agents do =
not set the flag, reporting nodes may send client specific OLRs when the fl=
ag in the request was set. This has no big impact to clients (only always s=
et the feature flag), no impacts
 to agents, and allows (if so desired) reporting nodes to make use of the c=
lient specific throttling (at least in some cases).


<Ulrich>=
any comments?</Ulrich>


 =
;


Best regar=
ds


Ulrich


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, March 06, 2014 9:00 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


 =
;


 


Dear all,<=
o:p>


 =
;


This mail =
thread started proposing new OLR reports to request reduction for one speci=
fic client.



However, t=
he discussion clarified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is o=
ne special case here, when the agent is acting on behalf of the client (i.e=
. for a non-supporting client or for an agent SFE with topology
 hiding). In this case, the reporting node sends host-report to agent. Here=
 we have two options:


 =
;


=
a)     
We expect the agent to apply the host-report received in an answer to =
specifically the client that sent the corresponding request


Thi=
s requires some extra complexity at agent side.


But=
 here we have one more option: allow the reporting node to choose whether i=
t prefers to apply this host-report to “all-client” vs “o=
ne-client”.
 That increases again the complexity (at reporting node, protocol-wise, and=
 at agent).


 


=
b)     
We expect the agent to apply this host-report to
any client that is sending a request towards this agent


In =
my opinion, this is the best approach, it reduces complexity and increases =
robustness.



 =
;


Therefore,=
 I will be in favor of option b), which does not require any changes to the=
 actual draft.


 =
;


Let me kno=
w your opinions.


Best regar=
ds


/MCruz


 =
;


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8DEMUMBX014nsnin_--


From nobody Fri Mar  7 08:07: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 9BBC51A02AF for ; Fri,  7 Mar 2014 08:07:00 -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 INCyjcaPPFcq for ; Fri,  7 Mar 2014 08:06:58 -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 489411A02A8 for ; Fri,  7 Mar 2014 08:06:58 -0800 (PST)
Received: from localhost ([127.0.0.1]:52098 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLxHw-00062k-IU; Fri, 07 Mar 2014 17:06:21 +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: lionel.morand@orange-ftgroup.com, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Fri, 07 Mar 2014 16:06:17 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/32#comment:2
Message-ID: <081.1ab981726c01117c36b4359574840994@trac.tools.ietf.org>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>
X-Trac-Ticket-ID: 32
In-Reply-To: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, srdonovan@usdonovans.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/p6uGqb_XP_a-AJNwuUR57Sh1BMs
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32 (draft-docdt-dime-ovli): Sequence-Number Time-Stamp values within OC-OLR
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: Fri, 07 Mar 2014 16:07:00 -0000

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


Comment (by srdonovan@usdonovans.com):

 Changed Section 4.3 Paragraph 3 from:

    The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.
    It is possible to replay the same OC-OLR AVP multiple times between
    the overload control endpoints, however, when the OC-OLR AVP content
    changes or sending endpoint otherwise wants the receiving endpoint to
    update its overload control information, then the OC-Sequence-Number
    AVP MUST contain a new greater value than the previously received.
    The receiver SHOULD discard an OC-OLR AVP with a sequence number that
    is less than previously received one.

 To:

    The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.

    It is possible to replay the same OC-OLR AVP multiple times between
    the overload control endpoints, however, when the OC-OLR AVP content
    changes or sending endpoint otherwise wants the receiving endpoint to
    update its overload control information, then the OC-Sequence-Number
    AVP MUST contain a new value that is greater than the value previously
 received.
    The receiver SHOULD discard an OC-OLR AVP with a sequence number that
    is less than or equal to the previously received OC-OLR AVP.

-- 
--------------------------------------+---------------------------
 Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Fri Mar  7 08:31: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 0C4BF1A02CC for ; Fri,  7 Mar 2014 08:31:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 6kfIvn1c-Jga for ; Fri,  7 Mar 2014 08:31:04 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id D7C881A02BE for ; Fri,  7 Mar 2014 08:31:02 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-70-5319f4415f47
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 6B.CE.04249.144F9135; Fri,  7 Mar 2014 17:30:58 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Fri, 7 Mar 2014 17:30:57 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/MXVwSViOSJ+HwVeoYWkoDwAAaGMAAAI8puAALdMXgAASJsPQ
Date: Fri, 7 Mar 2014 16:30:56 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@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.148]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920978A921ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM+Jvja7TF8lgg7fLGS3m9q5gs1j3dgWT A5PHkiU/mTx+rr/KHsAUxWWTkpqTWZZapG+XwJUxceEEloLbc5kqbp5uYWtgPPCbsYuRk0NC wERi77+bbBC2mMSFe+uBbC4OIYEjjBIbu36zQjiLGCW2nfwPVsUmYCdx6fQLJhBbRCBe4uWb H8wgtrCAusSd7xdYIeIaEo1vPrFD2G4Saxf+AqthEVCRaN00HayXV8BX4sLLnVAL5jJJvJuw EewkToEAiZvHToINYgQ66fupNWANzALiEreezGeCOFVAYsme88wQtqjEy8f/WCFsJYnGJU9Y IerzJc4vnMwKsUxQ4uTMJywTGEVmIRk1C0nZLCRlEHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQs voCRfRUjR3FqcVJuupHBJkZgFB3c8ttiB+PlvzaHGKU5WJTEeT++dQ4SEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwHj2+LXCXm7jqfxst0/v0/X8+THFrM3pqO/T7zavXm4JbZ0S0fd67wxW M8urVxMnPF90xHDx5rebQpdL6tSdujLvedyFrhV98nlGqbL79qf4la1ZsO/YH0Wn0p4ppxN4 n7j0bHsZqCu3k6m2UiNIddu9HZ8P9Mc9ysz0WJoR47MgdGN14KaORTuUWIozEg21mIuKEwEp dhxIcAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KgYsPRkFkKEd4jQQn16imA1z_uY
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: Fri, 07 Mar 2014 16:31:11 -0000

--_000_087A34937E64E74E848732CFF8354B920978A921ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear Ulrich,

See comments below please.
Anyway, since during IETF meeting it was commented that this could be consi=
dered as an extension, not sure how this should be managed from now on. I p=
resume we should confirm that in this list.

Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request repor=
ts. Can you please confirm.
[MCruz] I think this case is different. If we agree that realm reports are =
only generated by agents (as an aggregated report based on host reports and=
 potentially another implementation dependent criteria), then the server it=
self does not require a traffic-to-realm reduction, on the contrary, the ho=
st only requests a traffic-to-host reduction. Agent may or not (I think thi=
s is up in the draft) to  forward back to the original client this host-rep=
ort. Then, not sure if we really need something else here.
 I don't know whether it is still relevant, but I would have though=
t that the agent that generates a realm-routed-request report, when taking =
the host reports received from servers into accout for the aggregation, may=
 e.g. detect that all the severs request reduction of traffic from the same=
 a specific client. Would it not be logical that the aggregated realm-route=
d-request report in this case also only requests reduction from that client=
 (with the aggregated percentage)? 
[MCruz] This could be something to be considered and could provide some add=
ed value, but it is up to interpretation whether this is required.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4=
.7.  please confirm.
[MCruz] It does address the 3GPP requirement in general, but not for one sp=
ecific case:  "There is one special case here, when the agent is acting on =
behalf of the client (i.e. for a non-supporting client or for an agent SFE =
with topology hiding)".
 I'm not sure, see below

Also proposal b)  impacts the reporting node which must not send client spe=
cific OLRs (with separate sequence number streams for different clients)
[MCruz] I do not think so. In the case I mentioned, when the agent is actin=
g on behalf of the client, it is always the receiver of the answers (i.e. f=
rom a host perspective, the client is the agent
This is not correct. The host (reporting node) does not know whethe=
r the reacting node is the client (identified by orig-host in the request) =
or an agent (acting on behalf of the client and possibly also on behalf of =
other clients); the reporting node receives a request that contains an OC-S=
upported-Features AVP; this indicates to the reporting node that there is a=
 downstream node supporting DOIC. Let me give an example:
Two non-supporting clients C1 and C2 send requests via the same supporting =
agent A to the server. Traffic from C1 increases, so S requests a 10% throt=
tling from C1 (sequence number 1). As the agent A is acting on behalf of C1=
, A will do the throttling. As a not wanted but acceptable side effect A wi=
ll also throttle traffic sent from C2 to S. Now the situation improves and =
S only requests a 5% reduction from C1 (sequence number 2).  Again A will a=
pply the 5% throttling also for traffic from C2, which again is not nice bu=
t acceptable. Now  Traffic from C2 increases (although throttled with 5%) a=
nd S request a 50% throttling from C2 (sequence number 1). 
, and then there are not separate sequence number streams).
[MCruz] I think your example is right, and it highlights something importan=
t I haven't realized. Since the server may send totally different reduction=
 requests to different clients, as in your example, the key point is not ev=
en that they carry different sequence numbers, but that reduction to apply =
to "all" clients will oscillate a lot, depending on server requests towards=
 one specific client. Then, a way to solve this is that the server knows wh=
ether or not an agent is acting on behalf of the final client. If so, repor=
ting node should not request reductions per client (i.e. %reduction will be=
 the same for any client).

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type rep=
ort to any non-DOIC-supporting client that is sending requests towards this=
 host/realm.
[MCruz] Yes, any non-DOIC-supporting client.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but=
 not Steve)  think it is "natural" and "implicit" that agents would do the =
per client behaviour as a default.
[MCruz] Agreed, at least clarification is required.

An alternative proposal that addresses the complexity argument for agents b=
ut at the same time at least partly addresses the 3GPP requirement would be=
 to make use of a feature flag: clients allways set the flag, agents do not=
 set the flag, reporting nodes may send client specific OLRs when the flag =
in the request was set. This has no big impact to clients (only always set =
the feature flag), no impacts to agents, and allows (if so desired) reporti=
ng nodes to make use of the client specific throttling (at least in some ca=
ses).
any comments?
[MCruz] I agree this could be a way for the reporting node to know that an =
agent is not acting on behalf of a client

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)     We expect the agent to apply the host-report received in an answer t=
o specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)     We expect the agent to apply this host-report to any client that is =
sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz



--_000_087A34937E64E74E848732CFF8354B920978A921ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear Ulrich,


 <=
/p>

See
comments
below please.


Anyway, since during IETF=
 meeting it was commented that this could be considered as an extension, no=
t sure how this should be managed from now on. I presume
 we should confirm that in this list.


 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: jueves, 06 de marzo de 2014 10:12

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: RE: [Dime] Issue#35 conclusion






 


Dear MCruz,


 


for my clarification:



what you say about Host r=
eports is also true for Realm-Routed-Request reports. Can you please confir=
m.


[MCruz] I think this case=
 is different. If we agree that realm reports are only generated by agents =
(as an aggregated report based on host reports and potentially
 another implementation dependent criteria), then the server itself does no=
t require a traffic-to-realm reduction, on the contrary, the host only requ=
ests a traffic-to-host reduction. Agent may or not (I think this is up in t=
he draft) to  forward back to the
 original client this host-report. Then, not sure if we really need somethi=
ng else here.


<Ulrich> I don’t =
know whether it is still relevant, but I would have thought that the agent =
that generates a realm-routed-request report, when taking the host reports
 received from servers into accout for the aggregation, may e.g. detect tha=
t all the severs request reduction of traffic from the same a specific clie=
nt. Would it not be logical that the aggregated realm-routed-request report=
 in this case also only requests
 reduction from that client (with the aggregated percentage)? </Ulrich&g=
t;


[MCruz] This could be =
something to be considered and could provide some added value, but it is up=
 to interpretation whether this is required.



 <=
/p>

Proposal b) does not addr=
ess the 3GPP requirement from TR 29.809 clause 6.4.7.  please confirm.=



[MCruz] It does address t=
he 3GPP requirement in general, but not for one specific case:  “=
;There
 is one special case here, when the agent is acting on behalf of the client=
 (i.e. for a non-supporting client or for an agent SFE with topology hiding=
)”.


<Ulrich> I’m not =
sure, see below</Ulrich>



 <=
/p>

Also proposal b)  im=
pacts the reporting node which must not send client specific OLRs (with sep=
arate sequence number streams for different clients)


[MCruz] I do not think so=
. In the case I mentioned, when the agent is acting on behalf of the client=
, it is always the receiver of the answers (i.e. from a
 host perspective, the client is the agent


<Ulrich>This is not cor=
rect. The host (reporting node) does not know whether the reacting node is =
the client (identified by orig-host in the request) or an agent
 (acting on behalf of the client and possibly also on behalf of other clien=
ts); the reporting node receives a request that contains an OC-Supported-Fe=
atures AVP; this indicates to the reporting node that there is a downstream=
 node supporting DOIC. Let me give
 an example:


Two non-supporting clients C1=
 and C2 send requests via the same supporting agent A to the server. Traffi=
c from C1 increases, so S requests a 10% throttling from
 C1 (sequence number 1). As the agent A is acting on behalf of C1, A will d=
o the throttling. As a not wanted but acceptable side effect A will also th=
rottle traffic sent from C2 to S. Now the situation improves and S only req=
uests a 5% reduction from C1 (sequence
 number 2).  Again A will apply the 5% throttling also for traffic fro=
m C2, which again is not nice but acceptable. Now  Traffic from C2 inc=
reases (although throttled with 5%) and S request a 50% throttling from C2 =
(sequence number 1). </Ulrich>



, and then there are not =
separate sequence number streams).


[MCruz] I think your e=
xample is right, and it highlights something important I haven’t real=
ized. Since the server may send totally different reduction requests
 to different clients, as in your example, the key point is not even that t=
hey carry different sequence numbers, but that reduction to apply to “=
;all” clients will oscillate a lot, depending on server requests towa=
rds one specific client. Then, a way to solve
 this is that the server knows whether or not an agent is acting on behalf =
of the final client. If so, reporting node should not request reductions pe=
r client (i.e. %reduction will be the same for any client).


 <=
/p>

Also, shouldn’t b) =
read:


We expect the agent to ap=
ply this host type / realm-routed-request type report to any
non-DOIC-supporting client that is sending requests towards this hos=
t/realm.


[MCruz] Yes, any non-DOIC=
-supporting client.


 <=
/p>

Also, you say:=



b) does not require any c=
hanges to the actual draft


 <=
/p>

I guess at least some cla=
rification is required as some (Lionel, Nirav, but not Steve)  think i=
t is “natural” and “implicit” that agents would do =
the per client
 behaviour as a default. 


[MCruz] Agreed, at least =
clarification is required.


 <=
/p>

An alternative proposal t=
hat addresses the complexity argument for agents but at the same time at le=
ast partly addresses the 3GPP requirement would be to make
 use of a feature flag: clients allways set the flag, agents do not set the=
 flag, reporting nodes may send client specific OLRs when the flag in the r=
equest was set. This has no big impact to clients (only always set the feat=
ure flag), no impacts to agents,
 and allows (if so desired) reporting nodes to make use of the client speci=
fic throttling (at least in some cases).


<Ulrich>any comments?&l=
t;/Ulrich>


[MCruz] I agree this c=
ould be a way for the reporting node to know that an agent is not acting on=
 behalf of a client


 <=
/p>

Best regards


Ulrich<=
/p>

 <=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, March 06, 2014 9:00 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


 <=
/p>

 


Dear all,


 <=
/p>

This mail thread started =
proposing new OLR reports to request reduction for one specific client.



However, the discussion c=
larified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is one special case=
 here, when the agent is acting on behalf of the client (i.e. for a non-sup=
porting client or for an agent SFE with topology hiding).
 In this case, the reporting node sends host-report to agent. Here we have =
two options:


 <=
/p>

a)&=
nbsp;   
We expect =
the agent to apply the host-report received in an answer to specifically th=
e client that sent the corresponding request


This requires some=
 extra complexity at agent side.


But here we have o=
ne more option: allow the reporting node to choose whether it prefers to ap=
ply this host-report to “all-client” vs “one-client”=
;. That
 increases again the complexity (at reporting node, protocol-wise, and at a=
gent).


 <=
/span>


b)&=
nbsp;   
We expect =
the agent to apply this host-report to
any client that is sending a request towards this agent


In my opinion, thi=
s is the best approach, it reduces complexity and increases robustness.



 <=
/p>

Therefore, I will be in f=
avor of option b), which does not require any changes to the actual draft.<=
o:p>


 <=
/p>

Let me know your opinions=
.


Best regards


/MCruz<=
/p>

 <=
/p>

 






--_000_087A34937E64E74E848732CFF8354B920978A921ESESSMB101erics_--


From nobody Fri Mar  7 08:33:07 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 A2ED01A02BB for ; Fri,  7 Mar 2014 08:33:05 -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 1jO-Es2LUq9x for ; Fri,  7 Mar 2014 08:33:03 -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 BB0EF1A02AF for ; Fri,  7 Mar 2014 08:33:03 -0800 (PST)
Received: from localhost ([127.0.0.1]:53543 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WLxhf-0000Vn-Vx; Fri, 07 Mar 2014 17:32:55 +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: lionel.morand@orange-ftgroup.com, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Fri, 07 Mar 2014 16:32:55 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/32#comment:3
Message-ID: <081.778acab79112f9ddcd125eafacc00df9@trac.tools.ietf.org>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>
X-Trac-Ticket-ID: 32
In-Reply-To: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: lionel.morand@orange-ftgroup.com, srdonovan@usdonovans.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/D3lMrSPpp-QlnQS1Z0IDN_am3yg
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #32 (draft-docdt-dime-ovli): Sequence-Number Time-Stamp values within OC-OLR
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: Fri, 07 Mar 2014 16:33:05 -0000

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


Comment (by srdonovan@usdonovans.com):

 Further updated to change "previously recieved" to "currently active
 overload report".

 The new text is as follows:

 It is possible to replay the same OC-OLR AVP multiple times between the
 overload control endpoints, however, when the OC-OLR AVP content changes
 or the
 sending endpoint otherwise wants the receiving endpoint to update
 its overload control information in an active overload report,
 then the OC-Sequence-Number AVP MUST contain
 a new value which is greater than the last value received for that
 overload report.
 The receiver SHOULD discard an OC-OLR AVP with a sequence number that is
 less than or equal to any currently active overload report previously
 received from the reporting node.

-- 
--------------------------------------+---------------------------
 Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Fri Mar  7 08:44:20 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 8733F1A0205 for ; Fri,  7 Mar 2014 08:44:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.28
X-Spam-Level: 
X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 B4FbasqccLMb for ; Fri,  7 Mar 2014 08:44:17 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4BA1A00A8 for ; Fri,  7 Mar 2014 08:44:17 -0800 (PST)
Received: from [109.144.221.15] (port=50438 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WLxsY-0001fh-JG; Fri, 07 Mar 2014 08:44:12 -0800
Message-ID: <5319F759.1080602@usdonovans.com>
Date: Fri, 07 Mar 2014 16:44:09 +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, lionel.morand@orange-ftgroup.com
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <081.778acab79112f9ddcd125eafacc00df9@trac.tools.ietf.org>
In-Reply-To: <081.778acab79112f9ddcd125eafacc00df9@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------010303080508010504030407"
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/msDgvBcR7se8Vk5vWGp6UTd8Fzc
Subject: Re: [Dime] [dime] #32 (draft-docdt-dime-ovli): 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: Fri, 07 Mar 2014 16:44:18 -0000

This is a multi-part message in MIME format.
--------------010303080508010504030407
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

All,

One note on these changes to the draft based on issue #32.  This issue
was closed without proposing alternative text, so I have taken the
liberty of proposing the text included in these messages.

If I have missed the mark on this wording please re-open the ticket.

I believe there is no proposed text in this one because the guidance to
include proposed text happened after this ticket was closed.

Regards,

Steve

On 3/7/14 4:32 PM, dime issue tracker wrote:
> #32: Sequence-Number Time-Stamp values within OC-OLR
>
>
> Comment (by srdonovan@usdonovans.com):
>
>  Further updated to change "previously recieved" to "currently active
>  overload report".
>
>  The new text is as follows:
>
>  It is possible to replay the same OC-OLR AVP multiple times between the
>  overload control endpoints, however, when the OC-OLR AVP content changes
>  or the
>  sending endpoint otherwise wants the receiving endpoint to update
>  its overload control information in an active overload report,
>  then the OC-Sequence-Number AVP MUST contain
>  a new value which is greater than the last value received for that
>  overload report.
>  The receiver SHOULD discard an OC-OLR AVP with a sequence number that is
>  less than or equal to any currently active overload report previously
>  received from the reporting node.
>


--------------010303080508010504030407
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    All,

      

      One note on these changes to the draft based on issue #32.  This
      issue was closed without proposing alternative text, so I have
      taken the liberty of proposing the text included in these
      messages.

      

      If I have missed the mark on this wording please re-open the
      ticket.

      

      I believe there is no proposed text in this one because the
      guidance to include proposed text happened after this ticket was
      closed.

      

      Regards,

      

      Steve

      

    
    
On 3/7/14 4:32 PM, dime issue tracker
      wrote:

    

    

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


Comment (by srdonovan@usdonovans.com):

 Further updated to change "previously recieved" to "currently active
 overload report".

 The new text is as follows:

 It is possible to replay the same OC-OLR AVP multiple times between the
 overload control endpoints, however, when the OC-OLR AVP content changes
 or the
 sending endpoint otherwise wants the receiving endpoint to update
 its overload control information in an active overload report,
 then the OC-Sequence-Number AVP MUST contain
 a new value which is greater than the last value received for that
 overload report.
 The receiver SHOULD discard an OC-OLR AVP with a sequence number that is
 less than or equal to any currently active overload report previously
 received from the reporting node.



    

    

  


--------------010303080508010504030407--


From nobody Fri Mar  7 09:17: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 AA7CA1A00DE for ; Fri,  7 Mar 2014 09:17:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 SDxuTZLGkog0 for ; Fri,  7 Mar 2014 09:17:04 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7201A0074 for ; Fri,  7 Mar 2014 09:17:02 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-61-5319ff0a3e28
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id FD.91.04853.A0FF9135; Fri,  7 Mar 2014 18:16:58 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Fri, 7 Mar 2014 18:16:57 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" ,  "lionel.morand@orange-ftgroup.com" 
Thread-Topic: [Dime] [dime] #32 (draft-docdt-dime-ovli): Sequence-Number Time-Stamp values within OC-OLR
Thread-Index: AQHPOiLkYHJxtaWxBEeEZvuG+G7oCprVw+KAgAAZ4eA=
Date: Fri, 7 Mar 2014 17:16:56 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978A9DE@ESESSMB101.ericsson.se>
References: <066.f8b7ffcffcd55b9e56fa2bfc281d4649@trac.tools.ietf.org> <081.778acab79112f9ddcd125eafacc00df9@trac.tools.ietf.org> <5319F759.1080602@usdonovans.com>
In-Reply-To: <5319F759.1080602@usdonovans.com>
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_087A34937E64E74E848732CFF8354B920978A9DEESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUyM+JvjS7Xf8lgg/UrBSzm9q5gs7hy9jOr xYYmHgdmjyVLfjJ5/DgW5rHqbR9rAHMUl01Kak5mWWqRvl0CV8b0jf/YCpp8K16t/sXawPjB q4uRk0NCwERizrrNzBC2mMSFe+vZuhi5OIQETjBKTJx/kwnCWcQo8f7sR0aQKjYBO4lLp1+A JUQEpjFKzFr8ix0kISyQKXH3wQcwW0QgS+LDxl+sELaVxMO5E8BWsAioSKw5sI0FxOYV8JXY tOM/1LrljBJL/h4D28ApoCcxbcEysAZGoJu+n1rDBGIzC4hL3HoynwniVgGJJXvOQ90tKvHy 8T9WCFtJYu3h7SwQ9fkSGz+tYYZYJihxcuYTlgmMIrOQjJqFpGwWkrJZjBxAcU2J9bv0IUoU JaZ0P2SHsDUkWufMZUcWX8DIvopRsji1uDg33chALzc9t0QvtSgzubg4P0+vOHUTIzDmDm75 bbSD8eQe+0OM0hwsSuK811lrgoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwKq59H68cf7nJ ls32THZlZM+ThgO1C1iWzj/wTO2xwk35a+479NpF77SoftX8Gtw9O8luybUeh4VbGVLTSq8U vZqXrVHA9yKh0f7kg4u1Znbiq6bMnSUgeyvP58jyQHvPDc8WsUjrBKlyG38r01V3WVuwtOjX izMuax9XGs8QVvpc+ayty6BEiaU4I9FQi7moOBEAW6Z45IcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SCF-efUtWnDt3ENcm6Pzk7IZ1w8
Subject: Re: [Dime] [dime] #32 (draft-docdt-dime-ovli): 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: Fri, 07 Mar 2014 17:17:05 -0000

--_000_087A34937E64E74E848732CFF8354B920978A9DEESESSMB101erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

RmluZSBmb3IgbWUNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRpbWUtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIFN0ZXZlIERvbm92YW4NClNlbnQ6IHZpZXJuZXMsIDA3IGRlIG1hcnpvIGRl
IDIwMTQgMTc6NDQNClRvOiBkaW1lQGlldGYub3JnOyBsaW9uZWwubW9yYW5kQG9yYW5nZS1mdGdy
b3VwLmNvbQ0KU3ViamVjdDogUmU6IFtEaW1lXSBbZGltZV0gIzMyIChkcmFmdC1kb2NkdC1kaW1l
LW92bGkpOiBTZXF1ZW5jZS1OdW1iZXIgVGltZS1TdGFtcCB2YWx1ZXMgd2l0aGluIE9DLU9MUg0K
DQpBbGwsDQoNCk9uZSBub3RlIG9uIHRoZXNlIGNoYW5nZXMgdG8gdGhlIGRyYWZ0IGJhc2VkIG9u
IGlzc3VlICMzMi4gIFRoaXMgaXNzdWUgd2FzIGNsb3NlZCB3aXRob3V0IHByb3Bvc2luZyBhbHRl
cm5hdGl2ZSB0ZXh0LCBzbyBJIGhhdmUgdGFrZW4gdGhlIGxpYmVydHkgb2YgcHJvcG9zaW5nIHRo
ZSB0ZXh0IGluY2x1ZGVkIGluIHRoZXNlIG1lc3NhZ2VzLg0KDQpJZiBJIGhhdmUgbWlzc2VkIHRo
ZSBtYXJrIG9uIHRoaXMgd29yZGluZyBwbGVhc2UgcmUtb3BlbiB0aGUgdGlja2V0Lg0KDQpJIGJl
bGlldmUgdGhlcmUgaXMgbm8gcHJvcG9zZWQgdGV4dCBpbiB0aGlzIG9uZSBiZWNhdXNlIHRoZSBn
dWlkYW5jZSB0byBpbmNsdWRlIHByb3Bvc2VkIHRleHQgaGFwcGVuZWQgYWZ0ZXIgdGhpcyB0aWNr
ZXQgd2FzIGNsb3NlZC4NCg0KUmVnYXJkcywNCg0KU3RldmUNCk9uIDMvNy8xNCA0OjMyIFBNLCBk
aW1lIGlzc3VlIHRyYWNrZXIgd3JvdGU6DQoNCiMzMjogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3Rh
bXAgdmFsdWVzIHdpdGhpbiBPQy1PTFINCg0KDQoNCg0KDQpDb21tZW50IChieSBzcmRvbm92YW5A
dXNkb25vdmFucy5jb208bWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbT4pOg0KDQoNCg0K
IEZ1cnRoZXIgdXBkYXRlZCB0byBjaGFuZ2UgInByZXZpb3VzbHkgcmVjaWV2ZWQiIHRvICJjdXJy
ZW50bHkgYWN0aXZlDQoNCiBvdmVybG9hZCByZXBvcnQiLg0KDQoNCg0KIFRoZSBuZXcgdGV4dCBp
cyBhcyBmb2xsb3dzOg0KDQoNCg0KIEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSB0aGUgc2FtZSBP
Qy1PTFIgQVZQIG11bHRpcGxlIHRpbWVzIGJldHdlZW4gdGhlDQoNCiBvdmVybG9hZCBjb250cm9s
IGVuZHBvaW50cywgaG93ZXZlciwgd2hlbiB0aGUgT0MtT0xSIEFWUCBjb250ZW50IGNoYW5nZXMN
Cg0KIG9yIHRoZQ0KDQogc2VuZGluZyBlbmRwb2ludCBvdGhlcndpc2Ugd2FudHMgdGhlIHJlY2Vp
dmluZyBlbmRwb2ludCB0byB1cGRhdGUNCg0KIGl0cyBvdmVybG9hZCBjb250cm9sIGluZm9ybWF0
aW9uIGluIGFuIGFjdGl2ZSBvdmVybG9hZCByZXBvcnQsDQoNCiB0aGVuIHRoZSBPQy1TZXF1ZW5j
ZS1OdW1iZXIgQVZQIE1VU1QgY29udGFpbg0KDQogYSBuZXcgdmFsdWUgd2hpY2ggaXMgZ3JlYXRl
ciB0aGFuIHRoZSBsYXN0IHZhbHVlIHJlY2VpdmVkIGZvciB0aGF0DQoNCiBvdmVybG9hZCByZXBv
cnQuDQoNCiBUaGUgcmVjZWl2ZXIgU0hPVUxEIGRpc2NhcmQgYW4gT0MtT0xSIEFWUCB3aXRoIGEg
c2VxdWVuY2UgbnVtYmVyIHRoYXQgaXMNCg0KIGxlc3MgdGhhbiBvciBlcXVhbCB0byBhbnkgY3Vy
cmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgcHJldmlvdXNseQ0KDQogcmVjZWl2ZWQgZnJv
bSB0aGUgcmVwb3J0aW5nIG5vZGUuDQoNCg0KDQo=

--_000_087A34937E64E74E848732CFF8354B920978A9DEESESSMB101erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA
Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg
MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv
Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw
MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs
InNlcmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z
by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl
cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M
IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29s
b3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJ
Y29sb3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3
OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg
Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs
YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8
L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y
PSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj
bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GaW5lIGZvciBtZTxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz
dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6
My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndpbmRvd3RleHQiPiBEaU1FIFttYWlsdG86ZGltZS1i
b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TdGV2ZSBEb25vdmFuPGJyPg0K
PGI+U2VudDo8L2I+IHZpZXJuZXMsIDA3IGRlIG1hcnpvIGRlIDIwMTQgMTc6NDQ8YnI+DQo8Yj5U
bzo8L2I+IGRpbWVAaWV0Zi5vcmc7IGxpb25lbC5tb3JhbmRAb3JhbmdlLWZ0Z3JvdXAuY29tPGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRGltZV0gW2RpbWVdICMzMiAoZHJhZnQtZG9jZHQtZGlt
ZS1vdmxpKTogU2VxdWVuY2UtTnVtYmVyIFRpbWUtU3RhbXAgdmFsdWVzIHdpdGhpbiBPQy1PTFI8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy
Z2luLWJvdHRvbToxMi4wcHQiPkFsbCw8YnI+DQo8YnI+DQpPbmUgbm90ZSBvbiB0aGVzZSBjaGFu
Z2VzIHRvIHRoZSBkcmFmdCBiYXNlZCBvbiBpc3N1ZSAjMzIuJm5ic3A7IFRoaXMgaXNzdWUgd2Fz
IGNsb3NlZCB3aXRob3V0IHByb3Bvc2luZyBhbHRlcm5hdGl2ZSB0ZXh0LCBzbyBJIGhhdmUgdGFr
ZW4gdGhlIGxpYmVydHkgb2YgcHJvcG9zaW5nIHRoZSB0ZXh0IGluY2x1ZGVkIGluIHRoZXNlIG1l
c3NhZ2VzLjxicj4NCjxicj4NCklmIEkgaGF2ZSBtaXNzZWQgdGhlIG1hcmsgb24gdGhpcyB3b3Jk
aW5nIHBsZWFzZSByZS1vcGVuIHRoZSB0aWNrZXQuPGJyPg0KPGJyPg0KSSBiZWxpZXZlIHRoZXJl
IGlzIG5vIHByb3Bvc2VkIHRleHQgaW4gdGhpcyBvbmUgYmVjYXVzZSB0aGUgZ3VpZGFuY2UgdG8g
aW5jbHVkZSBwcm9wb3NlZCB0ZXh0IGhhcHBlbmVkIGFmdGVyIHRoaXMgdGlja2V0IHdhcyBjbG9z
ZWQuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpTdGV2ZTxvOnA+PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDMvNy8xNCA0OjMyIFBNLCBkaW1lIGlzc3Vl
IHRyYWNrZXIgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4jMzI6IFNlcXVl
bmNlLU51bWJlciBUaW1lLVN0YW1wIHZhbHVlcyB3aXRoaW4gT0MtT0xSPG86cD48L286cD48L3By
ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48
L3ByZT4NCjxwcmU+Q29tbWVudCAoYnkgPGEgaHJlZj0ibWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92
YW5zLmNvbSI+c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tPC9hPik6PG86cD48L286cD48L3ByZT4N
CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+IEZ1cnRoZXIgdXBkYXRlZCB0byBj
aGFuZ2UgJnF1b3Q7cHJldmlvdXNseSByZWNpZXZlZCZxdW90OyB0byAmcXVvdDtjdXJyZW50bHkg
YWN0aXZlPG86cD48L286cD48L3ByZT4NCjxwcmU+IG92ZXJsb2FkIHJlcG9ydCZxdW90Oy48bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT4gVGhlIG5l
dyB0ZXh0IGlzIGFzIGZvbGxvd3M6PG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8
L286cD48L3ByZT4NCjxwcmU+IEl0IGlzIHBvc3NpYmxlIHRvIHJlcGxheSB0aGUgc2FtZSBPQy1P
TFIgQVZQIG11bHRpcGxlIHRpbWVzIGJldHdlZW4gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+
IG92ZXJsb2FkIGNvbnRyb2wgZW5kcG9pbnRzLCBob3dldmVyLCB3aGVuIHRoZSBPQy1PTFIgQVZQ
IGNvbnRlbnQgY2hhbmdlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiBvciB0aGU8bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT4gc2VuZGluZyBlbmRwb2ludCBvdGhlcndpc2Ugd2FudHMgdGhlIHJlY2Vp
dmluZyBlbmRwb2ludCB0byB1cGRhdGU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gaXRzIG92ZXJs
b2FkIGNvbnRyb2wgaW5mb3JtYXRpb24gaW4gYW4gYWN0aXZlIG92ZXJsb2FkIHJlcG9ydCw8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT4gdGhlbiB0aGUgT0MtU2VxdWVuY2UtTnVtYmVyIEFWUCBNVVNU
IGNvbnRhaW48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gYSBuZXcgdmFsdWUgd2hpY2ggaXMgZ3Jl
YXRlciB0aGFuIHRoZSBsYXN0IHZhbHVlIHJlY2VpdmVkIGZvciB0aGF0PG86cD48L286cD48L3By
ZT4NCjxwcmU+IG92ZXJsb2FkIHJlcG9ydC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4gVGhlIHJl
Y2VpdmVyIFNIT1VMRCBkaXNjYXJkIGFuIE9DLU9MUiBBVlAgd2l0aCBhIHNlcXVlbmNlIG51bWJl
ciB0aGF0IGlzPG86cD48L286cD48L3ByZT4NCjxwcmU+IGxlc3MgdGhhbiBvciBlcXVhbCB0byBh
bnkgY3VycmVudGx5IGFjdGl2ZSBvdmVybG9hZCByZXBvcnQgcHJldmlvdXNseTxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiByZWNlaXZlZCBmcm9tIHRoZSByZXBvcnRpbmcgbm9kZS48bzpwPjwvbzpw
PjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N
CjwvaHRtbD4NCg==

--_000_087A34937E64E74E848732CFF8354B920978A9DEESESSMB101erics_--


From nobody Sat Mar  8 02:11:47 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 877C81A0258 for ; Sat,  8 Mar 2014 02:11:45 -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 s5Lnv_Dy-gBx for ; Sat,  8 Mar 2014 02:11:44 -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 D4FDA1A0250 for ; Sat,  8 Mar 2014 02:11:43 -0800 (PST)
Received: from localhost ([127.0.0.1]:40847 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEE8-0007dw-Dz; Sat, 08 Mar 2014 11:11:32 +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: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:11:32 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/50#comment:2
Message-ID: <090.78e4ad8d9db42d98d67f99475a2f233e@trac.tools.ietf.org>
References: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
X-Trac-Ticket-ID: 50
In-Reply-To: <075.da0c5efd096e353975a7634294e686ff@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YMb4jjdbBPN4Jn8iaxcrR_R12os
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #50 (draft-docdt-dime-ovli): OC-OLR AVP implicit info
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: Sat, 08 Mar 2014 10:11:45 -0000

#50: OC-OLR AVP implicit info


Comment (by srdonovan@usdonovans.com):

 Change made with minor editorial changes as follows:

 The OC-OLR AVP does not explicitly contain all information needed by the
 reacting node to decide whether a subsequent request must undergo a
 throttling process with the received reduction percentage.   The value of
 the OC-Report-Type AVP within the OC-OLR AVP indicates which
 implicit information is relevant for this decision (see clause 4.6).

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  maria.cruz.bartolome@ericsson.com  |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:  1.0
 Severity:  Active WG Document       |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:17:22 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 8FD601A0258 for ; Sat,  8 Mar 2014 02:17:21 -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 bBdL2olaATWH for ; Sat,  8 Mar 2014 02:17:20 -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 37DBD1A015B for ; Sat,  8 Mar 2014 02:17:20 -0800 (PST)
Received: from localhost ([127.0.0.1]:41131 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEJd-00044Z-NH; Sat, 08 Mar 2014 11:17:14 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:17:13 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/51#comment:2
Message-ID: <090.ea604a40ac5347fd7d84481d9f564fa0@trac.tools.ietf.org>
References: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 51
In-Reply-To: <075.edaabec86a9d8f96dc7c8731cb6d4ef2@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.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/7mlmTWevKFV29Q_f6acv62itHNQ
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #51 (draft-docdt-dime-ovli): OC-Supported-Features in requests
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: Sat, 08 Mar 2014 10:17:21 -0000

#51: OC-Supported-Features in requests


Comment (by srdonovan@usdonovans.com):

 Changed from SHOULD to MUST but removed the word request as we have agreed
 that the OC-Supported-Features AVP must be in all requests and answers.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |       Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  major                              |      Status:  closed
Component:  draft-docdt-dime-ovli              |   Milestone:
 Severity:  Active WG Document                 |     Version:  1.0
 Keywords:                                     |  Resolution:  fixed
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:26:24 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 42E9A1A0254 for ; Sat,  8 Mar 2014 02:26:22 -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 4pFiSj1CfeBN for ; Sat,  8 Mar 2014 02:26:20 -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 AE6AB1A01E6 for ; Sat,  8 Mar 2014 02:26:20 -0800 (PST)
Received: from localhost ([127.0.0.1]:41975 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMESN-0007IP-Hu; Sat, 08 Mar 2014 11:26:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:26:15 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/52#comment:2
Message-ID: <090.e07e7d2aaf47922204717e73fbc9cf36@trac.tools.ietf.org>
References: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
X-Trac-Ticket-ID: 52
In-Reply-To: <075.fdee2d1220a4dd797b0b12767aebd1cf@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: maria.cruz.bartolome@ericsson.com, srdonovan@usdonovans.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/D38O5o4xkjusOAu-m5ayeSJwNf8
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #52 (draft-docdt-dime-ovli): Throttling not needed to be based on previous history
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: Sat, 08 Mar 2014 10:26:22 -0000

#52: Throttling not needed to be based on previous history


Comment (by srdonovan@usdonovans.com):

 Update made.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |       Owner:  MCruz
     Type:  defect                             |  Bartolomé
 Priority:  major                              |      Status:  closed
Component:  draft-docdt-dime-ovli              |   Milestone:
 Severity:  Active WG Document                 |     Version:  1.0
 Keywords:                                     |  Resolution:  fixed
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:28:35 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 C745F1A01E6 for ; Sat,  8 Mar 2014 02:28:32 -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 s7JevIkGNDjL for ; Sat,  8 Mar 2014 02:28:31 -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 E6F9F1A015B for ; Sat,  8 Mar 2014 02:28:30 -0800 (PST)
Received: from localhost ([127.0.0.1]:42010 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEUP-0000dv-IX; Sat, 08 Mar 2014 11:28:21 +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: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:28:21 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/47#comment:2
Message-ID: <072.7f5058fec9ca3621165bf9b0e4bc69c3@trac.tools.ietf.org>
References: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 47
In-Reply-To: <057.6f1ee674941c8e6f852041883b135c9c@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rK2KcHE_G0BzerQA1rrjFzLjsC0
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #47 (draft-docdt-dime-ovli): reduction percentages greater than 100 should be ignored
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: Sat, 08 Mar 2014 10:28:33 -0000

#47: reduction percentages greater than 100 should be ignored


Comment (by srdonovan@usdonovans.com):

 Change made as indicated.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:32:29 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 8BE301A0265 for ; Sat,  8 Mar 2014 02:32:28 -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 Rd-d46MdRpsv for ; Sat,  8 Mar 2014 02:32:27 -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 1ED3E1A01E6 for ; Sat,  8 Mar 2014 02:32:27 -0800 (PST)
Received: from localhost ([127.0.0.1]:42117 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEYD-000601-MM; Sat, 08 Mar 2014 11:32:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:32:17 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/24#comment:1
Message-ID: <081.3132d0333788fadc69631749fc81b009@trac.tools.ietf.org>
References: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 24
In-Reply-To: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mXgdqbePILOdvMR5C5vJjCfW5Cw
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #24 (draft-docdt-dime-ovli): Terminology and Abbreviations
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: Sat, 08 Mar 2014 10:32:28 -0000

#24: Terminology and Abbreviations

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Agreed – Remove definition of Diameter layer load balancing.
 Agreed – Remove definition of Topology Hiding.
 Agreed – Remove discussion of agents acting as topology hiders or server
 front ends.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  closed
 Priority:  minor                    |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:
 Severity:  Submitted WG Document    |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:33:04 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 4E74F1A0265 for ; Sat,  8 Mar 2014 02:33: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 eRUaqHRbjkFR for ; Sat,  8 Mar 2014 02:33:02 -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 EC68A1A015B for ; Sat,  8 Mar 2014 02:33:01 -0800 (PST)
Received: from localhost ([127.0.0.1]:42128 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEYo-00061I-VV; Sat, 08 Mar 2014 11:32:54 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:32:54 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/24#comment:2
Message-ID: <081.d44b84c57d8c3e7545b77f8f4b77e7ba@trac.tools.ietf.org>
References: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 24
In-Reply-To: <066.30fbf9b68075ea84e4d6fcf5261cf53e@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1F98jcpKSaHQAZzx_MJosNxqXbE
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #24 (draft-docdt-dime-ovli): Terminology and Abbreviations
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: Sat, 08 Mar 2014 10:33:03 -0000

#24: Terminology and Abbreviations


Comment (by srdonovan@usdonovans.com):

 Updated as indicated.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  closed
 Priority:  minor                    |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:
 Severity:  Submitted WG Document    |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:37:52 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 6A7881A026B for ; Sat,  8 Mar 2014 02:37:50 -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 8Owk2xfmjp2U for ; Sat,  8 Mar 2014 02:37:48 -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 A7CB01A015B for ; Sat,  8 Mar 2014 02:37:48 -0800 (PST)
Received: from localhost ([127.0.0.1]:42226 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEdN-0006h6-Gq; Sat, 08 Mar 2014 11:37:37 +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: draft-ietf-dime-app-design-guide@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:37:37 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/60
Message-ID: <066.25846a096050f4de0dae76f80a0a9d46@trac.tools.ietf.org>
X-Trac-Ticket-ID: 60
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-dime-app-design-guide@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: hannes.tschofenig@gmx.net, lionel.morand@orange.com, vf0213@gmail.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fpYo3LMW0tD_tQdDAekwYiTFcNY
Cc: dime@ietf.org
Subject: [Dime] [dime] #60 (app-design-guide): Agent Overload Report Handling considerations
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: Sat, 08 Mar 2014 10:37:50 -0000

#60: Agent Overload Report Handling considerations

 Need wording for a new section 5.5.4 on Agent handling of overload
 reports.

 This needs to address agent behavior when acting as a reacting node for
 non supporting clients, when acting as reporting node for a set of servers
 and for when the agent will be the reporting node for realm reports.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-app-
  srdonovan@usdonovans.com           |  design-guide@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  app-design-guide         |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:38:24 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 0D0691A0291 for ; Sat,  8 Mar 2014 02:38:23 -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 ZORE_qA7GtKC for ; Sat,  8 Mar 2014 02:38:21 -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 87FFB1A027B for ; Sat,  8 Mar 2014 02:38:21 -0800 (PST)
Received: from localhost ([127.0.0.1]:42243 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEdu-0006jP-24; Sat, 08 Mar 2014 11:38:10 +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: draft-ietf-dime-app-design-guide@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:38:10 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/61
Message-ID: <066.240dbe9c6b177a4db5db4535d22df5f1@trac.tools.ietf.org>
X-Trac-Ticket-ID: 61
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-dime-app-design-guide@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: hannes.tschofenig@gmx.net, lionel.morand@orange.com, vf0213@gmail.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QBYEdiNQRNdEak1vqhrAh3Za-LA
Cc: dime@ietf.org
Subject: [Dime] [dime] #61 (app-design-guide): Agent Capability Announcement Considerations
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: Sat, 08 Mar 2014 10:38:23 -0000

#61: Agent Capability Announcement Considerations

 Need new section 5.5.3 on agent considerations wrt Capability
 Announcement.

 This needs to address agent behavior when acting as a reacting node for
 non supporting clients, when acting as reporting node for a set of servers
 and for when the agent will be the reporting node for realm reports.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-dime-app-
  srdonovan@usdonovans.com           |  design-guide@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  app-design-guide         |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:41:49 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 D245A1A02B3 for ; Sat,  8 Mar 2014 02:41:47 -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 yUXriXHBD9WJ for ; Sat,  8 Mar 2014 02:41:46 -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 48CF21A026B for ; Sat,  8 Mar 2014 02:41:46 -0800 (PST)
Received: from localhost ([127.0.0.1]:42355 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEhC-0007Gd-Pq; Sat, 08 Mar 2014 11:41:35 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:41:34 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/60#comment:1
Message-ID: <081.5c9513b1ab3af738e7e38b797c98c1b3@trac.tools.ietf.org>
References: <066.25846a096050f4de0dae76f80a0a9d46@trac.tools.ietf.org>
X-Trac-Ticket-ID: 60
In-Reply-To: <066.25846a096050f4de0dae76f80a0a9d46@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2G8YFs1VT8AdJc01Vu1QqMyidCQ
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #60 (draft-docdt-dime-ovli): Agent Overload Report Handling considerations
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: Sat, 08 Mar 2014 10:41:48 -0000

#60: Agent Overload Report Handling considerations

Changes (by srdonovan@usdonovans.com):

 * owner:  draft-ietf-dime-app-design-guide@tools.ietf.org => draft-docdt-
     dime-ovli@tools.ietf.org
 * component:  app-design-guide => draft-docdt-dime-ovli


Comment:

 Moving report to correct document

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:42:24 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 BCB6F1A027B for ; Sat,  8 Mar 2014 02:42:23 -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 678t8MczPfrT for ; Sat,  8 Mar 2014 02:42:22 -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 3A1BE1A027A for ; Sat,  8 Mar 2014 02:42:22 -0800 (PST)
Received: from localhost ([127.0.0.1]:42377 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEhq-0007Sx-Si; Sat, 08 Mar 2014 11:42:14 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:42:14 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/61#comment:1
Message-ID: <081.11c33cfeca0264aad53f0b0b8f932493@trac.tools.ietf.org>
References: <066.240dbe9c6b177a4db5db4535d22df5f1@trac.tools.ietf.org>
X-Trac-Ticket-ID: 61
In-Reply-To: <066.240dbe9c6b177a4db5db4535d22df5f1@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tbACEljg9lfthHU6bxeHiKJotwo
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #61 (draft-docdt-dime-ovli): Agent Capability Announcement Considerations
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: Sat, 08 Mar 2014 10:42:24 -0000

#61: Agent Capability Announcement Considerations

Changes (by srdonovan@usdonovans.com):

 * owner:  draft-ietf-dime-app-design-guide@tools.ietf.org => draft-docdt-
     dime-ovli@tools.ietf.org
 * component:  app-design-guide => draft-docdt-dime-ovli


Comment:

 Moving ticket to correct document.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:
 Severity:  Active WG Document       |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:47:47 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 52EBE1A02B3 for ; Sat,  8 Mar 2014 02:47:46 -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 Bt1KDPVC3ZxZ for ; Sat,  8 Mar 2014 02:47:44 -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 04FCE1A027A for ; Sat,  8 Mar 2014 02:47:44 -0800 (PST)
Received: from localhost ([127.0.0.1]:42563 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEn1-0008D9-U0; Sat, 08 Mar 2014 11:47:35 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:47:35 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/28#comment:1
Message-ID: <081.d5fb7c344c53c3b4965d2b135a92e6be@trac.tools.ietf.org>
References: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org>
X-Trac-Ticket-ID: 28
In-Reply-To: <066.b908ffa610747388ec343de03f526af3@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9qyq0S87P0w1oBFKvLDIWKbEZWk
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #28 (draft-docdt-dime-ovli): Report type support in capabilities?
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: Sat, 08 Mar 2014 10:47:46 -0000

#28: Report type support in capabilities?

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 No changes required.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  closed
 Priority:  minor                    |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:
 Severity:  Submitted WG Document    |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:49: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 4B1FE1A0250 for ; Sat,  8 Mar 2014 02:49:54 -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 vEBksqpLssAn for ; Sat,  8 Mar 2014 02:49:52 -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 91C8D1A017B for ; Sat,  8 Mar 2014 02:49:52 -0800 (PST)
Received: from localhost ([127.0.0.1]:42595 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEp7-0004Be-1N; Sat, 08 Mar 2014 11:49:45 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:49:44 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/37#comment:1
Message-ID: <072.3f3f8a2dfef0bdb8e6704957868bc0d9@trac.tools.ietf.org>
References: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org>
X-Trac-Ticket-ID: 37
In-Reply-To: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rVUtAEIfadBKaZytjbfJfCYFo6Q
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #37 (draft-docdt-dime-ovli): Inconsistent name and abbreviation
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: Sat, 08 Mar 2014 10:49:54 -0000

#37: Inconsistent name and abbreviation

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Agreed to use the name DOIC.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  trivial      |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:50:22 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 C81B21A0258 for ; Sat,  8 Mar 2014 02:50:19 -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 qG0B2CrmKyLM for ; Sat,  8 Mar 2014 02:50:18 -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 8F2921A017B for ; Sat,  8 Mar 2014 02:50:18 -0800 (PST)
Received: from localhost ([127.0.0.1]:42633 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMEpX-0005G5-MW; Sat, 08 Mar 2014 11:50:11 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:50:11 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/37#comment:2
Message-ID: <072.0799c3cb4b2a1c1e3b7ffde0894b5bd0@trac.tools.ietf.org>
References: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org>
X-Trac-Ticket-ID: 37
In-Reply-To: <057.3a201a94252d25a27114080765cddc27@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7-7fryOPe1PfOJETgwapVHjvPMg
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #37 (draft-docdt-dime-ovli): Inconsistent name and abbreviation
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: Sat, 08 Mar 2014 10:50:19 -0000

#37: Inconsistent name and abbreviation


Comment (by srdonovan@usdonovans.com):

 Global change made.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  trivial      |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 02:52:15 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 603F91A017B for ; Sat,  8 Mar 2014 02:52:14 -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 YzlBTx12vW4K for ; Sat,  8 Mar 2014 02:52: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 CD15A1A0150 for ; Sat,  8 Mar 2014 02:52:12 -0800 (PST)
Received: from localhost ([127.0.0.1]:42712 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WMErD-0000B0-2U; Sat, 08 Mar 2014 11:51:55 +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: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Sat, 08 Mar 2014 10:51:55 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/39#comment:2
Message-ID: <072.f337219bc6da443dbb362467a4e43bc1@trac.tools.ietf.org>
References: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org>
X-Trac-Ticket-ID: 39
In-Reply-To: <057.f065e75bab4329d8222a3e0f41765194@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, ben@nostrum.com, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OzmEuWeHbrubuv9cDXXjhJ7EDVU
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #39 (draft-docdt-dime-ovli): Definition of Diameter Routing
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: Sat, 08 Mar 2014 10:52:14 -0000

#39: Definition of Diameter Routing

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of number 24.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  duplicate
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Sat Mar  8 03:09: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 EC6711A01C9 for ; Sat,  8 Mar 2014 03:09:10 -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_20=-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 HXw-tLVMmoJ3 for ; Sat,  8 Mar 2014 03:09:09 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id CA56D1A01E6 for ; Sat,  8 Mar 2014 03:09:09 -0800 (PST)
Received: from [31.55.35.252] (port=51442 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WMF7o-00009m-Kw for dime@ietf.org; Sat, 08 Mar 2014 03:09:05 -0800
Message-ID: <531AFA52.4070304@usdonovans.com>
Date: Sat, 08 Mar 2014 11:09:06 +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" 
Content-Type: multipart/alternative; boundary="------------080903090001080601050000"
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/DHRDJRKGy-O0WcfrsVQFtFwSYY0
Subject: [Dime] Tentative agreements from DIME meeting in IETF #89
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, 08 Mar 2014 11:09:11 -0000

This is a multi-part message in MIME format.
--------------080903090001080601050000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

The following were tentative agreements reached during the meeting in
London.

-----

Overload report types:

Agreed - Support two report types -- host as currently defined (requests
with a destination-host AVP) and realm (all requests). 

Proposal - Remove Realm-Routed-Request (requests without a
destination-host) report type.  Still an open issue.

Need to define the interaction between host and realm report types.

---

Client specific reports:

Agreed - Remove explicit ability of reporting node to send client
specific reports.  It was agreed that this feature should be treated as
a new report type that needs to be addressed as a separate extension.

---

OC-Supported-Features handling:

Agreed: OC-Supported-Features AVP MUST be included in all answer
messages (we had already agreed that it must be included in all request
messages).
Agreed: Reacting node advertises all supported algorithms;
Agreed: Reporting node responds with the single algorithm it will be using;
Agreed: Handling of other feature bits is defined in the extension drafts

---

OC-OLR handling:

Agreed: Single OC-OLR AVP used by all abatement algorithms with the
meaning of the overload report indicated in the OC-Supported-Features AVP.
Agreed: Put text in the draft to recommend that algorithms should not be
changed on the fly.

Regards,

Steve

--------------080903090001080601050000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      The following were tentative agreements reached during the meeting
      in London.

      

      -----

      

      Overload report types:

      

      Agreed - Support two report types -- host as currently defined
      (requests with a destination-host AVP) and realm (all requests). 
      

      

      Proposal - Remove Realm-Routed-Request (requests without a
      destination-host) report type.  Still an open issue.

      

      Need to define the interaction between host and realm report
      types.

      

      ---

      

      Client specific reports:

      

      Agreed - Remove explicit ability of reporting node to send client
      specific reports.  It was agreed that this feature should be
      treated as a new report type that needs to be addressed as a
      separate extension.

      

      ---

      

      OC-Supported-Features handling:

      

      Agreed: OC-Supported-Features AVP MUST be included in all answer
      messages (we had already agreed that it must be included in all
      request messages).

      Agreed: Reacting node advertises all supported algorithms;

      Agreed: Reporting node responds with the single algorithm it will
      be using;

      Agreed: Handling of other feature bits is defined in the extension
      drafts

      

      --- 

      

      OC-OLR handling:

      

      Agreed: Single OC-OLR AVP used by all abatement algorithms with
      the meaning of the overload report indicated in the
      OC-Supported-Features AVP.

      Agreed: Put text in the draft to recommend that algorithms should
      not be changed on the fly.

      

      Regards,

      

      Steve

    
  


--------------080903090001080601050000--


From nobody Sat Mar  8 03:19: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 652101A0258 for ; Sat,  8 Mar 2014 03:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 LiMyHQLogX7Y for ; Sat,  8 Mar 2014 03:19:03 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 966FD1A0114 for ; Sat,  8 Mar 2014 03:19:03 -0800 (PST)
Received: from [31.55.35.252] (port=51548 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WMFHO-0001yN-M8 for dime@ietf.org; Sat, 08 Mar 2014 03:18:59 -0800
Message-ID: <531AFCA4.1010408@usdonovans.com>
Date: Sat, 08 Mar 2014 11:19:00 +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" 
Content-Type: multipart/alternative; boundary="------------050905050805090608090202"
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/_wLkucKAHn5mbO-UgoPNAE2brsk
Subject: [Dime] Snapshot of -02 version of DOIC draft
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, 08 Mar 2014 11:19:04 -0000

This is a multi-part message in MIME format.
--------------050905050805090608090202
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

I have made updates to the -02 version of the DOIC draft based on
resolution to the following issues:

24, 32, 50, 51, 52, 47 and 37

I had also started to make updates for issues 29, 31 and 34 before we
agreed that the proposed text needs to be updated in the issue tracker
before the edits are made.  I'll clean up these updates when we have the
wording put into issue tracker.

To those who own issues in issue tracker, if we have resolution of the
issue on the mailing list please update issue tracker ASAP so the edits
can be put into the -02 draft.

Thanks,

Steve

--------------050905050805090608090202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      I have made updates to the -02 version of the DOIC draft based on
      resolution to the following issues:

      

      24, 32, 50, 51, 52, 47 and 37

      

      I had also started to make updates for issues 29, 31 and 34 before
      we agreed that the proposed text needs to be updated in the issue
      tracker before the edits are made.  I'll clean up these updates
      when we have the wording put into issue tracker.

      

      To those who own issues in issue tracker, if we have resolution of
      the issue on the mailing list please update issue tracker ASAP so
      the edits can be put into the -02 draft.

      

      Thanks,

      

      Steve

    
  


--------------050905050805090608090202--


From nobody Sat Mar  8 03:20:44 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 189B61A0258 for ; Sat,  8 Mar 2014 03:20:43 -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 med4pDCyzSjC for ; Sat,  8 Mar 2014 03:20:41 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id CCCE11A024B for ; Sat,  8 Mar 2014 03:20:41 -0800 (PST)
Received: from [31.55.35.252] (port=51554 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WMFIx-0003Z1-NU for dime@ietf.org; Sat, 08 Mar 2014 03:20:37 -0800
Message-ID: <531AFD05.1030203@usdonovans.com>
Date: Sat, 08 Mar 2014 11:20: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: dime@ietf.org
References: <531AFCA4.1010408@usdonovans.com>
In-Reply-To: <531AFCA4.1010408@usdonovans.com>
Content-Type: multipart/alternative; boundary="------------000607090103040307030902"
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/KEKbFBgiQBy3bC11beHPgfWPumA
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 08 Mar 2014 11:20:43 -0000

This is a multi-part message in MIME format.
--------------000607090103040307030902
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

One other thing, the latest snapshot can be found here:

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-02.txt

This is very much a work in progress with a number of items that will
need to be cleaned up before it is submitted to the IETF.

Steve

On 3/8/14 11:19 AM, Steve Donovan wrote:
> All,
>
> I have made updates to the -02 version of the DOIC draft based on
> resolution to the following issues:
>
> 24, 32, 50, 51, 52, 47 and 37
>
> I had also started to make updates for issues 29, 31 and 34 before we
> agreed that the proposed text needs to be updated in the issue tracker
> before the edits are made.  I'll clean up these updates when we have
> the wording put into issue tracker.
>
> To those who own issues in issue tracker, if we have resolution of the
> issue on the mailing list please update issue tracker ASAP so the
> edits can be put into the -02 draft.
>
> Thanks,
>
> Steve
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------000607090103040307030902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    One other thing, the latest
      snapshot can be found here:

      

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-02.txt

      

      This is very much a work in progress with a number of items that
      will need to be cleaned up before it is submitted to the IETF. 

      

      Steve

      

    
    
On 3/8/14 11:19 AM, Steve Donovan
      wrote:

    

    

      
      All,

        

        I have made updates to the -02 version of the DOIC draft based
        on resolution to the following issues:

        

        24, 32, 50, 51, 52, 47 and 37

        

        I had also started to make updates for issues 29, 31 and 34
        before we agreed that the proposed text needs to be updated in
        the issue tracker before the edits are made.  I'll clean up
        these updates when we have the wording put into issue tracker.

        

        To those who own issues in issue tracker, if we have resolution
        of the issue on the mailing list please update issue tracker
        ASAP so the edits can be put into the -02 draft.

        

        Thanks,

        

        Steve

       

      

      

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


    

    

  


--------------000607090103040307030902--


From nobody Sat Mar  8 03:34:28 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 496F71A0114 for ; Sat,  8 Mar 2014 03:34:25 -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 Z3Eepb9Mfc3K for ; Sat,  8 Mar 2014 03:34:22 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 295F21A012A for ; Sat,  8 Mar 2014 03:34:21 -0800 (PST)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-47-531b00385a5c
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 52.B7.10875.8300B135; Sat,  8 Mar 2014 12:34:16 +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; Sat, 8 Mar 2014 12:34:16 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Tentative agreements from DIME meeting in IETF #89
Thread-Index: AQHPOr7UIAZwhG6to0W2unjRGr77w5rXDenQ
Date: Sat, 8 Mar 2014 11:34:15 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978AD49@ESESSMB101.ericsson.se>
References: <531AFA52.4070304@usdonovans.com>
In-Reply-To: <531AFA52.4070304@usdonovans.com>
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_087A34937E64E74E848732CFF8354B920978AD49ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja4Fg3SwwZ3TJhZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGXO+bWAs2GhTceL1ZrYGxm6TLkYODgkBE4nl z9W7GDmBTDGJC/fWs3UxcnEICRxilFh56xArhLOIUWLC+rOMIFVsAnYSl06/YAKxRQR8JY53 nmYBsYUF3CTut/cxQ8TdJc5+XsYIYRtJrDnzgQVkGYuAisTXCaYgYV6g1paWp2AlQgK6ElO7 XoCN4RTQk7j2vgdsPCPQQd9PrQGzmQXEJW49mc8EcaiAxJI955khbFGJl4//sULYShJrD29n gajPl3i5+ggTxC5BiZMzn7BMYBSZhWTULCRls5CUQcT1JG5MncIGYWtLLFv4mhnC1pWY8e8Q C7L4Akb2VYzsuYmZOenlhpsYgXFzcMtv3R2Mp86JHGKU5mBREuf98NY5SEggPbEkNTs1tSC1 KL6oNCe1+BAjEwenVANjy8XcoMtT7i7a68JcunTxxe9i2eUxRV9K//z74NVrLlrA0FN++oTz 0gfzfCoSwnkuJGup/uhS84zsvco8bcbqQ+kH9kxnvX9e/e7xfz9ml05k+qC9qGjL71cf01dM O/Ka10Lj8xW1iUlJXFp+37yOTmk8oPspt3zD8RNcd58fzFgZx3meQyEvQYmlOCPRUIu5qDgR AIBIpWdpAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xonayIQ_CSIyPmX7ZRAnWUEmDYA
Subject: Re: [Dime] Tentative agreements from DIME meeting in IETF #89
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, 08 Mar 2014 11:34:25 -0000

--_000_087A34937E64E74E848732CFF8354B920978AD49ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Steve,

See comments below
Thanks for the updates and summary
Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: s=E1bado, 08 de marzo de 2014 12:09
To: dime@ietf.org
Subject: [Dime] Tentative agreements from DIME meeting in IETF #89

All,

The following were tentative agreements reached during the meeting in Londo=
n.

-----

Overload report types:

Agreed - Support two report types -- host as currently defined (requests wi=
th a destination-host AVP) and realm (all requests).

Proposal - Remove Realm-Routed-Request (requests without a destination-host=
) report type.  Still an open issue.

Need to define the interaction between host and realm report types.

---

Client specific reports:

Agreed - Remove explicit ability of reporting node to send client specific =
reports.  It was agreed that this feature should be treated as a new report=
 type that needs to be addressed as a separate extension.
[MCruz] It was pre-agreed that it could be considered as an extension. In m=
y opinion, we do not reach an agreement on the way to do it, we simply pres=
ented what has already been discussed in the list till this moment.
---

OC-Supported-Features handling:

Agreed: OC-Supported-Features AVP MUST be included in all answer messages (=
we had already agreed that it must be included in all request messages).
Agreed: Reacting node advertises all supported algorithms;
Agreed: Reporting node responds with the single algorithm it will be using;
Agreed: Handling of other feature bits is defined in the extension drafts

---

OC-OLR handling:

Agreed: Single OC-OLR AVP used by all abatement algorithms with the meaning=
 of the overload report indicated in the OC-Supported-Features AVP.
Agreed: Put text in the draft to recommend that algorithms should not be ch=
anged on the fly.

Regards,

Steve

--_000_087A34937E64E74E848732CFF8354B920978AD49ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Steve,



 <=
/p>

See comments below


Thanks for the updates an=
d summary


Best regards


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: s=E1bado, 08 de marzo de 2014 12:09

To: dime@ietf.org

Subject: [Dime] Tentative agreements from DIME meeting in IETF #89






 


All,



The following were tentative agreements reached during the meeting in Londo=
n.



-----



Overload report types:



Agreed - Support two report types -- host as currently defined (requests wi=
th a destination-host AVP) and realm (all requests). 




Proposal - Remove Realm-Routed-Request (requests without a destination-host=
) report type.  Still an open issue.



Need to define the interaction between host and realm report types.



---



Client specific reports:



Agreed - Remove explicit ability of reporting node to send client specific =
reports.  It was agreed that this feature should be treated as a new r=
eport type that needs to be addressed as a separate extension.

[MCruz] It was pre-agreed that it could be co=
nsidered as an extension. In my opinion, we do not reach an agreement on th=
e way to do it, we simply presented what has already been discussed in the =
list till this moment.

---



OC-Supported-Features handling:



Agreed: OC-Supported-Features AVP MUST be included in all answer messages (=
we had already agreed that it must be included in all request messages).
Agreed: Reacting node advertises all supported algorithms;

Agreed: Reporting node responds with the single algorithm it will be using;=


Agreed: Handling of other feature bits is defined in the extension drafts


--- 



OC-OLR handling:



Agreed: Single OC-OLR AVP used by all abatement algorithms with the meaning=
 of the overload report indicated in the OC-Supported-Features AVP.

Agreed: Put text in the draft to recommend that algorithms should not be ch=
anged on the fly.



Regards,



Steve






--_000_087A34937E64E74E848732CFF8354B920978AD49ESESSMB101erics_--


From nobody Tue Mar 11 05:06: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 37BAC1A0716 for ; Tue, 11 Mar 2014 05:06:57 -0700 (PDT)
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 bRRPfoXUS6xZ for ; Tue, 11 Mar 2014 05:06:54 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7101A068D for ; Tue, 11 Mar 2014 05:06:53 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-92-531efc565f19
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 39.E1.10875.65CFE135; Tue, 11 Mar 2014 13:06:47 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.28]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Tue, 11 Mar 2014 13:06:46 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Snapshot of -02 version of DOIC draft
Thread-Index: AQHPOsA2dYgrcAw7T0W7J1ZKE/2avprbzrfQ
Date: Tue, 11 Mar 2014 12:06:46 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se>
References: <531AFCA4.1010408@usdonovans.com>
In-Reply-To: <531AFCA4.1010408@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920978BCDAESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+JvjW74H7lggxltUhZze1ewWWxo4nFg 8liy5CeTx6q3fawBTFFcNimpOZllqUX6dglcGQ/v9DAXPM2ouHLqLEsD49+YLkZODgkBE4mt U9rZIGwxiQv31gPZXBxCAocYJR7u+MgMkhASWMwo8ewcB4jNJmAncen0CyYQW0TAV+J452kW EFtYwFLi++GzrBBxK4nPy1ezQ9hGEnuO9oHVswioSvya+gYozsHBC9Q7Z7svxHhdicNf1zKC hDkF9CQmPUgBCTMCnfP91BqwTmYBcYlbT+YzQZwpILFkz3lmCFtU4uXjf6wgrRICihLL++Ug yvMlWqfcBDuGV0BQ4uTMJywTGEVmIZk0C0nZLCRlEHE9iRtTp7BB2NoSyxa+ZoawdSVm/DvE giy+gJF9FSN7bmJmTnq54SZGYMwc3PJbdwfjqXMihxilOViUxHk/vHUOEhJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAo+S7LKiXs8eqbMwtYtlbsW5lv4fg/9rFGrMXmCLZnJ+pTlrAF9jR5 t5u6WXYZyL8uVFw2g2+lakfxxA0xwY8XFYe3HPz84Fz46jcLz8ps0pSZoaf9yCH/0Qyj3aan L3OzHOOr/xaQbXx5ScaqJ0Gq6uzbvvlc/7agb9+vkBg57v9SS5ZxzXutxFKckWioxVxUnAgA qpgoHmcCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/g4ynNixYxUKLYM-YAQ3eoUlnua4
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 11 Mar 2014 12:06:57 -0000

--_000_087A34937E64E74E848732CFF8354B920978BCDAESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Steve,

According to conclusion on #Issue 51: OC-Supported-Feature AVP MUST be incl=
uded in all request messages sent by a DOIC supporting node. (not yet agree=
d).

Text marked in green below requires updates:

5.3.1.  Reacting Node Endpoint Considerations

   The basic principle is that the request message initiating endpoint
   (i.e. the "reacting node") announces its support for the overload
   control mechanism by including in the request message the OC-
   Supported-Features AVP with those capabilities it supports and is
   willing to use for this Diameter session (or transaction in a case of
   a non-session state maintaining applications, see Section 3.1.2 for
   more details on Diameter sessions).  It is RECOMMENDED that the
   request message initiating endpoint includes the capability
   announcement into every request regardless it has had prior message
   exchanges with the give remote endpoint.  In a case of a Diameter
   session maintaining application, sending the OC-Supported-Features
   AVP in every message is not really necessary after the initial
   capability announcement or until there is a change in supported
   features.

   Once the endpoint that initiated the request message receives an
   answer message from the remote endpoint, it can detect from the
   received answer message whether the remote endpoint supports the
   overload control solution and in a case it does, what features are
   supported.  The support for the overload control solution is based on
   the presence of the OC-Supported-Features AVP in the Diameter answer
   for existing application.


Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: s=E1bado, 08 de marzo de 2014 12:19
To: dime@ietf.org
Subject: [Dime] Snapshot of -02 version of DOIC draft

All,

I have made updates to the -02 version of the DOIC draft based on resolutio=
n to the following issues:

24, 32, 50, 51, 52, 47 and 37

I had also started to make updates for issues 29, 31 and 34 before we agree=
d that the proposed text needs to be updated in the issue tracker before th=
e edits are made.  I'll clean up these updates when we have the wording put=
 into issue tracker.

To those who own issues in issue tracker, if we have resolution of the issu=
e on the mailing list please update issue tracker ASAP so the edits can be =
put into the -02 draft.

Thanks,

Steve

--_000_087A34937E64E74E848732CFF8354B920978BCDAESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Steve,


 <=
/p>

According to conclusion o=
n #Issue 51: OC-Supported-Feature AVP MUST be included in all request messa=
ges sent by a DOIC supporting node. (not yet agreed).


 <=
/p>

Text marked in green belo=
w requires updates:


 <=
/p>

5.3.1.  Reacting Nod=
e Endpoint Considerations


 <=
/p>

   The basic pr=
inciple is that the request message initiating endpoint

   (i.e. the &q=
uot;reacting node") announces its support for the overload<=
/span>


   control mech=
anism by including in the request message the OC-


   Supported-Fe=
atures AVP with those capabilities it supports and is


   willing to u=
se for this Diameter session (or transaction in a case of=



   a non-sessio=
n state maintaining applications, see Section 3.1.2 for

   more details=
 on Diameter sessions). 
It is RECOMMENDED that the


   request mess=
age initiating endpoint includes the capability


   announcement=
 into every request regardless it has had prior message

   exchanges wi=
th the give remote endpoint.  In a case of a Diameter


   session main=
taining application, sending the OC-Supported-Features

   AVP in every=
 message is not really necessary after the initial


   capability a=
nnouncement or until there is a change in supported


   features.


 <=
/p>

   Once the end=
point that initiated the request message receives an


   answer messa=
ge from the remote endpoint, it can detect from the


   received ans=
wer message whether the remote endpoint supports the


   overload con=
trol solution and in a case it does, what features are

   supported.&n=
bsp; The support for the overload control solution is based on


   the presence=
 of the OC-Supported-Features AVP in the Diameter answer<=
/p>

   for existing=
 application.


 <=
/p>

 <=
/p>

Best regards


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: s=E1bado, 08 de marzo de 2014 12:19

To: dime@ietf.org

Subject: [Dime] Snapshot of -02 version of DOIC draft






 


All,



I have made updates to the -02 version of the DOIC draft based on resolutio=
n to the following issues:



24, 32, 50, 51, 52, 47 and 37



I had also started to make updates for issues 29, 31 and 34 before we agree=
d that the proposed text needs to be updated in the issue tracker before th=
e edits are made.  I'll clean up these updates when we have the wordin=
g put into issue tracker.



To those who own issues in issue tracker, if we have resolution of the issu=
e on the mailing list please update issue tracker ASAP so the edits can be =
put into the -02 draft.



Thanks,



Steve






--_000_087A34937E64E74E848732CFF8354B920978BCDAESESSMB101erics_--


From nobody Mon Mar 17 10:12:10 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 B84801A044A for ; Mon, 17 Mar 2014 10:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.28
X-Spam-Level: 
X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 uxLQiY1rK6Sz for ; Mon, 17 Mar 2014 10:12:05 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id C627E1A0448 for ; Mon, 17 Mar 2014 10:12:05 -0700 (PDT)
Received: from [137.254.4.59] (port=8659 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPb4s-0002GL-5h; Mon, 17 Mar 2014 10:11:57 -0700
Message-ID: <53272CD9.9080904@usdonovans.com>
Date: Mon, 17 Mar 2014 12:11:53 -0500
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: Maria Cruz Bartolome ,  "dime@ietf.org" 
References: <531AFCA4.1010408@usdonovans.com> <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------030901060906090105010607"
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/GMPRZpLUIUbVUeN_l30muayoLpI
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 17 Mar 2014 17:12:08 -0000

This is a multi-part message in MIME format.
--------------030901060906090105010607
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Maria Cruz,

I updated the text based on what was put in the issue tracker when you
closed the issue.

Are you suggesting that this issue needs to be re-opened so we can
discuss whether OC-Supported-Features is needed in mid-session requests?

Steve

On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:
>
> Hello Steve,
>
>  
>
> According to conclusion on #Issue 51: OC-Supported-Feature AVP MUST be
> included in all request messages sent by a DOIC supporting node. (not
> yet agreed).
>
>  
>
> Text marked in green below requires updates:
>
>  
>
> 5.3.1.  Reacting Node Endpoint Considerations
>
>  
>
>    The basic principle is that the request message initiating endpoint
>
>    (i.e. the "reacting node") announces its support for the overload
>
>    control mechanism by including in the request message the OC-
>
>    Supported-Features AVP with those capabilities it supports and is
>
>    willing to use for this Diameter session (or transaction in a case of
>
>    a non-session state maintaining applications, see Section 3.1.2 for
>
>    more details on Diameter sessions).  It is RECOMMENDED that the
>
>    request message initiating endpoint includes the capability
>
>    announcement into every request regardless it has had prior message
>
>    exchanges with the give remote endpoint.  In a case of a Diameter
>
>    session maintaining application, sending the OC-Supported-Features
>
>    AVP in every message is not really necessary after the initial
>
>    capability announcement or until there is a change in supported
>
>    features.
>
>  
>
>    Once the endpoint that initiated the request message receives an
>
>    answer message from the remote endpoint, it can detect from the
>
>    received answer message whether the remote endpoint supports the
>
>    overload control solution and in a case it does, what features are
>
>    supported.  The support for the overload control solution is based on
>
>    the presence of the OC-Supported-Features AVP in the Diameter answer
>
>    for existing application.
>
>  
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* sábado, 08 de marzo de 2014 12:19
> *To:* dime@ietf.org
> *Subject:* [Dime] Snapshot of -02 version of DOIC draft
>
>  
>
> All,
>
> I have made updates to the -02 version of the DOIC draft based on
> resolution to the following issues:
>
> 24, 32, 50, 51, 52, 47 and 37
>
> I had also started to make updates for issues 29, 31 and 34 before we
> agreed that the proposed text needs to be updated in the issue tracker
> before the edits are made.  I'll clean up these updates when we have
> the wording put into issue tracker.
>
> To those who own issues in issue tracker, if we have resolution of the
> issue on the mailing list please update issue tracker ASAP so the
> edits can be put into the -02 draft.
>
> Thanks,
>
> Steve
>


--------------030901060906090105010607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      I updated the text based on what was put in the issue tracker when
      you closed the issue.

      

      Are you suggesting that this issue needs to be re-opened so we can
      discuss whether OC-Supported-Features is needed in mid-session
      requests?

      

      Steve

      

    
    
On 3/11/14 7:06 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello
            Steve,

        
 

        
According
            to conclusion on #Issue 51: OC-Supported-Feature AVP MUST be
            included in all request messages sent by a DOIC supporting
            node. (not yet agreed).

        
 

        
Text
            marked in green below requires updates:

        
 

        
5.3.1. 
            Reacting Node Endpoint Considerations

        
 

        
  
            The basic principle is that the request message initiating
            endpoint

        
  
            (i.e. the "reacting node") announces its support for the
            overload

        
  
            control mechanism by including in the request message the
            OC-

        
  
            Supported-Features AVP with those capabilities it supports
            and is

        
  
            willing to use for this Diameter session (or transaction in
            a case of

        
  
            a non-session state maintaining applications, see Section
            3.1.2 for

        
  
            more details on Diameter sessions). 
          It
            is RECOMMENDED that the

        
  
            request message initiating endpoint includes the capability

        
  
            announcement into every request regardless it has had prior
            message

        
  
            exchanges with the give remote endpoint.  In a case of a
            Diameter

        
  
            session maintaining application, sending the
            OC-Supported-Features

        
  
            AVP in every message is not really necessary after the
            initial

        
  
            capability announcement or until there is a change in
            supported

        
  
            features.

        
 

        
  
            Once the endpoint that initiated the request message
            receives an

        
  
            answer message from the remote endpoint, it can detect from
            the

        
  
            received answer message whether the remote endpoint supports
            the

        
  
            overload control solution and in a case it does, what
            features are

        
  
            supported.  The support for the overload control solution is
            based on

        
  
            the presence of the OC-Supported-Features AVP in the
            Diameter answer

        
  
            for existing application.

        
 

        
 

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Steve Donovan

                Sent: sábado, 08 de marzo de 2014 12:19

                To: dime@ietf.org

                Subject: [Dime] Snapshot of -02 version of DOIC
                draft

          

        

        
 

        
All,

          

          I have made updates to the -02 version of the DOIC draft based
          on resolution to the following issues:

          

          24, 32, 50, 51, 52, 47 and 37

          

          I had also started to make updates for issues 29, 31 and 34
          before we agreed that the proposed text needs to be updated in
          the issue tracker before the edits are made.  I'll clean up
          these updates when we have the wording put into issue tracker.

          

          To those who own issues in issue tracker, if we have
          resolution of the issue on the mailing list please update
          issue tracker ASAP so the edits can be put into the -02 draft.

          

          Thanks,

          

          Steve

      

    

    

  


--------------030901060906090105010607--


From nobody Mon Mar 17 10:16:30 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 D3D5F1A043C for ; Mon, 17 Mar 2014 10:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 wqIDHBRm-0OV for ; Mon, 17 Mar 2014 10:16:28 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC471A045F for ; Mon, 17 Mar 2014 10:16:09 -0700 (PDT)
Received: from [137.254.4.59] (port=16260 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPb8q-0007u0-1j for dime@ietf.org; Mon, 17 Mar 2014 10:16:00 -0700
Message-ID: <53272DCF.9020105@usdonovans.com>
Date: Mon, 17 Mar 2014 12:15:59 -0500
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" 
Content-Type: multipart/alternative; boundary="------------010704030202020206020707"
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/HfFZoRbds_fK9ECcDxnpKOiSoU4
Subject: [Dime] Closing DOIC issues
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, 17 Mar 2014 17:16:29 -0000

This is a multi-part message in MIME format.
--------------010704030202020206020707
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

We need to work to get the open issues on the DOIC draft closed.

The agreed to process was that the we use the DIME list to work towards
agreed text and that the agreed to text be included in the issue
tracker, preferably by the person who opened the issue. 

We have a number of issues that I believe we have agreed to text or we
are very close to having agreed to text.  If you own this issues, please
take the next step to close the issue. 

I'll also start working through the issues and try to identify those
that we can close.  I'll also try to re-initiate discussions on those
that need discussion.

Steve

--------------010704030202020206020707
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      We need to work to get the open issues on the DOIC draft closed.

      

      The agreed to process was that the we use the DIME list to work
      towards agreed text and that the agreed to text be included in the
      issue tracker, preferably by the person who opened the issue.  

      

      We have a number of issues that I believe we have agreed to text
      or we are very close to having agreed to text.  If you own this
      issues, please take the next step to close the issue.  

      

      I'll also start working through the issues and try to identify
      those that we can close.  I'll also try to re-initiate discussions
      on those that need discussion.

      

      Steve

    
  


--------------010704030202020206020707--


From nobody Mon Mar 17 10:25:47 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 A2D781A0424 for ; Mon, 17 Mar 2014 10:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.28
X-Spam-Level: 
X-Spam-Status: No, score=0.28 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 i188__VSPtW2 for ; Mon, 17 Mar 2014 10:25:44 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 568141A0453 for ; Mon, 17 Mar 2014 10:25:43 -0700 (PDT)
Received: from [137.254.4.59] (port=33023 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPbI4-0004Sv-0G; Mon, 17 Mar 2014 10:25:34 -0700
Message-ID: <5327300B.8010309@usdonovans.com>
Date: Mon, 17 Mar 2014 12:25:31 -0500
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: Maria Cruz Bartolome ,  "dime@ietf.org" 
References: <531AFA52.4070304@usdonovans.com> <087A34937E64E74E848732CFF8354B920978AD49@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978AD49@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------050705070104090108070609"
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/KXqCoGHN9y2gn-gZ1W_3Rah1D2Q
Subject: Re: [Dime] Tentative agreements from DIME meeting in IETF #89
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, 17 Mar 2014 17:25:45 -0000

This is a multi-part message in MIME format.
--------------050705070104090108070609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Maria Cruz,

Please see comments inline.

Steve

On 3/8/14 5:34 AM, Maria Cruz Bartolome wrote:
>
> Hello Steve,
>
>  
>
> See comments below
>
> Thanks for the updates and summary
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* sábado, 08 de marzo de 2014 12:09
> *To:* dime@ietf.org
> *Subject:* [Dime] Tentative agreements from DIME meeting in IETF #89
>
>  
>
> All,
>
> The following were tentative agreements reached during the meeting in
> London.
>
> -----
>
> Overload report types:
>
> Agreed - Support two report types -- host as currently defined
> (requests with a destination-host AVP) and realm (all requests). 
>
> Proposal - Remove Realm-Routed-Request (requests without a
> destination-host) report type.  Still an open issue.
>
> Need to define the interaction between host and realm report types.
>
> ---
>
> Client specific reports:
>
> Agreed - Remove explicit ability of reporting node to send client
> specific reports.  It was agreed that this feature should be treated
> as a new report type that needs to be addressed as a separate extension.
> [MCruz] It was pre-agreed that it could be considered as an extension.
> In my opinion, we do not reach an agreement on the way to do it, we
> simply presented what has already been discussed in the list till this
> moment.
>
srd> I agree that we did not discuss the actual mechanism as suggested
above.  The last sentence should be "It was agreed that this feature
should be addressed in a separate extension to DOIC.
>
> ---
>
> OC-Supported-Features handling:
>
> Agreed: OC-Supported-Features AVP MUST be included in all answer
> messages (we had already agreed that it must be included in all
> request messages).
> Agreed: Reacting node advertises all supported algorithms;
> Agreed: Reporting node responds with the single algorithm it will be
> using;
> Agreed: Handling of other feature bits is defined in the extension drafts
>
> ---
>
> OC-OLR handling:
>
> Agreed: Single OC-OLR AVP used by all abatement algorithms with the
> meaning of the overload report indicated in the OC-Supported-Features AVP.
> Agreed: Put text in the draft to recommend that algorithms should not
> be changed on the fly.
>
> Regards,
>
> Steve
>


--------------050705070104090108070609
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      Please see comments inline.

      

      Steve

      

    
    
On 3/8/14 5:34 AM, Maria Cruz Bartolome
      wrote:

    

    

      
      
      
      

        
Hello
            Steve,
            

        
 

        
See
            comments below

        
Thanks
            for the updates and summary

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Steve Donovan

                Sent: sábado, 08 de marzo de 2014 12:09

                To: dime@ietf.org

                Subject: [Dime] Tentative agreements from DIME
                meeting in IETF #89

          

        

        
 

        
All,

          

          The following were tentative agreements reached during the
          meeting in London.

          

          -----

          

          Overload report types:

          

          Agreed - Support two report types -- host as currently defined
          (requests with a destination-host AVP) and realm (all
          requests). 
          

          

          Proposal - Remove Realm-Routed-Request (requests without a
          destination-host) report type.  Still an open issue.

          

          Need to define the interaction between host and realm report
          types.

          

          ---

          

          Client specific reports:

          

          Agreed - Remove explicit ability of reporting node to send
          client specific reports.  It was agreed that this feature
          should be treated as a new report type that needs to be
          addressed as a separate extension.

          [MCruz] It was pre-agreed that it
            could be considered as an extension. In my opinion, we do
            not reach an agreement on the way to do it, we simply
            presented what has already been discussed in the list till
            this moment.

        

      

    

    srd> I agree that we did not discuss the actual mechanism as
    suggested above.  The last sentence should be "It was agreed that
    this feature should be addressed in a separate extension to DOIC.

    

      

        

          ---

          

          OC-Supported-Features handling:

          

          Agreed: OC-Supported-Features AVP MUST be included in all
          answer messages (we had already agreed that it must be
          included in all request messages).

          Agreed: Reacting node advertises all supported algorithms;

          Agreed: Reporting node responds with the single algorithm it
          will be using;

          Agreed: Handling of other feature bits is defined in the
          extension drafts

          

          --- 

          

          OC-OLR handling:

          

          Agreed: Single OC-OLR AVP used by all abatement algorithms
          with the meaning of the overload report indicated in the
          OC-Supported-Features AVP.

          Agreed: Put text in the draft to recommend that algorithms
          should not be changed on the fly.

          

          Regards,

          

          Steve

      

    

    

  


--------------050705070104090108070609--


From nobody Mon Mar 17 10:56: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 66ADB1A02F2 for ; Mon, 17 Mar 2014 10:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.8
X-Spam-Level: *
X-Spam-Status: No, score=1.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, 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 YxXaP1D6w7mL for ; Mon, 17 Mar 2014 10:56:05 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id ED9B11A01D5 for ; Mon, 17 Mar 2014 10:56:04 -0700 (PDT)
Received: from [137.254.4.59] (port=20863 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPblT-00069C-UZ for dime@ietf.org; Mon, 17 Mar 2014 10:55:56 -0700
Message-ID: <5327372B.1040600@usdonovans.com>
Date: Mon, 17 Mar 2014 12:55:55 -0500
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
CC: "dime@ietf.org list" 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net> <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com> <530BA310.4090100@usdonovans.com> <8BE5229D-E276-4084-B6EB-DBF89817E02F@nostrum.com>
In-Reply-To: <8BE5229D-E276-4084-B6EB-DBF89817E02F@nostrum.com>
Content-Type: multipart/alternative; boundary="------------090009090009020104010307"
X-OutGoing-Spam-Status: No, score=-1.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/cuNl4qVDlr9p_ZOffLRFjoOfePg
Subject: Re: [Dime] Issue#29 proposed 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, 17 Mar 2014 17:56:06 -0000

This is a multi-part message in MIME format.
--------------090009090009020104010307
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

All,

I believe we have consensus on this ticket.

I had put the following into my issue status document:

Agreed – Removed OC-Sequence-Number from OC-Supported-Features AVP.

Agreed – The scope of an OC-Supported-Features AVP is a single transaction.

Agreed – Diameter nodes that support DOIC must include the
OC-Supported-Features AVP in all requests.


I believe that this translates into the text changes outlined below.  If
we have agreement on the text below we can close the issue and I'll
update the text in the -02 draft accordingly.

Regards,

Steve

-----

Section 4.1:

Remove < OC-Sequence-Number >  from OC-Supported-Features syntax
description.

Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."

Section 4.4, Paragraph 1:

Remove reference to section 4.1.

Section 5.3.1, Paragraph 1:

Change:

It is RECOMMENDED that the
   request message initiating endpoint includes the capability
   announcement into every request regardless it has had prior message
   exchanges with the give remote endpoint. In a case of a Diameter
   session maintaining application, sending the OC-Supported-Features
   AVP in every message is not really necessary after the initial
   capability announcement or until there is a change in supported
   features. To: The lifetime of a capability announcement is limited to
a single transaction. As a result, the reacting node MUST include the
capability announcement in all request messages.









On 2/24/14 5:02 PM, Ben Campbell wrote:
> On Feb 24, 2014, at 1:52 PM, Steve Donovan  wrote:
>
>> I agree.
>>
>> I also think that we agreed that the lifetime of the OC-Supported-Features AVP is a single transaction and that the OC-Supported-Features AVP must be included in all requests originated by a Diameter node supporting DOIC.
> +1, and my previous agreement was based on that assumption.
>
>
>> Steve
>>
>> On 2/20/14 4:31 PM, Ben Campbell wrote:
>>> I concur with removing the sequence number from OC-Supported-Features.
>>>
>>>
>


--------------090009090009020104010307
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    All,

      

      I believe we have consensus on this ticket.

      

      I had put the following into my issue status document:

    

    
      
    
    
Agreed – Removed OC-Sequence-Number from
      OC-Supported-Features AVP.

    
Agreed – The scope of an OC-Supported-Features
      AVP is a
      single transaction.

    
Agreed – Diameter nodes that support DOIC must
      include the
      OC-Supported-Features AVP in all requests.

    
      
      
      
      
      
      
      
      
      
      
      

      I believe that this translates into the text changes outlined
      below.  If we have agreement on the text below we can close the
      issue and I'll update the text in the -02 draft accordingly.

      

      Regards,

      

      Steve

      

      -----

      

      Section 4.1:

      

      Remove < OC-Sequence-Number >  from OC-Supported-Features
      syntax description.

      

      Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."

      

      Section 4.4, Paragraph 1:

      

      Remove reference to section 4.1.

      

      Section 5.3.1, Paragraph 1:

      

      Change:

    

    
      
    
    
It is RECOMMENDED that the
   request message initiating endpoint includes the capability
   announcement into every request regardless it has had prior message
   exchanges with the give remote endpoint.  In a case of a Diameter
   session maintaining application, sending the OC-Supported-Features
   AVP in every message is not really necessary after the initial
   capability announcement or until there is a change in supported
   features.

To:

The lifetime of a capability announcement is limited to a single transaction.  As a result, the reacting 
node MUST include the capability announcement in all request messages.




    

      

      

      

      

    

      

    

    
On 2/24/14 5:02 PM, Ben Campbell wrote:

    

    

      
On Feb 24, 2014, at 1:52 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
I agree.

I also think that we agreed that the lifetime of the OC-Supported-Features AVP is a single transaction and that the OC-Supported-Features AVP must be included in all requests originated by a Diameter node supporting DOIC.


      

      
+1, and my previous agreement was based on that assumption.




      

        
Steve

On 2/20/14 4:31 PM, Ben Campbell wrote:


        

          
I concur with removing the sequence number from OC-Supported-Features.




        

        

      

      



    

    

  


--------------090009090009020104010307--


From nobody Mon Mar 17 10:59: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 538911A0444 for ; Mon, 17 Mar 2014 10:59:44 -0700 (PDT)
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 RJ0vXe4_czBF for ; Mon, 17 Mar 2014 10:59:42 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A931A01D5 for ; Mon, 17 Mar 2014 10:59:41 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2HHxWN9077455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2014 12:59:33 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org>
Date: Mon, 17 Mar 2014 12:59:32 -0500
X-Mao-Original-Outgoing-Id: 416771972.102098-6b13731749a25bc3bd257c2965d5b8a8
Content-Transfer-Encoding: quoted-printable
Message-Id: <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org>
To: dime@ietf.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dHLM86Ejgp_QxucxFkX82J77_xY
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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, 17 Mar 2014 17:59:44 -0000

Hi,

In the London meeting, I agreed that this issue was invalid based on =
statements in the room that the 6733 correct treatment of an unknown =
mandatory AVP inside a grouped AVP was to ignore the grouped AVP.

On rereading that section of RFC 6733, I disagree with that =
interpretation. Section 4.4 says:

> Receivers of a Grouped AVP that
>    does not have the 'M' (mandatory) bit set and one or more of the
>    encapsulated AVPs within the group has the 'M' (mandatory) bit set
>    MAY simply be ignored if the Grouped AVP itself is unrecognized.


That text only applies for _unrecognized_ grouped AVPs. The case in =
question is when you _recognize_ an optional grouped AVP, but do not =
recognize a mandatory AVP imbedded in it. The exception in 4.4 does not =
seem to cover that case.

So I no longer believe that the issue is invalid. I think the best =
option is to simply forbid setting of the m-bit on any DOIC related AVP.

To address other comments on the issue:

Consider the case of a Diameter _relay_ that supports DOIC. It is not =
aware of any application-specific rules about m-bits. It receives an =
OC-Supported-Features or an OC-OLR that has a mandatory AVP that it =
doesn't recognize. Logically, it should probably ignore the entire =
OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a =
relay, it's not going to reject the message. Rather it's likely to try =
to apply the OC-Supported-Features or OC-OLR incorrectly.


On Feb 7, 2014, at 4:10 PM, dime issue tracker =
 wrote:

> #48: Setting M-Bit gives wrong semantics
>=20
> Multiple sections indicate that a new application that incorporates =
DOIC
> can set the M-Bit on DOIC sub-avps. I don't think this ever does the =
right
> thing.
>=20
> IIUC, If a node that otherwise supports DOIC encounters a DOIC avp =
that it
> doesn't understand, and has the M-Bit set, it will cause a failure of =
the
> application command. I don't think we want the lack of support of some
> DOIC feature or extension to ever cause an application-level failure.  =
I
> think we are looking for something that would just cause the OLR to be
> ignored.
>=20
> --=20
> =
-------------------------+------------------------------------------------=
-
> Reporter:               |      Owner:  draft-docdt-dime-
>  ben@nostrum.com        |  ovli@tools.ietf.org
>     Type:  defect       |     Status:  new
> Priority:  major        |  Milestone:
> Component:  draft-       |    Version:  1.0
>  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 17 11:19:09 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 D6DC21A0462 for ; Mon, 17 Mar 2014 11:19:07 -0700 (PDT)
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 z7404pxAbZwx for ; Mon, 17 Mar 2014 11:19:05 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC681A0450 for ; Mon, 17 Mar 2014 11:19:05 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2HIItwv079182 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2014 13:18:57 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 416773135.235905-1bd92862118c722a889ed1d334749a59
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Message-Id: <4857132E-EB7E-4844-B9F4-81DD209E0705@nostrum.com>
Date: Mon, 17 Mar 2014 13:18:55 -0500
To: "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NcFuMnBN94e-ya1nW-saeJ1vOW8
Subject: [Dime] DOIC Default Algorithm Specification
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, 17 Mar 2014 18:19:08 -0000

Hi,

In re-reading dime-ovli, I noticed that the procedures for the "default" =
abatement algorithm are spread through several parts of the text. That's =
going to make life difficult down the road for a couple of reasons:

1) There's no easily referenced section that fully defines the =
algorithm. That will be a problem for other docs that want to talk about =
the algorithm (e.g. 3GPP specs), or even other sections in dime-ovli =
that want to mention the default algorithm by reference.

2) It makes extensibility harder, as it will be more difficult to define =
new algorithms, if they need to modify behavior that is spread =
throughout dime-ovli, rather than simply supersede a specific section of =
dime-ovli.

I propose that we move all algorithm-specific behavior to its own =
section, and have any other sections that need to talk about the default =
algorithm reference that section rather than attempt to describe the =
behavior.

Thanks!

Ben.=


From nobody Mon Mar 17 11:34:27 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 C4BE91A02FB for ; Mon, 17 Mar 2014 11:34:25 -0700 (PDT)
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 9w7J1QtyoKEk for ; Mon, 17 Mar 2014 11:34:24 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AD61A01D5 for ; Mon, 17 Mar 2014 11:34:23 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2HIYDkP080436 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Mar 2014 13:34:15 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
From: Ben Campbell 
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 416774053.741066-4445a478d6250aec32e366fa525c4975
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Message-Id: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com>
Date: Mon, 17 Mar 2014 13:34:13 -0500
To: "dime@ietf.org list" 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/HDWWYAqHcjiGrzeiuO2Cdz4Ky54
Subject: [Dime] DOIC Overview of Operation
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, 17 Mar 2014 18:34:26 -0000

Hi,

the dime-ovli currently lacks any sort of high-level overview of =
operation. As written, it jumps into details without giving the reader a =
high-level view of how it works. I think that will create confusion for =
new readers that have not been involved in discussions so far.

I propose adding the following text to the beginning of section 3. This =
would be entirely non-normative. I recognize that this would create some =
redundancies with later subsections. I don't address those here, but we =
would need to do so when integrating this text if we agree to add it.

Thanks!

Ben.

--------------------------

   The Diameter Overload Information Conveyance (DOIC) mechanism allows
   Diameter nodes to request other nodes to perform overload abatement
   actions, that is, actions to reduce the load offered to the
   overloaded node.

   A Diameter node that supports DOIC is known as a "DOIC endpoint".
   Any Diameter node can act as a DOIC endpoint, including clients,
   servers, and agents.  DOIC endpoints are further divided into
   "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
   overload abatement by sending an Overload Report (OLR) to one or more
   reacting nodes.

   A reacting node consumes OLRs, and performs whatever actions are
   needed to fulfill the requests.  A Reporting node may report overload
   on its own behalf, or on behalf of other (typically upstream) nodes.
   Likewise, a reacting node may perform overload abatement on its own
   behalf, or on behalf of other (typically downstream) nodes.

   A node's role as a DOIC endpoint is independent of its Diameter role.
   For example, Diameter relay and proxy agents may act as DOIC
   endpoints, even though they are not endpoints in the Diameter sense.
   Since Diameter enables bi-directional applications, where Diameter
   servers can send requests towards Diameter clients, a given Diameter
   node can simultaneously act as a reporting node and reacting node.

   Likewise, an relay or proxy agent may act as a reacting node from the
   perspective of upstream nodes, and a reporting node from the
   perspective of downstream nodes.

   DOIC endpoints do not generate new messages to carry DOIC related
   information.  Rather, they "piggyback" DOIC information over existing
   Diameter messages by inserting new AVPs into existing Diameter
   requests and responses.  Nodes indicate support for DOIC, and any
   needed DOIC parameters by inserting an OC_Supported_Features AVP
   (Section 4.1) into existing requests and responses.  Reporting nodes
   send OLRs by inserting OC-OLR AVPs.  (Section 4.3)

   A given OLR applies to the Diameter realm and application of the
   Diameter message that carries it.  If a reporting node supports more
   than one realm and/or application, it reports independently for each
   combination of realm and application.  Similarly, OC-Feature-Vector
   AVPs apply to the realm and application of the enclosing message.
   This implies that a node may support DOIC for one application and/or
   realm, but not another, and may indicate different DOIC parameters
   for each application and realm for which it supports DOIC.

   Reacting nodes perform overload abatement according to an agreed-upon
   abatement algorithm.  An abatement algorithm defines the meaning of
   the parameters of an OLR, and the procedures required for overload
   abatement.  This document specifies a single must-support algorithm,
   namely the "loss" algorithm [ref?].  Future specifications may
   introduce new algorithms.

   Overload conditions may vary in scope.  For example, a single
   Diameter node may be overloaded, in which case reacting nodes may
   reasonably attempt to send throttled requests to other destinations
   or via other agents.  On the other hand, an entire Diameter realm may
   be overloaded, in which case such attempts would do harm.  DOIC OLRs
   have a concept of "report type" (Section 4.6), where the type defines
   such behaviors.  Report types are extensible.  This document defines
   report types for overload of a specific server, and for overload of
   an entire realm.

   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unmolested.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.  Documents
   that introduce new report types MUST describe any limitations on
   their use across non-supporting agents.


From nobody Mon Mar 17 12:03:49 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 E8C171A0307 for ; Mon, 17 Mar 2014 12:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.76
X-Spam-Level: *
X-Spam-Status: No, score=1.76 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_FONT_FACE_BAD=0.981, 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 lZ5okDR4XB07 for ; Mon, 17 Mar 2014 12:03:45 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id F2F561A044D for ; Mon, 17 Mar 2014 12:03:43 -0700 (PDT)
Received: from [137.254.4.59] (port=8118 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPcow-0005oV-SP for dime@ietf.org; Mon, 17 Mar 2014 12:03:35 -0700
Message-ID: <53274706.70201@usdonovans.com>
Date: Mon, 17 Mar 2014 14:03:34 -0500
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" 
Content-Type: multipart/alternative; boundary="------------040707060604080803060603"
X-OutGoing-Spam-Status: No, score=-1.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/3_5vr7eRhEe5j3jCnE3wLJRncIY
Subject: [Dime] Issue #30
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, 17 Mar 2014 19:03:47 -0000

This is a multi-part message in MIME format.
--------------040707060604080803060603
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

We reached the tentative agreement in the DIME meeting on the following:

OC-Supported-Features handling:

Agreed: OC-Supported-Features AVP MUST be included in all answer
messages (we had already agreed that it must be included in all request
messages).
Agreed: Reacting node advertises all supported algorithms;
Agreed: Reporting node responds with the single algorithm it will be using;
Agreed: Handling of other feature bits is defined in the extension drafts

Based on this I believe we need the text changes outlined below.

Let me know if I have missed any.

If we agree on the text changes then we can close the issue and I'll
update the document accordingly.

Regards,

Steve

-----

Section 5.3.2, paragraph 1:

Change:

The answer message
   initiating endpoint MAY announce as many supported capabilities as it
   has (the announced set is a subject to local policy and
   configuration). However, at least one of the announced capabilities
   MUST be the same as received in the request message.


To:

The reporting node MUST include the OC-Supported-Features AVP in all
response messages for transactions where the request message included
the OC-Supported-Features AVP.  The reporting node MUST announce support
of the single algorithm that the reporting node will request the
reacting node to use to mitigate overload instances.  The reporting node
MUST NOT change the selected algorithm during a period of time that it
is in an overload state and, as a result, is sending OC-OLR AVPs in
answer messages. 

    Note: There will always be at least one algorithm supported by both
the reacting and reporting nodes as all nodes that support DOIC must
support the loss algorithm defined in this document.

The handling of feature bits in the OC-Feature-Vector AVP that are not
associated with overload abatement algorithms MUST be specified by the
extension that defines the feature.

Paragraph 2:

Change:

The answer message initiating endpoint MUST NOT include any overload
   control solution defined AVPs into its answer messages if the request
   message initiating endpoint has not indicated support at the
   beginning of the created session (or transaction in a case of non-
   session state maintaining applications). The same also applies if
   none of the announced capabilities match between the two endpoints.

To:

The reporting node MUST NOT include the OC-Supported-Features AVP,
OC-OLR AVP or any other overload control AVPs defined in extension
drafts in response messages for transaction where the request message
does not include the OC-Supported-Features AVP.  Lack of the
OC-Supported-Features AVP in the request message indicates that the
sender of the request message does not support DOIC.

Section 5.5.2, Paragraph 1:

Change:

   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP or indirectly remembering the previously
   used traffic abatement algorithm with the given reporting node.

To: (removing the last portion of the last sentence)

   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP.



--------------040707060604080803060603
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      We reached the tentative agreement in the DIME meeting on the
      following:

    

    OC-Supported-Features handling:

        

        Agreed: OC-Supported-Features AVP MUST be included in all answer
        messages (we had already agreed that it must be included in all
        request messages).

        Agreed: Reacting node advertises all supported algorithms;

        Agreed: Reporting node responds with the single algorithm it
        will be using;

        Agreed: Handling of other feature bits is defined in the
        extension drafts

      

      Based on this I believe we need the text changes outlined below.

      

      Let me know if I have missed any.

      

      If we agree on the text changes then we can close the issue and
      I'll update the document accordingly.

      

      Regards,

      

      Steve

      

      -----

      

      Section 5.3.2, paragraph 1:

      

      Change:

    
      
    
    
The answer message
   initiating endpoint MAY announce as many supported capabilities as it
   has (the announced set is a subject to local policy and
   configuration).  However, at least one of the announced capabilities
   MUST be the same as received in the request message.

    

      To:

      

      The reporting node MUST include the OC-Supported-Features AVP in
      all response messages for transactions where the request message
      included the OC-Supported-Features AVP.  The reporting node MUST
      announce support of the single algorithm that the reporting node
      will request the reacting node to use to mitigate overload
      instances.  The reporting node MUST NOT change the selected
      algorithm during a period of time that it is in an overload state
      and, as a result, is sending OC-OLR AVPs in answer messages.  

      

          Note: There will always be at least one algorithm supported by
      both the reacting and reporting nodes as all nodes that support
      DOIC must support the loss algorithm defined in this document.

      

      The handling of feature bits in the OC-Feature-Vector AVP that are
      not associated with overload abatement algorithms MUST be
      specified by the extension that defines the feature.

      

      Paragraph 2:

      

      Change:

    
      
    
    
The answer message initiating endpoint MUST NOT include any overload
   control solution defined AVPs into its answer messages if the request
   message initiating endpoint has not indicated support at the
   beginning of the created session (or transaction in a case of non-
   session state maintaining applications).  The same also applies if
   none of the announced capabilities match between the two endpoints.

    To:

      

      The reporting node MUST NOT include the OC-Supported-Features AVP,
      OC-OLR AVP or any other overload control AVPs defined in extension
      drafts in response messages for transaction where the request
      message does not include the OC-Supported-Features AVP.  Lack of
      the OC-Supported-Features AVP in the request message indicates
      that the sender of the request message does not support DOIC.

      

      Section 5.5.2, Paragraph 1:

      

      Change:

    
      
    
    
   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP or indirectly remembering the previously
   used traffic abatement algorithm with the given reporting node.

    To: (removing the last
      portion of the last sentence)

    
    
    
   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP.

    

  


--------------040707060604080803060603--


From nobody Mon Mar 17 14:32:49 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 41F8C1A0584 for ; Mon, 17 Mar 2014 14:32:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 2TeCxEvkX0U7 for ; Mon, 17 Mar 2014 14:32:42 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 40EAA1A0443 for ; Mon, 17 Mar 2014 14:32:41 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-23-532769f0c38e
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C7.52.04249.0F967235; Mon, 17 Mar 2014 22:32:32 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Mon, 17 Mar 2014 22:32:32 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Snapshot of -02 version of DOIC draft
Thread-Index: AQHPOsA2dYgrcAw7T0W7J1ZKE/2avprbzrfQgAmzAICAAFjH0A==
Date: Mon, 17 Mar 2014 21:32:30 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920979D620@ESESSMB101.ericsson.se>
References: <531AFCA4.1010408@usdonovans.com> <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se> <53272CD9.9080904@usdonovans.com>
In-Reply-To: <53272CD9.9080904@usdonovans.com>
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_087A34937E64E74E848732CFF8354B920979D620ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvje6HTPVgg2nz1S3m9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Mh6dWc5Y8LCNseLB0vvsDYyry7sYOTkkBEwk /r28xAphi0lcuLeerYuRi0NI4AijxL/nf9ghnCWMEpsnr2UGqWITsJO4dPoFE4gtIuArcbzz NAuILSxgKfH98FlWiLiVxOflq9khbCeJXSt/A9VwcLAIqEq8WsAMYvICtTZd9IUYPxVo/PGp YK2cAnoS53/NABvJCHTQ91NrwFYxC4hL3HoynwniUAGJJXvOM0PYohIvH/+DekBJonHJE1aI +nyJV6t/gp3AKyAocXLmE5YJjCKzkIyahaRsFpIyiLiexI2pU9ggbG2JZQtfM0PYuhIz/h1i QRZfwMi+ipGjOLU4KTfdyGATIzB6Dm75bbGD8fJfm0OM0hwsSuK8H986BwkJpCeWpGanphak FsUXleakFh9iZOLglGpg7J7/+pfP945kyxf1667ncu/J4+spv3HEomVGabl5z029z3X+G94d Nb96RH6ePzt/BevbDyLRj86v6riwYOkb09JlZys/7NjM1ZeXtCf8yF6fnKpT0VG9d2ed+fRK YjKT0nJWrxvzOUNsZb569vmodS4+9PDgYQGjE8u9PQ6d7KtZ7Rvx7ttNPyWW4oxEQy3mouJE AMcCjPNsAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tiodHMq2McFETyJYbSNmxmIf07Q
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 17 Mar 2014 21:32:45 -0000

--_000_087A34937E64E74E848732CFF8354B920979D620ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,

Well, text needs to be cleaned since it has impacts along the doc, apart fr=
om what is being discussed.
Not sure whether it is better to open a new issue or reopen this one.  Both=
 options are fine with me.
Cheers
/MCruz

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: lunes, 17 de marzo de 2014 18:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft

Maria Cruz,

I updated the text based on what was put in the issue tracker when you clos=
ed the issue.

Are you suggesting that this issue needs to be re-opened so we can discuss =
whether OC-Supported-Features is needed in mid-session requests?

Steve
On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:
Hello Steve,

According to conclusion on #Issue 51: OC-Supported-Feature AVP MUST be incl=
uded in all request messages sent by a DOIC supporting node. (not yet agree=
d).

Text marked in green below requires updates:

5.3.1.  Reacting Node Endpoint Considerations

   The basic principle is that the request message initiating endpoint
   (i.e. the "reacting node") announces its support for the overload
   control mechanism by including in the request message the OC-
   Supported-Features AVP with those capabilities it supports and is
   willing to use for this Diameter session (or transaction in a case of
   a non-session state maintaining applications, see Section 3.1.2 for
   more details on Diameter sessions).  It is RECOMMENDED that the
   request message initiating endpoint includes the capability
   announcement into every request regardless it has had prior message
   exchanges with the give remote endpoint.  In a case of a Diameter
   session maintaining application, sending the OC-Supported-Features
   AVP in every message is not really necessary after the initial
   capability announcement or until there is a change in supported
   features.

   Once the endpoint that initiated the request message receives an
   answer message from the remote endpoint, it can detect from the
   received answer message whether the remote endpoint supports the
   overload control solution and in a case it does, what features are
   supported.  The support for the overload control solution is based on
   the presence of the OC-Supported-Features AVP in the Diameter answer
   for existing application.


Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: s=E1bado, 08 de marzo de 2014 12:19
To: dime@ietf.org
Subject: [Dime] Snapshot of -02 version of DOIC draft

All,

I have made updates to the -02 version of the DOIC draft based on resolutio=
n to the following issues:

24, 32, 50, 51, 52, 47 and 37

I had also started to make updates for issues 29, 31 and 34 before we agree=
d that the proposed text needs to be updated in the issue tracker before th=
e edits are made.  I'll clean up these updates when we have the wording put=
 into issue tracker.

To those who own issues in issue tracker, if we have resolution of the issu=
e on the mailing list please update issue tracker ASAP so the edits can be =
put into the -02 draft.

Thanks,

Steve


--_000_087A34937E64E74E848732CFF8354B920979D620ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

 <=
/p>

Well, text needs to be cl=
eaned since it has impacts along the doc, apart from what is being discusse=
d.


Not sure whether it is be=
tter to open a new issue or reopen this one.  Both options are fine wi=
th me.


Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: lunes, 17 de marzo de 2014 18:12

To: Maria Cruz Bartolome; dime@ietf.org

Subject: Re: [Dime] Snapshot of -02 version of DOIC draft=







 


Maria Cruz,



I updated the text based on what was put in the issue tracker when you clos=
ed the issue.



Are you suggesting that this issue needs to be re-opened so we can discuss =
whether OC-Supported-Features is needed in mid-session requests?



Steve




On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:=







Hello Steve,<=
/o:p>


 <=
/p>

According to conclusion o=
n #Issue 51: OC-Supported-Feature AVP MUST be included in all request messa=
ges sent by a DOIC supporting node. (not yet agreed).


 <=
/p>

Text marked in green belo=
w requires updates:


 <=
/p>

5.3.1.  Reacting Nod=
e Endpoint Considerations


 <=
/p>

   The basic pr=
inciple is that the request message initiating endpoint

   (i.e. the &q=
uot;reacting node") announces its support for the overload=



   control mech=
anism by including in the request message the OC-


   Supported-Fe=
atures AVP with those capabilities it supports and is


   willing to u=
se for this Diameter session (or transaction in a case of=



   a non-sessio=
n state maintaining applications, see Section 3.1.2 for

   more details=
 on Diameter sessions). 
It is RECOMMENDED that the


   request mess=
age initiating endpoint includes the capability


   announcement=
 into every request regardless it has had prior message

   exchanges wi=
th the give remote endpoint.  In a case of a Diameter


   session main=
taining application, sending the OC-Supported-Features

   AVP in every=
 message is not really necessary after the initial


   capability a=
nnouncement or until there is a change in supported


   features.


 <=
/p>

   Once the end=
point that initiated the request message receives an


   answer messa=
ge from the remote endpoint, it can detect from the


   received ans=
wer message whether the remote endpoint supports the


   overload con=
trol solution and in a case it does, what features are

   supported.&n=
bsp; The support for the overload control solution is based on<=
/o:p>


   the presence=
 of the OC-Supported-Features AVP in the Diameter answer<=
/p>

   for existing=
 application.


 <=
/p>

 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: s=E1bado, 08 de marzo de 2014 12:19

To: dime@ietf.org

Subject: [Dime] Snapshot of -02 version of DOIC draft






 


All,



I have made updates to the -02 version of the DOIC draft based on resolutio=
n to the following issues:



24, 32, 50, 51, 52, 47 and 37



I had also started to make updates for issues 29, 31 and 34 before we agree=
d that the proposed text needs to be updated in the issue tracker before th=
e edits are made.  I'll clean up these updates when we have the wordin=
g put into issue tracker.



To those who own issues in issue tracker, if we have resolution of the issu=
e on the mailing list please update issue tracker ASAP so the edits can be =
put into the -02 draft.



Thanks,



Steve




 






--_000_087A34937E64E74E848732CFF8354B920979D620ESESSMB101erics_--


From nobody Tue Mar 18 04:51: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 AD0801A0323; Tue, 18 Mar 2014 04:51:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-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 hKFB4xkowSvn; Tue, 18 Mar 2014 04:51:00 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2607:f170:8000:1500::d3]) by ietfa.amsl.com (Postfix) with ESMTP id C89B51A01BC; Tue, 18 Mar 2014 04:51:00 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 99F957FC2C7; Tue, 18 Mar 2014 04:50:52 -0700 (PDT)
To: Hyungho.Kim@aeris.net, carlberg@g11.org.uk, tom.taylor.stds@gmail.com
From: RFC Errata System 
Message-Id: <20140318115052.99F957FC2C7@rfc-editor.org>
Date: Tue, 18 Mar 2014 04:50:52 -0700 (PDT)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/7s4mO6OTb8gsqnMT0kpLselD6ow
Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org
Subject: [Dime] [Errata Rejected] RFC6735 (3859)
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, 18 Mar 2014 11:51:03 -0000

The following errata report has been rejected for RFC6735,
"Diameter Priority Attribute-Value Pairs".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6735&eid=3859

--------------------------------------
Status: Rejected
Type: Technical

Reported by: Hyungho Kim 
Date Reported: 2014-01-02
Rejected by: Benoit Claise (IESG)

Section: 5.1

Original Text
-------------
ALRP-Value                             617  3.4.2     Unsigned32

Corrected Text
--------------
ALRP-Value                             617  3.4.2     Unsigned8

Notes
-----
Conflicts with section 3.4.2, which says "The ALRP-Value AVP (AVP Code 617) is of type Unsigned8"
 --VERIFIER NOTES-- 
In accordance with the DIME chairs: The introduction of new data types would imply a new version of the Base protocol..

  "In the event that a new Basic AVP Data Format is needed,
   a new version of this RFC MUST be created." 

A bis document is required.

--------------------------------------
RFC6735 (draft-ietf-dime-priority-avps-06)
--------------------------------------
Title               : Diameter Priority Attribute-Value Pairs
Publication Date    : October 2012
Author(s)           : K. Carlberg, Ed., T. Taylor
Category            : PROPOSED STANDARD
Source              : Diameter Maintenance and Extensions
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Tue Mar 18 05:59:22 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 4A28B1A03FB for ; Tue, 18 Mar 2014 05:59:19 -0700 (PDT)
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 pXOCUGdzQ5OV for ; Tue, 18 Mar 2014 05:59:17 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id BC55C1A0537 for ; Tue, 18 Mar 2014 05:58:26 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62557 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPtat-00044D-DB; Tue, 18 Mar 2014 05:58:18 -0700
Message-ID: <532842E2.5080102@usdonovans.com>
Date: Tue, 18 Mar 2014 07:58:10 -0500
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: Maria Cruz Bartolome ,  "dime@ietf.org" 
References: <531AFCA4.1010408@usdonovans.com> <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se> <53272CD9.9080904@usdonovans.com> <087A34937E64E74E848732CFF8354B920979D620@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920979D620@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------060901050105070907000006"
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/vvdvNxSL03ISNmAfvNz5wl2BQ2A
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 18 Mar 2014 12:59:19 -0000

This is a multi-part message in MIME format.
--------------060901050105070907000006
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Maria Cruz,

Let me first try to convince you that we don't need the session scoping
of OC-Supported-Features.  If I'm not successful then we can open an issue.

The two options is to scope the capability advertisement to be either
transaction-based or session-based.  A subset of applications, those
that do not use sessions, will be transaction-based by definition. 
Applications that use sessions could use either transaction or session
scoping on capability advertisement.

The one clear advantage of allowing for session-based scoping is it
reduces the size of non session initiating requests and answers.  I
don't see other advantages but may be missing some.

The big disadvantage I see for session-based scoping is the impact on
agents.  This would require agents to become session aware, something
that is otherwise not required.  It might also require sharing that
session-state across multiple agents.  Again, this is not otherwise
required.

The following are the advantages I see for supporting only
transaction-based scoping:

1) Consistency across all applications.  There is no need to have two
implementations of DOIC, one for session-based applications and another
for transaction-based applications.  The DOIC handler can always go to
the same place to determine the results of the capabilities exchange --
the OC-Supported-Features AVP in the appropriate message -- instead of
having to go the to stored session state if the scope is session-based.

2) Statelessness - Transaction-based scoping allows for capability
advertisement to be completely stateless. 

3) Agent impacts - Transaction-based scoping removes the need for
maintaining per session DOIC state in agents.  This is a big advantage
(in my opinion).

One other point is that supporting transaction-based scoping in
session-based applications does not break anything.  It does have the
negative of adding the OC-Supported-Features AVP to all messages, but
that is a small negative.

Regards,

Steve

On 3/17/14 4:32 PM, Maria Cruz Bartolome wrote:
>
> Hello,
>
>  
>
> Well, text needs to be cleaned since it has impacts along the doc,
> apart from what is being discussed.
>
> Not sure whether it is better to open a new issue or reopen this one.
>  Both options are fine with me.
>
> Cheers
>
> /MCruz
>
>  
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* lunes, 17 de marzo de 2014 18:12
> *To:* Maria Cruz Bartolome; dime@ietf.org
> *Subject:* Re: [Dime] Snapshot of -02 version of DOIC draft
>
>  
>
> Maria Cruz,
>
> I updated the text based on what was put in the issue tracker when you
> closed the issue.
>
> Are you suggesting that this issue needs to be re-opened so we can
> discuss whether OC-Supported-Features is needed in mid-session requests?
>
> Steve
>
> On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:
>
>     Hello Steve,
>
>      
>
>     According to conclusion on #Issue 51: OC-Supported-Feature AVP
>     MUST be included in all request messages sent by a DOIC supporting
>     node. (not yet agreed).
>
>      
>
>     Text marked in green below requires updates:
>
>      
>
>     5.3.1.  Reacting Node Endpoint Considerations
>
>      
>
>        The basic principle is that the request message initiating endpoint
>
>        (i.e. the "reacting node") announces its support for the overload
>
>        control mechanism by including in the request message the OC-
>
>        Supported-Features AVP with those capabilities it supports and is
>
>        willing to use for this Diameter session (or transaction in a
>     case of
>
>        a non-session state maintaining applications, see Section 3.1.2 for
>
>        more details on Diameter sessions).  It is RECOMMENDED that the
>
>        request message initiating endpoint includes the capability
>
>        announcement into every request regardless it has had prior message
>
>        exchanges with the give remote endpoint.  In a case of a Diameter
>
>        session maintaining application, sending the OC-Supported-Features
>
>        AVP in every message is not really necessary after the initial
>
>        capability announcement or until there is a change in supported
>
>        features.
>
>      
>
>        Once the endpoint that initiated the request message receives an
>
>        answer message from the remote endpoint, it can detect from the
>
>        received answer message whether the remote endpoint supports the
>
>        overload control solution and in a case it does, what features are
>
>        supported.  The support for the overload control solution is
>     based on
>
>        the presence of the OC-Supported-Features AVP in the Diameter
>     answer
>
>        for existing application.
>
>      
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve
>     Donovan
>     *Sent:* sábado, 08 de marzo de 2014 12:19
>     *To:* dime@ietf.org 
>     *Subject:* [Dime] Snapshot of -02 version of DOIC draft
>
>      
>
>     All,
>
>     I have made updates to the -02 version of the DOIC draft based on
>     resolution to the following issues:
>
>     24, 32, 50, 51, 52, 47 and 37
>
>     I had also started to make updates for issues 29, 31 and 34 before
>     we agreed that the proposed text needs to be updated in the issue
>     tracker before the edits are made.  I'll clean up these updates
>     when we have the wording put into issue tracker.
>
>     To those who own issues in issue tracker, if we have resolution of
>     the issue on the mailing list please update issue tracker ASAP so
>     the edits can be put into the -02 draft.
>
>     Thanks,
>
>     Steve
>
>  
>


--------------060901050105070907000006
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      Let me first try to convince you that we don't need the session
      scoping of OC-Supported-Features.  If I'm not successful then we
      can open an issue.

      

      The two options is to scope the capability advertisement to be
      either transaction-based or session-based.  A subset of
      applications, those that do not use sessions, will be
      transaction-based by definition.  Applications that use sessions
      could use either transaction or session scoping on capability
      advertisement.

      

      The one clear advantage of allowing for session-based scoping is
      it reduces the size of non session initiating requests and
      answers.  I don't see other advantages but may be missing some.

      

      The big disadvantage I see for session-based scoping is the impact
      on agents.  This would require agents to become session aware,
      something that is otherwise not required.  It might also require
      sharing that session-state across multiple agents.  Again, this is
      not otherwise required.

      

      The following are the advantages I see for supporting only
      transaction-based scoping:

      

      1) Consistency across all applications.  There is no need to have
      two implementations of DOIC, one for session-based applications
      and another for transaction-based applications.  The DOIC handler
      can always go to the same place to determine the results of the
      capabilities exchange -- the OC-Supported-Features AVP in the
      appropriate message -- instead of having to go the to stored
      session state if the scope is session-based. 

      

      2) Statelessness - Transaction-based scoping allows for capability
      advertisement to be completely stateless.  

      

      3) Agent impacts - Transaction-based scoping removes the need for
      maintaining per session DOIC state in agents.  This is a big
      advantage (in my opinion).

      

      One other point is that supporting transaction-based scoping in
      session-based applications does not break anything.  It does have
      the negative of adding the OC-Supported-Features AVP to all
      messages, but that is a small negative.

      

      Regards,

      

      Steve

      

    
    
On 3/17/14 4:32 PM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello,

        
 

        
Well,
            text needs to be cleaned since it has impacts along the doc,
            apart from what is being discussed.

        
Not
            sure whether it is better to open a new issue or reopen this
            one.  Both options are fine with me.

        
Cheers

        
/MCruz

        
 

        

          

            
From:
                Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: lunes, 17 de marzo de 2014 18:12

                To: Maria Cruz Bartolome; dime@ietf.org

                Subject: Re: [Dime] Snapshot of -02 version of
                DOIC draft

          

        

        
 

        
Maria Cruz,

          

          I updated the text based on what was put in the issue tracker
          when you closed the issue.

          

          Are you suggesting that this issue needs to be re-opened so we
          can discuss whether OC-Supported-Features is needed in
          mid-session requests?

          

          Steve

        

          
On 3/11/14 7:06 AM, Maria Cruz Bartolome
            wrote:

        

        

          
Hello
              Steve,

          
 

          
According
              to conclusion on #Issue 51: OC-Supported-Feature AVP MUST
              be included in all request messages sent by a DOIC
              supporting node. (not yet agreed).

          
 

          
Text
              marked in green below requires updates:

          
 

          
5.3.1. 
              Reacting Node Endpoint Considerations

          
 

          
  
              The basic principle is that the request message initiating
              endpoint

          
  
              (i.e. the "reacting node") announces its support for the
              overload

          
  
              control mechanism by including in the request message the
              OC-

          
  
              Supported-Features AVP with those capabilities it supports
              and is

          
  
              willing to use for this Diameter session (or transaction
              in a case of

          
  
              a non-session state maintaining applications, see Section
              3.1.2 for

          
  
              more details on Diameter sessions). 
            It
              is RECOMMENDED that the

          
  
              request message initiating endpoint includes the
              capability

          
  
              announcement into every request regardless it has had
              prior message

          
  
              exchanges with the give remote endpoint.  In a case of a
              Diameter

          
  
              session maintaining application, sending the
              OC-Supported-Features

          
  
              AVP in every message is not really necessary after the
              initial

          
  
              capability announcement or until there is a change in
              supported

          
  
              features.

          
 

          
  
              Once the endpoint that initiated the request message
              receives an

          
  
              answer message from the remote endpoint, it can detect
              from the

          
  
              received answer message whether the remote endpoint
              supports the

          
  
              overload control solution and in a case it does, what
              features are

          
  
              supported.  The support for the overload control solution
              is based on

          
  
              the presence of the OC-Supported-Features AVP in the
              Diameter answer

          
  
              for existing application.

          
 

          
 

          
Best
              regards

          
/MCruz

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of Steve Donovan

                  Sent: sábado, 08 de marzo de 2014 12:19

                  To: dime@ietf.org

                  Subject: [Dime] Snapshot of -02 version of DOIC
                  draft

            

          

          
 

          
All,

            

            I have made updates to the -02 version of the DOIC draft
            based on resolution to the following issues:

            

            24, 32, 50, 51, 52, 47 and 37

            

            I had also started to make updates for issues 29, 31 and 34
            before we agreed that the proposed text needs to be updated
            in the issue tracker before the edits are made.  I'll clean
            up these updates when we have the wording put into issue
            tracker.

            

            To those who own issues in issue tracker, if we have
            resolution of the issue on the mailing list please update
            issue tracker ASAP so the edits can be put into the -02
            draft.

            

            Thanks,

            

            Steve

        

        
 

      

    

    

  


--------------060901050105070907000006--


From nobody Tue Mar 18 07:11: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 A506B1A012F for ; Tue, 18 Mar 2014 07:11:04 -0700 (PDT)
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 D4XK8BCMITUj for ; Tue, 18 Mar 2014 07:11:01 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5AD1A037C for ; Tue, 18 Mar 2014 07:11:01 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2IEAlT8078547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 09:10:49 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
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: <532842E2.5080102@usdonovans.com>
Date: Tue, 18 Mar 2014 09:10:47 -0500
X-Mao-Original-Outgoing-Id: 416844647.130681-55ad6489a22e66e53744539b55fc7cc1
Content-Transfer-Encoding: quoted-printable
Message-Id: <65C29455-E9E1-40E0-8AEA-416F38E180AB@nostrum.com>
References: <531AFCA4.1010408@usdonovans.com> <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se> <53272CD9.9080904@usdonovans.com> <087A34937E64E74E848732CFF8354B920979D620@ESESSMB101.ericsson.se> <532842E2.5080102@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/g7aZpu9melqgkJJMmxHFpFrOcCk
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 18 Mar 2014 14:11:04 -0000

I was under the impression that Jouni's original text did have, at least =
by implication, session scoping of OC-Supported-Features, and that we =
had discussed and decided against it.

I would also argue that the lifetime of a certain configuration of =
OC-Supported-Features and lifetimes of sessions are likely to be widely =
different. Many installations will be constantly establishing and =
terminating sessions. I don't think the size advantage for mid-session =
requests would turn out to be much of an advantage in practice.

Thanks!

Ben.

On Mar 18, 2014, at 7:58 AM, Steve Donovan  =
wrote:

> Maria Cruz,
>=20
> Let me first try to convince you that we don't need the session =
scoping of OC-Supported-Features.  If I'm not successful then we can =
open an issue.
>=20
> The two options is to scope the capability advertisement to be either =
transaction-based or session-based.  A subset of applications, those =
that do not use sessions, will be transaction-based by definition.  =
Applications that use sessions could use either transaction or session =
scoping on capability advertisement.
>=20
> The one clear advantage of allowing for session-based scoping is it =
reduces the size of non session initiating requests and answers.  I =
don't see other advantages but may be missing some.
>=20
> The big disadvantage I see for session-based scoping is the impact on =
agents.  This would require agents to become session aware, something =
that is otherwise not required.  It might also require sharing that =
session-state across multiple agents.  Again, this is not otherwise =
required.
>=20
> The following are the advantages I see for supporting only =
transaction-based scoping:
>=20
> 1) Consistency across all applications.  There is no need to have two =
implementations of DOIC, one for session-based applications and another =
for transaction-based applications.  The DOIC handler can always go to =
the same place to determine the results of the capabilities exchange -- =
the OC-Supported-Features AVP in the appropriate message -- instead of =
having to go the to stored session state if the scope is session-based.=20=

>=20
> 2) Statelessness - Transaction-based scoping allows for capability =
advertisement to be completely stateless. =20
>=20
> 3) Agent impacts - Transaction-based scoping removes the need for =
maintaining per session DOIC state in agents.  This is a big advantage =
(in my opinion).
>=20
> One other point is that supporting transaction-based scoping in =
session-based applications does not break anything.  It does have the =
negative of adding the OC-Supported-Features AVP to all messages, but =
that is a small negative.
>=20
> Regards,
>=20
> Steve
>=20
> On 3/17/14 4:32 PM, Maria Cruz Bartolome wrote:
>> Hello,
>> =20
>> Well, text needs to be cleaned since it has impacts along the doc, =
apart from what is being discussed.
>> Not sure whether it is better to open a new issue or reopen this one. =
 Both options are fine with me.
>> Cheers
>> /MCruz
>> =20
>> From: Steve Donovan [mailto:srdonovan@usdonovans.com]=20
>> Sent: lunes, 17 de marzo de 2014 18:12
>> To: Maria Cruz Bartolome; dime@ietf.org
>> Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
>> =20
>> Maria Cruz,
>>=20
>> I updated the text based on what was put in the issue tracker when =
you closed the issue.
>>=20
>> Are you suggesting that this issue needs to be re-opened so we can =
discuss whether OC-Supported-Features is needed in mid-session requests?
>>=20
>> Steve
>>=20
>> On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:
>> Hello Steve,
>> =20
>> According to conclusion on #Issue 51: OC-Supported-Feature AVP MUST =
be included in all request messages sent by a DOIC supporting node. (not =
yet agreed).
>> =20
>> Text marked in green below requires updates:
>> =20
>> 5.3.1.  Reacting Node Endpoint Considerations
>> =20
>>    The basic principle is that the request message initiating =
endpoint
>>    (i.e. the "reacting node") announces its support for the overload
>>    control mechanism by including in the request message the OC-
>>    Supported-Features AVP with those capabilities it supports and is
>>    willing to use for this Diameter session (or transaction in a case =
of
>>    a non-session state maintaining applications, see Section 3.1.2 =
for
>>    more details on Diameter sessions).  It is RECOMMENDED that the
>>    request message initiating endpoint includes the capability
>>    announcement into every request regardless it has had prior =
message
>>    exchanges with the give remote endpoint.  In a case of a Diameter
>>    session maintaining application, sending the OC-Supported-Features
>>    AVP in every message is not really necessary after the initial
>>    capability announcement or until there is a change in supported
>>    features.
>> =20
>>    Once the endpoint that initiated the request message receives an
>>    answer message from the remote endpoint, it can detect from the
>>    received answer message whether the remote endpoint supports the
>>    overload control solution and in a case it does, what features are
>>    supported.  The support for the overload control solution is based =
on
>>    the presence of the OC-Supported-Features AVP in the Diameter =
answer
>>    for existing application.
>> =20
>> =20
>> Best regards
>> /MCruz
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>> Sent: s=E1bado, 08 de marzo de 2014 12:19
>> To: dime@ietf.org
>> Subject: [Dime] Snapshot of -02 version of DOIC draft
>> =20
>> All,
>>=20
>> I have made updates to the -02 version of the DOIC draft based on =
resolution to the following issues:
>>=20
>> 24, 32, 50, 51, 52, 47 and 37
>>=20
>> I had also started to make updates for issues 29, 31 and 34 before we =
agreed that the proposed text needs to be updated in the issue tracker =
before the edits are made.  I'll clean up these updates when we have the =
wording put into issue tracker.
>>=20
>> To those who own issues in issue tracker, if we have resolution of =
the issue on the mailing list please update issue tracker ASAP so the =
edits can be put into the -02 draft.
>>=20
>> Thanks,
>>=20
>> Steve
>> =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Mar 18 07:14: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 0C4CF1A043E for ; Tue, 18 Mar 2014 07:14:53 -0700 (PDT)
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 kEDQU0Mh5bra for ; Tue, 18 Mar 2014 07:14:51 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 607861A0403 for ; Tue, 18 Mar 2014 07:14:49 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2IEEdO3078834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Mar 2014 09:14:40 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
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: <53274706.70201@usdonovans.com>
Date: Tue, 18 Mar 2014 09:14:39 -0500
X-Mao-Original-Outgoing-Id: 416844879.247991-6070fbfb102a9a5ffbf2522d02d2c67f
Content-Transfer-Encoding: quoted-printable
Message-Id: <47CE5611-2743-45AA-94A5-2D4BCF33EFF2@nostrum.com>
References: <53274706.70201@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/MlJLQYJqnMhw3xnbqtHxISODRD8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue #30
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, 18 Mar 2014 14:14:53 -0000

+1, with a minor suggested edit:

On Mar 17, 2014, at 2:03 PM, Steve Donovan  =
wrote:

> Change:
>    Once a reacting node receives an OC-OLR AVP from a reporting node, =
it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload =
condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP or indirectly remembering the previously
>    used traffic abatement algorithm with the given reporting node.

> To: (removing the last portion of the last sentence)
>    Once a reacting node receives an OC-OLR AVP from a reporting node, =
it
>    applies the traffic abatement based on the commonly supported

s/"commonly supported"/selected

"Commonly supported" is no longer descriptive. There may be several =
commonly supported algorithm, but the reporting node selects just one.

>    algorithm with the reporting node and the current overload =
condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP.
>=20


From nobody Tue Mar 18 07:51:47 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 059F31A036E for ; Tue, 18 Mar 2014 07:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 RFXPYyD9cEaV for ; Tue, 18 Mar 2014 07:51:41 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id F12871A03BC for ; Tue, 18 Mar 2014 07:51:39 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-1f-53285d7230fb
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 4A.C5.04249.27D58235; Tue, 18 Mar 2014 15:51:31 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.02.0387.000; Tue, 18 Mar 2014 15:51:30 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Snapshot of -02 version of DOIC draft
Thread-Index: AQHPOsA2dYgrcAw7T0W7J1ZKE/2avprbzrfQgAmzAICAAFjH0IAA8qsAgAAvWCA=
Date: Tue, 18 Mar 2014 14:51:29 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920979DC55@ESESSMB101.ericsson.se>
References: <531AFCA4.1010408@usdonovans.com> <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se> <53272CD9.9080904@usdonovans.com> <087A34937E64E74E848732CFF8354B920979D620@ESESSMB101.ericsson.se> <532842E2.5080102@usdonovans.com>
In-Reply-To: <532842E2.5080102@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.150]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B920979DC55ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM+JvjW5xrEawQeMWJou5vSvYLDY08Tgw eSxZ8pPJY9XbPtYApigum5TUnMyy1CJ9uwSujHV7VAuWnGKsmHV0E2sD47KNjF2MnBwSAiYS T37fZYGwxSQu3FvP1sXIxSEkcIRR4sqEF4wQzhJGiUdT2sA62ATsJC6dfsEEYosI+Eoc7zwN 1i0sYCnx/fBZVoi4lcTn5avZIWw/iTOvG9hAbBYBVYm996+B9fIC9Z448JUZYsFfRolJs6aB NXAK6ElcuvgSbBAj0EnfT60Ba2AWEJe49WQ+E8SpAhJL9pxnhrBFJV4+/scKYStJrNh+iRGi Pl/iyeIbbBDLBCVOznzCMoFRZBaSUbOQlM1CUgYR15O4MXUKG4StLbFs4WtmCFtXYsa/QyzI 4gsY2VcxchSnFiflphsZbGIERtDBLb8tdjBe/mtziFGag0VJnPfjW+cgIYH0xJLU7NTUgtSi +KLSnNTiQ4xMHJxSDYw5aWkf1+0u6Fo684Pqm/aorelP7H6tMp//4ovWpemn25huXHjqkN/8 tPTYlQW69VXTvvZsYV+dfWzNh6RMTx2uVZPd5guLM1vZfg215hSqifgcz2U+mXXxpfUp8R+u LbPWanYqUZD+GP0zmftD9/ms/acajBacdPFSyzxaGP9JQmT+ewHBNCUlluKMREMt5qLiRAAz M0qrbgIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/03dJrcV84vpXqn1_kECyczl0wZk
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 18 Mar 2014 14:51:44 -0000

--_000_087A34937E64E74E848732CFF8354B920979DC55ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve,

I was in favor already of capability advertisement per transaction :)

What I meant, but I can see I did not convey my message successfully, is th=
at since we have agreed OC-Supported-Features is included in every message,=
 then this implies a capability advertisement per transaction, and then som=
e text that was before there to consider capability advertisement per sessi=
on should be removed/updated, like the one I highlighted in green below.

I hope this clarifies
Thanks
/MCruz

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: martes, 18 de marzo de 2014 13:58
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft

Maria Cruz,

Let me first try to convince you that we don't need the session scoping of =
OC-Supported-Features.  If I'm not successful then we can open an issue.

The two options is to scope the capability advertisement to be either trans=
action-based or session-based.  A subset of applications, those that do not=
 use sessions, will be transaction-based by definition.  Applications that =
use sessions could use either transaction or session scoping on capability =
advertisement.

The one clear advantage of allowing for session-based scoping is it reduces=
 the size of non session initiating requests and answers.  I don't see othe=
r advantages but may be missing some.

The big disadvantage I see for session-based scoping is the impact on agent=
s.  This would require agents to become session aware, something that is ot=
herwise not required.  It might also require sharing that session-state acr=
oss multiple agents.  Again, this is not otherwise required.

The following are the advantages I see for supporting only transaction-base=
d scoping:

1) Consistency across all applications.  There is no need to have two imple=
mentations of DOIC, one for session-based applications and another for tran=
saction-based applications.  The DOIC handler can always go to the same pla=
ce to determine the results of the capabilities exchange -- the OC-Supporte=
d-Features AVP in the appropriate message -- instead of having to go the to=
 stored session state if the scope is session-based.

2) Statelessness - Transaction-based scoping allows for capability advertis=
ement to be completely stateless.

3) Agent impacts - Transaction-based scoping removes the need for maintaini=
ng per session DOIC state in agents.  This is a big advantage (in my opinio=
n).

One other point is that supporting transaction-based scoping in session-bas=
ed applications does not break anything.  It does have the negative of addi=
ng the OC-Supported-Features AVP to all messages, but that is a small negat=
ive.

Regards,

Steve
On 3/17/14 4:32 PM, Maria Cruz Bartolome wrote:
Hello,

Well, text needs to be cleaned since it has impacts along the doc, apart fr=
om what is being discussed.
Not sure whether it is better to open a new issue or reopen this one.  Both=
 options are fine with me.
Cheers
/MCruz

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: lunes, 17 de marzo de 2014 18:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft

Maria Cruz,

I updated the text based on what was put in the issue tracker when you clos=
ed the issue.

Are you suggesting that this issue needs to be re-opened so we can discuss =
whether OC-Supported-Features is needed in mid-session requests?

Steve
On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:
Hello Steve,

According to conclusion on #Issue 51: OC-Supported-Feature AVP MUST be incl=
uded in all request messages sent by a DOIC supporting node. (not yet agree=
d).

Text marked in green below requires updates:

5.3.1.  Reacting Node Endpoint Considerations

   The basic principle is that the request message initiating endpoint
   (i.e. the "reacting node") announces its support for the overload
   control mechanism by including in the request message the OC-
   Supported-Features AVP with those capabilities it supports and is
   willing to use for this Diameter session (or transaction in a case of
   a non-session state maintaining applications, see Section 3.1.2 for
   more details on Diameter sessions).  It is RECOMMENDED that the
   request message initiating endpoint includes the capability
   announcement into every request regardless it has had prior message
   exchanges with the give remote endpoint.  In a case of a Diameter
   session maintaining application, sending the OC-Supported-Features
   AVP in every message is not really necessary after the initial
   capability announcement or until there is a change in supported
   features.

   Once the endpoint that initiated the request message receives an
   answer message from the remote endpoint, it can detect from the
   received answer message whether the remote endpoint supports the
   overload control solution and in a case it does, what features are
   supported.  The support for the overload control solution is based on
   the presence of the OC-Supported-Features AVP in the Diameter answer
   for existing application.


Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: s=E1bado, 08 de marzo de 2014 12:19
To: dime@ietf.org
Subject: [Dime] Snapshot of -02 version of DOIC draft

All,

I have made updates to the -02 version of the DOIC draft based on resolutio=
n to the following issues:

24, 32, 50, 51, 52, 47 and 37

I had also started to make updates for issues 29, 31 and 34 before we agree=
d that the proposed text needs to be updated in the issue tracker before th=
e edits are made.  I'll clean up these updates when we have the wording put=
 into issue tracker.

To those who own issues in issue tracker, if we have resolution of the issu=
e on the mailing list please update issue tracker ASAP so the edits can be =
put into the -02 draft.

Thanks,

Steve



--_000_087A34937E64E74E848732CFF8354B920979DC55ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

I was in favor already of=
 capability advertisement per transaction
J


 <=
/p>

What I meant, but I can s=
ee I did not convey my message successfully, is that since we have agreed O=
C-Supported-Features is included in every message, then
 this implies a capability advertisement per transaction, and then some tex=
t that was before there to consider capability advertisement per session sh=
ould be removed/updated, like the one I highlighted in green below.


 <=
/p>

I hope this clarifies


Thanks<=
/p>

/MCruz<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: martes, 18 de marzo de 2014 13:58

To: Maria Cruz Bartolome; dime@ietf.org

Subject: Re: [Dime] Snapshot of -02 version of DOIC draft=







 


Maria Cruz,



Let me first try to convince you that we don't need the session scoping of =
OC-Supported-Features.  If I'm not successful then we can open an issu=
e.



The two options is to scope the capability advertisement to be either trans=
action-based or session-based.  A subset of applications, those that d=
o not use sessions, will be transaction-based by definition.  Applicat=
ions that use sessions could use either transaction
 or session scoping on capability advertisement.



The one clear advantage of allowing for session-based scoping is it reduces=
 the size of non session initiating requests and answers.  I don't see=
 other advantages but may be missing some.



The big disadvantage I see for session-based scoping is the impact on agent=
s.  This would require agents to become session aware, something that =
is otherwise not required.  It might also require sharing that session=
-state across multiple agents.  Again, this
 is not otherwise required.



The following are the advantages I see for supporting only transaction-base=
d scoping:



1) Consistency across all applications.  There is no need to have two =
implementations of DOIC, one for session-based applications and another for=
 transaction-based applications.  The DOIC handler can always go to th=
e same place to determine the results of the
 capabilities exchange -- the OC-Supported-Features AVP in the appropriate =
message -- instead of having to go the to stored session state if the scope=
 is session-based.




2) Statelessness - Transaction-based scoping allows for capability advertis=
ement to be completely stateless. 




3) Agent impacts - Transaction-based scoping removes the need for maintaini=
ng per session DOIC state in agents.  This is a big advantage (in my o=
pinion).



One other point is that supporting transaction-based scoping in session-bas=
ed applications does not break anything.  It does have the negative of=
 adding the OC-Supported-Features AVP to all messages, but that is a small =
negative.



Regards,



Steve




On 3/17/14 4:32 PM, Maria Cruz Bartolome wrote:=







Hello,<=
/p>

 <=
/p>

Well, text needs to be cl=
eaned since it has impacts along the doc, apart from what is being discusse=
d.


Not sure whether it is be=
tter to open a new issue or reopen this one.  Both options are fine wi=
th me.


Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: lunes, 17 de marzo de 2014 18:12

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: Re: [Dime] Snapshot of -02 version of DOIC draft






 


Maria Cruz,



I updated the text based on what was put in the issue tracker when you clos=
ed the issue.



Are you suggesting that this issue needs to be re-opened so we can discuss =
whether OC-Supported-Features is needed in mid-session requests?



Steve




On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:=







Hello Steve,<=
/o:p>


 <=
/p>

According to conclusion o=
n #Issue 51: OC-Supported-Feature AVP MUST be included in all request messa=
ges sent by a DOIC supporting node. (not yet agreed).


 <=
/p>

Text marked in green belo=
w requires updates:


 <=
/p>

5.3.1.  Reacting Nod=
e Endpoint Considerations


 <=
/p>

   The basic pr=
inciple is that the request message initiating endpoint

   (i.e. the &q=
uot;reacting node") announces its support for the overload=



   control mech=
anism by including in the request message the OC-


   Supported-Fe=
atures AVP with those capabilities it supports and is


   willing to u=
se for this Diameter session (or transaction in a case of=



   a non-sessio=
n state maintaining applications, see Section 3.1.2 for

   more details=
 on Diameter sessions). 
It is RECOMMENDED that the


   request mess=
age initiating endpoint includes the capability


   announcement=
 into every request regardless it has had prior message

   exchanges wi=
th the give remote endpoint.  In a case of a Diameter


   session main=
taining application, sending the OC-Supported-Features

   AVP in every=
 message is not really necessary after the initial


   capability a=
nnouncement or until there is a change in supported


   features.


 <=
/p>

   Once the end=
point that initiated the request message receives an


   answer messa=
ge from the remote endpoint, it can detect from the


   received ans=
wer message whether the remote endpoint supports the


   overload con=
trol solution and in a case it does, what features are

   supported.&n=
bsp; The support for the overload control solution is based on<=
/o:p>


   the presence=
 of the OC-Supported-Features AVP in the Diameter answer<=
/p>

   for existing=
 application.


 <=
/p>

 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: s=E1bado, 08 de marzo de 2014 12:19

To: dime@ietf.org

Subject: [Dime] Snapshot of -02 version of DOIC draft






 


All,



I have made updates to the -02 version of the DOIC draft based on resolutio=
n to the following issues:



24, 32, 50, 51, 52, 47 and 37



I had also started to make updates for issues 29, 31 and 34 before we agree=
d that the proposed text needs to be updated in the issue tracker before th=
e edits are made.  I'll clean up these updates when we have the wordin=
g put into issue tracker.



To those who own issues in issue tracker, if we have resolution of the issu=
e on the mailing list please update issue tracker ASAP so the edits can be =
put into the -02 draft.



Thanks,



Steve




 




 






--_000_087A34937E64E74E848732CFF8354B920979DC55ESESSMB101erics_--


From nobody Tue Mar 18 07:53:55 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 65F2C1A037C for ; Tue, 18 Mar 2014 07:53:54 -0700 (PDT)
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 1llLZhNHLQkq for ; Tue, 18 Mar 2014 07:53:52 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 44D371A036E for ; Tue, 18 Mar 2014 07:53:52 -0700 (PDT)
Received: from localhost ([127.0.0.1]:44551 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WPvOh-0006G0-5X; Tue, 18 Mar 2014 15:53:43 +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: srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Tue, 18 Mar 2014 14:53:43 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/34#comment:1
Message-ID: <081.475737e4bfd9084ab0998480b51f18f4@trac.tools.ietf.org>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>
X-Trac-Ticket-ID: 34
In-Reply-To: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: srdonovan@usdonovans.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/VIM4OmwIm5zqA_TwRP3VEO_HkdY
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #34 (draft-docdt-dime-ovli): Semantics of OC-Report-Type AVP
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: Tue, 18 Mar 2014 14:53:54 -0000

#34: Semantics of OC-Report-Type AVP

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Agreed to include the text proposed in the description.

-- 
--------------------------------------+---------------------------
 Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Tue Mar 18 07:59: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 ED9D61A036E for ; Tue, 18 Mar 2014 07:58:58 -0700 (PDT)
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 4h9yuYDhxLZs for ; Tue, 18 Mar 2014 07:58:56 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E8CBD1A03BC for ; Tue, 18 Mar 2014 07:58:37 -0700 (PDT)
Received: from [137.254.4.58] (port=41435 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPvTE-0004Nk-Dr; Tue, 18 Mar 2014 07:58:29 -0700
Message-ID: <53285F11.9080903@usdonovans.com>
Date: Tue, 18 Mar 2014 09:58:25 -0500
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: Maria Cruz Bartolome ,  "dime@ietf.org" 
References: <531AFCA4.1010408@usdonovans.com> <087A34937E64E74E848732CFF8354B920978BCDA@ESESSMB101.ericsson.se> <53272CD9.9080904@usdonovans.com> <087A34937E64E74E848732CFF8354B920979D620@ESESSMB101.ericsson.se> <532842E2.5080102@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DC55@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920979DC55@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------080905090208050209030508"
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/s3pSZcxxQ7J3wyLZJNHeuD1Nf9o
Subject: Re: [Dime] Snapshot of -02 version of DOIC draft
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, 18 Mar 2014 14:58:59 -0000

This is a multi-part message in MIME format.
--------------080905090208050209030508
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Maria Cruz,

My apologies, I misunderstood your comments.

I agree we need to remove the text you indicated, and any other similar
text.  I actually reflected that in the proposal I made yesterday for
the resolution to issue #29.  Hopefully I didn't miss any required changes.

Regards,

Steve

On 3/18/14 9:51 AM, Maria Cruz Bartolome wrote:
>
> Steve,
>
>  
>
> I was in favor already of capability advertisement per transaction J
>
>  
>
> What I meant, but I can see I did not convey my message successfully,
> is that since we have agreed OC-Supported-Features is included in
> every message, then this implies a capability advertisement per
> transaction, and then some text that was before there to consider
> capability advertisement per session should be removed/updated, like
> the one I highlighted in green below.
>
>  
>
> I hope this clarifies
>
> Thanks
>
> /MCruz
>
>  
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* martes, 18 de marzo de 2014 13:58
> *To:* Maria Cruz Bartolome; dime@ietf.org
> *Subject:* Re: [Dime] Snapshot of -02 version of DOIC draft
>
>  
>
> Maria Cruz,
>
> Let me first try to convince you that we don't need the session
> scoping of OC-Supported-Features.  If I'm not successful then we can
> open an issue.
>
> The two options is to scope the capability advertisement to be either
> transaction-based or session-based.  A subset of applications, those
> that do not use sessions, will be transaction-based by definition. 
> Applications that use sessions could use either transaction or session
> scoping on capability advertisement.
>
> The one clear advantage of allowing for session-based scoping is it
> reduces the size of non session initiating requests and answers.  I
> don't see other advantages but may be missing some.
>
> The big disadvantage I see for session-based scoping is the impact on
> agents.  This would require agents to become session aware, something
> that is otherwise not required.  It might also require sharing that
> session-state across multiple agents.  Again, this is not otherwise
> required.
>
> The following are the advantages I see for supporting only
> transaction-based scoping:
>
> 1) Consistency across all applications.  There is no need to have two
> implementations of DOIC, one for session-based applications and
> another for transaction-based applications.  The DOIC handler can
> always go to the same place to determine the results of the
> capabilities exchange -- the OC-Supported-Features AVP in the
> appropriate message -- instead of having to go the to stored session
> state if the scope is session-based.
>
> 2) Statelessness - Transaction-based scoping allows for capability
> advertisement to be completely stateless. 
>
> 3) Agent impacts - Transaction-based scoping removes the need for
> maintaining per session DOIC state in agents.  This is a big advantage
> (in my opinion).
>
> One other point is that supporting transaction-based scoping in
> session-based applications does not break anything.  It does have the
> negative of adding the OC-Supported-Features AVP to all messages, but
> that is a small negative.
>
> Regards,
>
> Steve
>
> On 3/17/14 4:32 PM, Maria Cruz Bartolome wrote:
>
>     Hello,
>
>      
>
>     Well, text needs to be cleaned since it has impacts along the doc,
>     apart from what is being discussed.
>
>     Not sure whether it is better to open a new issue or reopen this
>     one.  Both options are fine with me.
>
>     Cheers
>
>     /MCruz
>
>      
>
>     *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* lunes, 17 de marzo de 2014 18:12
>     *To:* Maria Cruz Bartolome; dime@ietf.org 
>     *Subject:* Re: [Dime] Snapshot of -02 version of DOIC draft
>
>      
>
>     Maria Cruz,
>
>     I updated the text based on what was put in the issue tracker when
>     you closed the issue.
>
>     Are you suggesting that this issue needs to be re-opened so we can
>     discuss whether OC-Supported-Features is needed in mid-session
>     requests?
>
>     Steve
>
>     On 3/11/14 7:06 AM, Maria Cruz Bartolome wrote:
>
>         Hello Steve,
>
>          
>
>         According to conclusion on #Issue 51: OC-Supported-Feature AVP
>         MUST be included in all request messages sent by a DOIC
>         supporting node. (not yet agreed).
>
>          
>
>         Text marked in green below requires updates:
>
>          
>
>         5.3.1.  Reacting Node Endpoint Considerations
>
>          
>
>            The basic principle is that the request message initiating
>         endpoint
>
>            (i.e. the "reacting node") announces its support for the
>         overload
>
>            control mechanism by including in the request message the OC-
>
>            Supported-Features AVP with those capabilities it supports
>         and is
>
>            willing to use for this Diameter session (or transaction in
>         a case of
>
>            a non-session state maintaining applications, see Section
>         3.1.2 for
>
>            more details on Diameter sessions).  It is RECOMMENDED that the
>
>            request message initiating endpoint includes the capability
>
>            announcement into every request regardless it has had prior
>         message
>
>            exchanges with the give remote endpoint.  In a case of a
>         Diameter
>
>            session maintaining application, sending the
>         OC-Supported-Features
>
>            AVP in every message is not really necessary after the initial
>
>            capability announcement or until there is a change in supported
>
>            features.
>
>          
>
>            Once the endpoint that initiated the request message
>         receives an
>
>            answer message from the remote endpoint, it can detect from the
>
>            received answer message whether the remote endpoint
>         supports the
>
>            overload control solution and in a case it does, what
>         features are
>
>            supported.  The support for the overload control solution
>         is based on
>
>            the presence of the OC-Supported-Features AVP in the
>         Diameter answer
>
>            for existing application.
>
>          
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>         *Steve Donovan
>         *Sent:* sábado, 08 de marzo de 2014 12:19
>         *To:* dime@ietf.org 
>         *Subject:* [Dime] Snapshot of -02 version of DOIC draft
>
>          
>
>         All,
>
>         I have made updates to the -02 version of the DOIC draft based
>         on resolution to the following issues:
>
>         24, 32, 50, 51, 52, 47 and 37
>
>         I had also started to make updates for issues 29, 31 and 34
>         before we agreed that the proposed text needs to be updated in
>         the issue tracker before the edits are made.  I'll clean up
>         these updates when we have the wording put into issue tracker.
>
>         To those who own issues in issue tracker, if we have
>         resolution of the issue on the mailing list please update
>         issue tracker ASAP so the edits can be put into the -02 draft.
>
>         Thanks,
>
>         Steve
>
>      
>
>  
>


--------------080905090208050209030508
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

      

      My apologies, I misunderstood your comments.

      

      I agree we need to remove the text you indicated, and any other
      similar text.  I actually reflected that in the proposal I made
      yesterday for the resolution to issue #29.  Hopefully I didn't
      miss any required changes.

      

      Regards,

      

      Steve

      

    
    
On 3/18/14 9:51 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
I
            was in favor already of capability advertisement per
            transaction
          J

        
 

        
What
            I meant, but I can see I did not convey my message
            successfully, is that since we have agreed
            OC-Supported-Features is included in every message, then
            this implies a capability advertisement per transaction, and
            then some text that was before there to consider capability
            advertisement per session should be removed/updated, like
            the one I highlighted in green below.

        
 

        
I
            hope this clarifies

        
Thanks

        
/MCruz

        
 

        

          

            
From:
                Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: martes, 18 de marzo de 2014 13:58

                To: Maria Cruz Bartolome; dime@ietf.org

                Subject: Re: [Dime] Snapshot of -02 version of
                DOIC draft

          

        

        
 

        
Maria Cruz,

          

          Let me first try to convince you that we don't need the
          session scoping of OC-Supported-Features.  If I'm not
          successful then we can open an issue.

          

          The two options is to scope the capability advertisement to be
          either transaction-based or session-based.  A subset of
          applications, those that do not use sessions, will be
          transaction-based by definition.  Applications that use
          sessions could use either transaction or session scoping on
          capability advertisement.

          

          The one clear advantage of allowing for session-based scoping
          is it reduces the size of non session initiating requests and
          answers.  I don't see other advantages but may be missing
          some.

          

          The big disadvantage I see for session-based scoping is the
          impact on agents.  This would require agents to become session
          aware, something that is otherwise not required.  It might
          also require sharing that session-state across multiple
          agents.  Again, this is not otherwise required.

          

          The following are the advantages I see for supporting only
          transaction-based scoping:

          

          1) Consistency across all applications.  There is no need to
          have two implementations of DOIC, one for session-based
          applications and another for transaction-based applications. 
          The DOIC handler can always go to the same place to determine
          the results of the capabilities exchange -- the
          OC-Supported-Features AVP in the appropriate message --
          instead of having to go the to stored session state if the
          scope is session-based.
          

          

          2) Statelessness - Transaction-based scoping allows for
          capability advertisement to be completely stateless. 
          

          

          3) Agent impacts - Transaction-based scoping removes the need
          for maintaining per session DOIC state in agents.  This is a
          big advantage (in my opinion).

          

          One other point is that supporting transaction-based scoping
          in session-based applications does not break anything.  It
          does have the negative of adding the OC-Supported-Features AVP
          to all messages, but that is a small negative.

          

          Regards,

          

          Steve

        

          
On 3/17/14 4:32 PM, Maria Cruz Bartolome
            wrote:

        

        

          
Hello,

          
 

          
Well,
              text needs to be cleaned since it has impacts along the
              doc, apart from what is being discussed.

          
Not
              sure whether it is better to open a new issue or reopen
              this one.  Both options are fine with me.

          
Cheers

          
/MCruz

          
 

          

            

              
From:
                  Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Sent: lunes, 17 de marzo de 2014 18:12

                  To: Maria Cruz Bartolome; dime@ietf.org

                  Subject: Re: [Dime] Snapshot of -02 version of
                  DOIC draft

            

          

          
 

          
Maria Cruz,

            

            I updated the text based on what was put in the issue
            tracker when you closed the issue.

            

            Are you suggesting that this issue needs to be re-opened so
            we can discuss whether OC-Supported-Features is needed in
            mid-session requests?

            

            Steve

          

            
On 3/11/14 7:06 AM, Maria Cruz
              Bartolome wrote:

          

          

            
Hello
                Steve,

            
 

            
According
                to conclusion on #Issue 51: OC-Supported-Feature AVP
                MUST be included in all request messages sent by a DOIC
                supporting node. (not yet agreed).

            
 

            
Text
                marked in green below requires updates:

            
 

            
5.3.1. 
                Reacting Node Endpoint Considerations

            
 

            
  
                The basic principle is that the request message
                initiating endpoint

            
  
                (i.e. the "reacting node") announces its support for the
                overload

            
  
                control mechanism by including in the request message
                the OC-

            
  
                Supported-Features AVP with those capabilities it
                supports and is

            
  
                willing to use for this Diameter session (or transaction
                in a case of

            
  
                a non-session state maintaining applications, see
                Section 3.1.2 for

            
  
                more details on Diameter sessions). 
              It
                is RECOMMENDED that the

            
  
                request message initiating endpoint includes the
                capability

            
  
                announcement into every request regardless it has had
                prior message

            
  
                exchanges with the give remote endpoint.  In a case of a
                Diameter

            
  
                session maintaining application, sending the
                OC-Supported-Features

            
  
                AVP in every message is not really necessary after the
                initial

            
  
                capability announcement or until there is a change in
                supported

            
  
                features.

            
 

            
  
                Once the endpoint that initiated the request message
                receives an

            
  
                answer message from the remote endpoint, it can detect
                from the

            
  
                received answer message whether the remote endpoint
                supports the

            
  
                overload control solution and in a case it does, what
                features are

            
  
                supported.  The support for the overload control
                solution is based on

            
  
                the presence of the OC-Supported-Features AVP in the
                Diameter answer

            
  
                for existing application.

            
 

            
 

            
Best
                regards

            
/MCruz

            
 

            

              

                
From:
                    DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of Steve Donovan

                    Sent: sábado, 08 de marzo de 2014 12:19

                    To: dime@ietf.org

                    Subject: [Dime] Snapshot of -02 version of
                    DOIC draft

              

            

            
 

            
All,

              

              I have made updates to the -02 version of the DOIC draft
              based on resolution to the following issues:

              

              24, 32, 50, 51, 52, 47 and 37

              

              I had also started to make updates for issues 29, 31 and
              34 before we agreed that the proposed text needs to be
              updated in the issue tracker before the edits are made. 
              I'll clean up these updates when we have the wording put
              into issue tracker.

              

              To those who own issues in issue tracker, if we have
              resolution of the issue on the mailing list please update
              issue tracker ASAP so the edits can be put into the -02
              draft.

              

              Thanks,

              

              Steve

          

          
 

        

        
 

      

    

    

  


--------------080905090208050209030508--


From nobody Tue Mar 18 08:00: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 2F9B31A046B for ; Tue, 18 Mar 2014 08:00:04 -0700 (PDT)
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_20=-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 2w7rS21tGHtq for ; Tue, 18 Mar 2014 08:00:02 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 84D051A0125 for ; Tue, 18 Mar 2014 08:00:01 -0700 (PDT)
Received: from [137.254.4.58] (port=44032 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPvUZ-0005t3-T3 for dime@ietf.org; Tue, 18 Mar 2014 07:59:52 -0700
Message-ID: <53285F65.30600@usdonovans.com>
Date: Tue, 18 Mar 2014 09:59:49 -0500
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.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <081.475737e4bfd9084ab0998480b51f18f4@trac.tools.ietf.org>
In-Reply-To: <081.475737e4bfd9084ab0998480b51f18f4@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------010409080608090701050501"
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/KyKE17e1VSZou6SRP5qqD4VVYFE
Subject: Re: [Dime] [dime] #34 (draft-docdt-dime-ovli): Semantics of OC-Report-Type AVP
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, 18 Mar 2014 15:00:04 -0000

This is a multi-part message in MIME format.
--------------010409080608090701050501
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

I closed this issue for Ulrich.  I have already reflected the changes
proposed by Ulrich in the current snapshot of the -02 draft.

Steve

On 3/18/14 9:53 AM, dime issue tracker wrote:
> #34: Semantics of OC-Report-Type AVP
>
> Changes (by srdonovan@usdonovans.com):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> Comment:
>
>  Agreed to include the text proposed in the description.
>


--------------010409080608090701050501
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    I closed this issue for
      Ulrich.  I have already reflected the changes proposed by Ulrich
      in the current snapshot of the -02 draft.

      

      Steve

      

    
    
On 3/18/14 9:53 AM, dime issue tracker
      wrote:

    

    

      
#34: Semantics of OC-Report-Type AVP

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Agreed to include the text proposed in the description.



    

    

  


--------------010409080608090701050501--


From nobody Tue Mar 18 09:19: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 005981A06D9 for ; Tue, 18 Mar 2014 09:19:21 -0700 (PDT)
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 edwh4d_1QTAk for ; Tue, 18 Mar 2014 09:19:19 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 9E85B1A06CC for ; Tue, 18 Mar 2014 09:19:19 -0700 (PDT)
Received: from [137.254.4.58] (port=30488 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPwjO-0006vq-AB for dime@ietf.org; Tue, 18 Mar 2014 09:19:10 -0700
Message-ID: <532871FF.1050903@usdonovans.com>
Date: Tue, 18 Mar 2014 11:19:11 -0500
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" 
Content-Type: multipart/alternative; boundary="------------080801000107030505090706"
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/s0A8P94BX1-VObi0VQc1cfeL0og
Subject: [Dime] Issue #45 proposed wording changes
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, 18 Mar 2014 16:19:21 -0000

This is a multi-part message in MIME format.
--------------080801000107030505090706
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

I believe we have reached consensus on this issue that validity duration
with a value of zero is used by the reporting node to indicate that an
overload report is no longer valid and should be removed.

I also believe that we have agreed that we will support a reduction
percentage of zero with a non zero validity duration.

To this end, I propose the following specific wording changes in the -01
draft.

Regards,

Steve

-----

Section 4.5, Paragraph 1:

First sentence - change "since" to "after". (Editorial change)

Change:

Validity duration values 0
   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
   Invalid validity duration values are treated as if the OC-Validity-
   Duration AVP were not present.


To:

Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be
used.  Invalid duration values are treated as if the
OC-Validity-Duration AVP were not present and result in the default
value being used.

Paragraph 3:

Replace:

This leaves no need for the
   reacting node to reason or guess the overload condition of the
   reporting node.


With:

This is achieved by sending an updated overload report (meaning it must
contain a new sequence number) with the OC-Validity-Duration AVP value
set to zero ("0").

Section 5.5.2, Paragraph 7

Change:

   value == 0
      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

To:
    value == 0

          Indicates that no traffic reduction has been requested.   As a
result the overload state, including the sequence number, MUST NOT be
removed and future overload reports of the same type from the same
reporting node must follow the rules for new sequence numbers.

New paragraphs at end of the section:

A value of zero ("0") received in the OC-Validity-Duration in an updated
overload report indicates that the overload condition has ended and that
the overload state is no longer valid. 

In the case that the validity duration expires or is explicitly signaled
as being no longer valid the state associated with the overload report
MUST be removed and any abatement associated with the overload report
MUST be ended.  After removing the overload state the sequence number
MUST NOT be used for future comparisons of sequence numbers.

Section 5.5.3, New paragraph at the end:

The reporting node SHOULD indicate the end of an overload occurrence by
sending a new OLR with OC-Validity-Duration set to a value of zero
("0").  The reporting node SHOULD insure that all reacting nodes receive
the updated overload report.

--------------080801000107030505090706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      I believe we have reached consensus on this issue that validity
      duration with a value of zero is used by the reporting node to
      indicate that an overload report is no longer valid and should be
      removed.

      

      I also believe that we have agreed that we will support a
      reduction percentage of zero with a non zero validity duration.

      

      To this end, I propose the following specific wording changes in
      the -01 draft.

      

      Regards,

      

      Steve

      

      -----

      

      Section 4.5, Paragraph 1:

      

      First sentence - change "since" to "after". (Editorial change)

      

      Change:

    
      
    
    
Validity duration values 0
   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
   Invalid validity duration values are treated as if the OC-Validity-
   Duration AVP were not present.

    

      To:

      

      Validity duration with values above 86400 (i.e.; 24 hours) MUST
      NOT be used.  Invalid duration values are treated as if the
      OC-Validity-Duration AVP were not present and result in the
      default value being used.

      

      Paragraph 3:

      

      Replace:

    
      
    
    
This leaves no need for the
   reacting node to reason or guess the overload condition of the
   reporting node.

    

      With:

      

      This is achieved by sending an updated overload report (meaning it
      must contain a new sequence number) with the OC-Validity-Duration
      AVP value set to zero ("0").

      

      Section 5.5.2, Paragraph 7

      

      Change:

    
      
    
    
   value == 0


      Indicates explicitly the end of overload condition and the
      reacting node SHOULD NOT apply the traffic abatement algorithm
      procedures anymore for the given reporting node (or realm).

    To:

          value == 0

      

                Indicates that no traffic reduction has been
      requested.   As a result the overload state, including the
      sequence number, MUST NOT be removed and future overload reports
      of the same type from the same reporting node must follow the
      rules for new sequence numbers.

      

      New paragraphs at end of the section:

      

      A value of zero ("0") received in the OC-Validity-Duration in an
      updated overload report indicates that the overload condition has
      ended and that the overload state is no longer valid.  

      

      In the case that the validity duration expires or is explicitly
      signaled as being no longer valid the state associated with the
      overload report MUST be removed and any abatement associated with
      the overload report MUST be ended.  After removing the overload
      state the sequence number MUST NOT be used for future comparisons
      of sequence numbers.

      

      Section 5.5.3, New paragraph at the end:

      

      The reporting node SHOULD indicate the end of an overload
      occurrence by sending a new OLR with OC-Validity-Duration set to a
      value of zero ("0").  The reporting node SHOULD insure that all
      reacting nodes receive the updated overload report.

    
  


--------------080801000107030505090706--


From nobody Tue Mar 18 09:47:29 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 B46411A06D8 for ; Tue, 18 Mar 2014 09:47:26 -0700 (PDT)
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 Gc5oVLQ_2p7y for ; Tue, 18 Mar 2014 09:47:24 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id E6A391A06E8 for ; Tue, 18 Mar 2014 09:47:23 -0700 (PDT)
Received: from [137.254.4.58] (port=27279 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPxAX-0005vj-PL for dime@ietf.org; Tue, 18 Mar 2014 09:47:15 -0700
Message-ID: <53287893.5020203@usdonovans.com>
Date: Tue, 18 Mar 2014 11:47:15 -0500
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: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060908040404060209010906"
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/TUkGGk3UdACnMRyO59XEyGTuol0
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 18 Mar 2014 16:47:26 -0000

This is a multi-part message in MIME format.
--------------060908040404060209010906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

All,

Do we have consensus that the OC-Report-Type AVP is required?

If so then one change would be as indicated in the syntax definition
proposed by Lionel.  We would also remove wording on the default value.

Jouni,

How do we indicate a fixed position for an AVP? 

I presonally don't see this as critical but we can add this requirement
if there is consensus.

Regards,

Steve

On 2/28/14 10:27 AM, Jouni Korhonen wrote:
> Hi,
>
> How having the AVP could be less error prone if it has a default
> value and the receiver knows exactly how to proceed when the AVP
> is not present?
>
> If a node does not include it when it should, the implementation
> is broken. Wouldn't a broken node be able to put wrong report
> type into the AVP even if the AVP is mandatory?
>
> Anyway, if it is my statement keeping issue #54 still open, consider
> it resolved from my side. I am OK making the OC-Report-Type AVP as
> required/mandatory AVP. Should we also consider it having a fixed
> position just after the OC-Sequence-Number AVP as well since it is
> going to in every OC-OLR?
>
> - Jouni
>
>
>
> On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:
>
>> Hello all,
>>
>> I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
>>
>> I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
>>
>> Best regards
>> /MCruz
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>> Sent: viernes, 14 de febrero de 2014 23:13
>> To: Jouni Korhonen
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>
>> I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
>>
>> On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:
>>
>>> Agree that it is a small optimization, which I put there because at 
>>> the beginning there seemed to be a lot of worry on every extra AVP ;-)
>>>
>>> I prefer having the AVP optional but with a default value just like it 
>>> is now. We have the same for the reduction percentage and the validity 
>>> time as well.
>>>
>>> - Jouni
>>>
>>> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:
>>>
>>>> Hi Mcruz
>>>>
>>>> The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
>>>> We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
>>>>
>>>> Best regards
>>>>
>>>> JJacques
>>>>
>>>>
>>>>
>>>>
>>>> -----Message d'origine-----
>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de 
>>>> lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À : 
>>>> dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 
>>>> [dime] #54: OC-Report-Type as mandatory AVP
>>>>
>>>> Hi Maria Cruz,
>>>>
>>>> I'm assuming that you mean "required" instead of "mandatory", right?
>>>>
>>>> So instead of:
>>>>
>>>> OC-OLR ::= < AVP Header: TBD2 >
>>>>            < OC-Sequence-Number >
>>>>            [ OC-Report-Type ]
>>>>            [ OC-Reduction-Percentage ]
>>>>            [ OC-Validity-Duration ]
>>>>          * [ AVP ]
>>>>
>>>> You would prefer:
>>>>
>>>> OC-OLR ::= < AVP Header: TBD2 >
>>>>            < OC-Sequence-Number >
>>>>            { OC-Report-Type }
>>>>            [ OC-Reduction-Percentage ]
>>>>            [ OC-Validity-Duration ]
>>>>          * [ AVP ]
>>>>
>>>> And I'm fine with this proposal.
>>>>
>>>> Cheers,
>>>>
>>>> Lionel
>>>>
>>>> -----Message d'origine-----
>>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
>>>> tracker Envoyé : mercredi 12 février 2014 15:26 À : 
>>>> maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 
>>>> [dime] #54: OC-Report-Type as mandatory AVP
>>>>
>>>> #54: OC-Report-Type as mandatory AVP
>>>>
>>>> Now in chapter 4.6:
>>>>
>>>>  The default value of the OC-Report-Type AVP is 0 (i.e. the host
>>>>  report).
>>>>
>>>> This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
>>>>
>>>> --
>>>> -----------------------------------------------+---------------------
>>>> -----------------------------------------------+---
>>>> -----------------------------------------------+---
>>>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>>>   Type:  defect                             |  Bartolomé
>>>> Priority:  major                              |     Status:  new
>>>> Component:  draft-docdt-dime-ovli              |  Milestone:
>>>> Severity:  Active WG Document                 |    Version:  1.0
>>>>                                             |   Keywords:
>>>> -----------------------------------------------+---------------------
>>>> -----------------------------------------------+---
>>>> -----------------------------------------------+---
>>>>
>>>> Ticket URL: 
>>>> 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
>


--------------060908040404060209010906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    All,

      

      Do we have consensus that the OC-Report-Type AVP is required?

      

      If so then one change would be as indicated in the syntax
      definition proposed by Lionel.  We would also remove wording on
      the default value.

      

      Jouni,

      

      How do we indicate a fixed position for an AVP?  

      

      I presonally don't see this as critical but we can add this
      requirement if there is consensus.

      

      Regards,

      

      Steve

      

    
    
On 2/28/14 10:27 AM, Jouni Korhonen
      wrote:

    

    

      
Hi,

How having the AVP could be less error prone if it has a default
value and the receiver knows exactly how to proceed when the AVP
is not present?

If a node does not include it when it should, the implementation
is broken. Wouldn't a broken node be able to put wrong report
type into the AVP even if the AVP is mandatory?

Anyway, if it is my statement keeping issue #54 still open, consider
it resolved from my side. I am OK making the OC-Report-Type AVP as
required/mandatory AVP. Should we also consider it having a fixed
position just after the OC-Sequence-Number AVP as well since it is
going to in every OC-OLR?

- Jouni



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



      

        
Hello all,

I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.

I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: viernes, 14 de febrero de 2014 23:13
To: Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.

On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:



        

          
Agree that it is a small optimization, which I put there because at 
the beginning there seemed to be a lot of worry on every extra AVP ;-)

I prefer having the AVP optional but with a default value just like it 
is now. We have the same for the reduction percentage and the validity 
time as well.

- Jouni

On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:



          

            
Hi Mcruz

The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.

Best regards

JJacques




-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de 
lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À : 
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 
[dime] #54: OC-Report-Type as mandatory AVP

Hi Maria Cruz,

I'm assuming that you mean "required" instead of "mandatory", right?

So instead of:

OC-OLR ::= < AVP Header: TBD2 >
           < OC-Sequence-Number >
           [ OC-Report-Type ]
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]

You would prefer:

OC-OLR ::= < AVP Header: TBD2 >
           < OC-Sequence-Number >
           { OC-Report-Type }
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]

And I'm fine with this proposal.

Cheers,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
tracker Envoyé : mercredi 12 février 2014 15:26 À : 
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 
[dime] #54: OC-Report-Type as mandatory AVP

#54: OC-Report-Type as mandatory AVP

Now in chapter 4.6:

 The default value of the OC-Report-Type AVP is 0 (i.e. the host
 report).

This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.

--
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
  Type:  defect                             |  Bartolomé
Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
Severity:  Active WG Document                 |    Version:  1.0
                                            |   Keywords:
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>
dime <http://tools.ietf.org/wg/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



    

    

  


--------------060908040404060209010906--


From nobody Tue Mar 18 10:16: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 7A8061A0425 for ; Tue, 18 Mar 2014 10:16:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 NgaexTrf6vLQ for ; Tue, 18 Mar 2014 10:16:42 -0700 (PDT)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 013B51A042C for ; Tue, 18 Mar 2014 10:16:37 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-31-53287f6c4878
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 04.B4.04853.C6F78235; Tue, 18 Mar 2014 18:16:28 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Tue, 18 Mar 2014 18:16:27 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPKdHmQtBV/d0cbEW2/a46j08/xpq/f2cwgCfAbtyAAAeTAA==
Date: Tue, 18 Mar 2014 17:16:27 +0000
Message-ID: <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com>
In-Reply-To: <53287893.5020203@usdonovans.com>
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_087A34937E64E74E848732CFF8354B920979DDA2ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW5OvUawQed3VYu5vSvYLDY08Tgw eSxZ8pPJY9XbPtYApigum5TUnMyy1CJ9uwSujCen/7EWrH3CWLFwl24DY+NRxi5GTg4JAROJ rr/n2CFsMYkL99azdTFycQgJnGCUuHD0CTuEs4RR4s+qOWwgVWwCdhKXTr9gArFFBHwljnee ZgGxhQXsJS5cn80KEXeQ+D77PCOE7SQxac5TsA0sAqoSu7YdAKrh4OAF6r20XxVi/jQWiVer TjCD1HAK6EnMW38ObBcj0EXfT60B28UsIC5x68l8JohLBSSW7DnPDGGLSrx8/I8VwlaSaFzy hBWiPl/i9L4usBt4BQQlTs58wjKBUWQWklGzkJTNQlIGEdeTuDF1ChuErS2xbOFrZghbV2LG v0MsyOILGNlXMUoWpxYX56YbGejlpueW6KUWZSYXF+fn6RWnbmIERtjBLb+NdjCe3GN/iFGa g0VJnPc6a02QkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkb/+uQTd6pvKnImTN2nP9FSPU9V X/BMuXyb0BWHDUI2W6dccf32qv9Dh8it9R3PN/G5X1xjG+fDKd6kO3lW0BzTPAcngcm/O6N3 v71dvvFOn4tKrLMP4/r5ERuSt+2uk/BYOlF512uWZPdAK563AWw1n2yqJKKiDnCHL7DL47V9 +3J7lZBlrhJLcUaioRZzUXEiAKoZ/2J+AgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gWvlp27T1f22ry3KUNxy6F9PKgo
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 18 Mar 2014 17:16:46 -0000

--_000_087A34937E64E74E848732CFF8354B920979DDA2ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.
This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.
If there is consensus on this, I will go with this.
Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 18 de marzo de 2014 17:47
To: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

All,

Do we have consensus that the OC-Report-Type AVP is required?

If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.

Jouni,

How do we indicate a fixed position for an AVP?

I presonally don't see this as critical but we can add this requirement if =
there is consensus.

Regards,

Steve
On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP

is not present?



If a node does not include it when it should, the implementation

is broken. Wouldn't a broken node be able to put wrong report

type into the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP ;-)



I prefer having the AVP optional but with a default value just like it

is now. We have the same for the reduction percentage and the validity

time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

 report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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




--_000_087A34937E64E74E848732CFF8354B920979DDA2ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

I think the agreement ten=
dency is the contrary: OC-Report-Type is not required, while default value =
is Host. i.e. it will remain as it is now in the draft.

This may be of some advan=
tage for some applications that may only use Host, as long as they may neve=
r generate Realm reports.


If there is consensus on =
this, I will go with this.


Best regards


/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?  



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve




On 2/28/14 10:27 AM, Jouni Korhonen wrote:






 


Hi,


 


How having the AVP could be less error prone if it has a default<=
/o:p>


value and the receiver knows exactly how to proceed when the AVP<=
/o:p>


is not present?


 


If a node does not include it when it should, the implementation<=
/o:p>


is broken. Wouldn't a broken node be able to put wrong report


type into the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 still open, consider


it resolved from my side. I am OK making the OC-Report-Type AVP as


required/mandatory AVP. Should we also consider it having a fixed=



position just after the OC-Sequence-Number AVP as well since it is


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>=
 wrote:


 




 


Hello all,


 


I understand JJ point of view, but I still tend to prefer to make it m=
andatory, since I think this is less error-prone, since the only node that =
knows the requested Report-Type is the reporting, if for any reason a repor=
ting is omitting it (since it is optional), it will be always interpreted a=
s HOST, but this type may be wrong.


 


I think DEFAULT values should never be error-prone, but used in "=
general cases", as a simplification, like e.g. a default for the Valid=
ity-Duration. Default Validity-Duration will never be an "error",=
 it could be not the best value (compared with another value perfectly tune=
d to reporting node overload situation) but never the use of a Default valu=
e should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


 


I actually prefer making it mandatory. The cost of adding it is trivia=
l--even more so for a reporting node that only supports the default. The va=
lue of having it is less opportunity for interop errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 




 


Agree that it is a small optimization, which I put there because at 


the beginning there seemed to be a lot of worry on every extra AVP ;-)=



 


I prefer having the AVP optional but with a default value just like it=
 


is now. We have the same for the reduction percentage and the validity=
 


time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUE=
S)" <jea=
n-jacques.trottin@alcatel-lucent.com> wrote:


 




Hi Mcruz


 


The current description indicates that when not present the OLR is of =
type Host, which was fine for me and keeps my preference. 


We may have  deployments where Realm OLR is not used, or where st=
atistically the HOST type is the most frequent, so to have the grouped OLR-=
AVP containing a minimum of AVPs minimizes parsing. I agree it is a small o=
ptimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de 


lionel.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 : 


dime@ietf.org; maria.cruz.bartolome@ericsson.com Ob=
jet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" instead of "manda=
tory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


           < OC-S=
equence-Number >


           [ OC-Repo=
rt-Type ]


           [ OC-Redu=
ction-Percentage ]


           [ OC-Vali=
dity-Duration ]


         * [ AVP ]<=
/pre>

 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


           < OC-S=
equence-Number >


           { OC-Repo=
rt-Type }


           [ OC-Redu=
ction-Percentage ]


           [ OC-Vali=
dity-Duration ]


         * [ AVP ]<=
/pre>

 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounce=
s@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 : <=
/pre>

maria.cruz.bartol=
ome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0 (i.e. the host<=
/o:p>


 report).


 


This AVP is always required, right? Then, I think it is more precise t=
hat  we define this AVP as mandatory.


 


--


-----------------------------------------------+------------------=
---


-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  m=
aria.cruz.bartolome@ericsson.com  |      =
Owner:  MCruz


  Type:  defect       &nb=
sp;            =
         |  Bartolom=E9


Priority:  major        &=
nbsp;           &nbs=
p;         |    =
; Status:  new


Component:  draft-docdt-dime-ovli     &n=
bsp;        |  Milestone:


Severity:  Active WG Document      =
           |  &=
nbsp; Version:  1.0


           &nbs=
p;            &=
nbsp;           &nbs=
p;       |   Keywords:

-----------------------------------------------+------------------=
---


-----------------------------------------------+---

-----------------------------------------------+---

 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>


dime <http://tools.ietf.=
org/wg/dime/>


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


_____________________________________________________________________<=
o:p>


____________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploite=
s ou copies sans autorisation. Si vous avez recu ce message par erreur, veu=
illez le signaler a l'expediteur et le detruire ainsi que les pieces jointe=
s. Les messages electroniques etant susceptibles d'alteration, Orange decli=
ne toute responsabilite si ce message a ete altere, deforme ou falsifie. Me=
rci.


 


This message and its attachments may contain confidential or privilege=
d 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.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




 


_______________________________________________


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_087A34937E64E74E848732CFF8354B920979DDA2ESESSMB101erics_--


From nobody Tue Mar 18 10:29:59 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 3F45C1A071B for ; Tue, 18 Mar 2014 10:29:58 -0700 (PDT)
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 fu5LwUyo9enP for ; Tue, 18 Mar 2014 10:29:54 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id 29C891A0717 for ; Tue, 18 Mar 2014 10:29:54 -0700 (PDT)
Received: from [137.254.4.58] (port=61927 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WPxpb-0002yU-1h; Tue, 18 Mar 2014 10:29:45 -0700
Message-ID: <53288284.5040606@usdonovans.com>
Date: Tue, 18 Mar 2014 12:29:40 -0500
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: Maria Cruz Bartolome ,  "dime@ietf.org" 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------040805060409070302080805"
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/Eh4nPFb-ug5sOlxSEvUq9BiqD4k
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 18 Mar 2014 17:29:58 -0000

This is a multi-part message in MIME format.
--------------040805060409070302080805
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I'm ok with either direction but generally lean toward being explicit.

Do we have other opinions? 

Steve
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
>
> Hello,
>
> I think the agreement tendency is the contrary: OC-Report-Type is not
> required, while default value is Host. i.e. it will remain as it is
> now in the draft.
>
> This may be of some advantage for some applications that may only use
> Host, as long as they may never generate Realm reports.
>
> If there is consensus on this, I will go with this.
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* martes, 18 de marzo de 2014 17:47
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> All,
>
> Do we have consensus that the OC-Report-Type AVP is required?
>
> If so then one change would be as indicated in the syntax definition
> proposed by Lionel.  We would also remove wording on the default value.
>
> Jouni,
>
> How do we indicate a fixed position for an AVP? 
>
> I presonally don't see this as critical but we can add this
> requirement if there is consensus.
>
> Regards,
>
> Steve
>
> On 2/28/14 10:27 AM, Jouni Korhonen wrote:
>
>      
>
>     Hi,
>
>      
>
>     How having the AVP could be less error prone if it has a default
>
>     value and the receiver knows exactly how to proceed when the AVP
>
>     is not present?
>
>      
>
>     If a node does not include it when it should, the implementation
>
>     is broken. Wouldn't a broken node be able to put wrong report
>
>     type into the AVP even if the AVP is mandatory?
>
>      
>
>     Anyway, if it is my statement keeping issue #54 still open, consider
>
>     it resolved from my side. I am OK making the OC-Report-Type AVP as
>
>     required/mandatory AVP. Should we also consider it having a fixed
>
>     position just after the OC-Sequence-Number AVP as well since it is
>
>     going to in every OC-OLR?
>
>      
>
>     - Jouni
>
>      
>
>      
>
>      
>
>     On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome   wrote:
>
>      
>
>          
>
>         Hello all,
>
>          
>
>         I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
>
>          
>
>         I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>
>         Sent: viernes, 14 de febrero de 2014 23:13
>
>         To: Jouni Korhonen
>
>         Cc: dime@ietf.org 
>
>         Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>          
>
>         I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
>
>          
>
>         On Feb 13, 2014, at 6:05 AM, Jouni Korhonen   wrote:
>
>          
>
>              
>
>             Agree that it is a small optimization, which I put there because at 
>
>             the beginning there seemed to be a lot of worry on every extra AVP ;-)
>
>              
>
>             I prefer having the AVP optional but with a default value just like it 
>
>             is now. We have the same for the reduction percentage and the validity 
>
>             time as well.
>
>              
>
>             - Jouni
>
>              
>
>             On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"   wrote:
>
>              
>
>                 Hi Mcruz
>
>                  
>
>                 The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
>
>                 We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
>
>                  
>
>                 Best regards
>
>                  
>
>                 JJacques
>
>                  
>
>                  
>
>                  
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de 
>
>                 lionel.morand@orange.com  Envoyé : mercredi 12 février 2014 15:46 À : 
>
>                 dime@ietf.org ; maria.cruz.bartolome@ericsson.com  Objet : Re: [Dime] 
>
>                 [dime] #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 Hi Maria Cruz,
>
>                  
>
>                 I'm assuming that you mean "required" instead of "mandatory", right?
>
>                  
>
>                 So instead of:
>
>                  
>
>                 OC-OLR ::= < AVP Header: TBD2 >
>
>                            < OC-Sequence-Number >
>
>                            [ OC-Report-Type ]
>
>                            [ OC-Reduction-Percentage ]
>
>                            [ OC-Validity-Duration ]
>
>                          * [ AVP ]
>
>                  
>
>                 You would prefer:
>
>                  
>
>                 OC-OLR ::= < AVP Header: TBD2 >
>
>                            < OC-Sequence-Number >
>
>                            { OC-Report-Type }
>
>                            [ OC-Reduction-Percentage ]
>
>                            [ OC-Validity-Duration ]
>
>                          * [ AVP ]
>
>                  
>
>                 And I'm fine with this proposal.
>
>                  
>
>                 Cheers,
>
>                  
>
>                 Lionel
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
>
>                 tracker Envoyé : mercredi 12 février 2014 15:26 À : 
>
>                 maria.cruz.bartolome@ericsson.com  Cc : dime@ietf.org  Objet : [Dime] 
>
>                 [dime] #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 Now in chapter 4.6:
>
>                  
>
>                  The default value of the OC-Report-Type AVP is 0 (i.e. the host
>
>                  report).
>
>                  
>
>                 This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
>
>                  
>
>                 --
>
>                 -----------------------------------------------+---------------------
>
>                 -----------------------------------------------+---
>
>                 -----------------------------------------------+---
>
>                 Reporter:  maria.cruz.bartolome@ericsson.com   |      Owner:  MCruz
>
>                   Type:  defect                             |  Bartolomé
>
>                 Priority:  major                              |     Status:  new
>
>                 Component:  draft-docdt-dime-ovli              |  Milestone:
>
>                 Severity:  Active WG Document                 |    Version:  1.0
>
>                                                             |   Keywords:
>
>                 -----------------------------------------------+---------------------
>
>                 -----------------------------------------------+---
>
>                 -----------------------------------------------+---
>
>                  
>
>                 Ticket URL:  
>
>                 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
>
>      
>
>  
>


--------------040805060409070302080805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I'm ok with either
      direction but generally lean toward being explicit.

      

      Do we have other opinions?  

      

      Steve

    
    
On 3/18/14 12:16 PM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Hello,

        
I
            think the agreement tendency is the contrary: OC-Report-Type
            is not required, while default value is Host. i.e. it will
            remain as it is now in the draft.

        
This
            may be of some advantage for some applications that may only
            use Host, as long as they may never generate Realm reports.

        
If
            there is consensus on this, I will go with this.

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Steve Donovan

                Sent: martes, 18 de marzo de 2014 17:47

                To: dime@ietf.org

                Subject: Re: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        
All,

          

          Do we have consensus that the OC-Report-Type AVP is required?

          

          If so then one change would be as indicated in the syntax
          definition proposed by Lionel.  We would also remove wording
          on the default value.

          

          Jouni,

          

          How do we indicate a fixed position for an AVP?  

          

          I presonally don't see this as critical but we can add this
          requirement if there is consensus.

          

          Regards,

          

          Steve

        

          
On 2/28/14 10:27 AM, Jouni Korhonen
            wrote:

        

        

          
 

          
Hi,

          
 

          
How having the AVP could be less error prone if it has a default

          
value and the receiver knows exactly how to proceed when the AVP

          
is not present?

          
 

          
If a node does not include it when it should, the implementation

          
is broken. Wouldn't a broken node be able to put wrong report

          
type into the AVP even if the AVP is mandatory?

          
 

          
Anyway, if it is my statement keeping issue #54 still open, consider

          
it resolved from my side. I am OK making the OC-Report-Type AVP as

          
required/mandatory AVP. Should we also consider it having a fixed

          
position just after the OC-Sequence-Number AVP as well since it is

          
going to in every OC-OLR?

          
 

          
- Jouni

          
 

          
 

          
 

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

          
 

          

            
 

            
Hello all,

            
 

            
I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.

            
 

            
I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.

            
 

            
Best regards

            
/MCruz

            
 

            
-----Original Message-----

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

            
Sent: viernes, 14 de febrero de 2014 23:13

            
To: Jouni Korhonen

            
Cc: dime@ietf.org

            
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

            
 

            
I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.

            
 

            
On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

            
 

            

              
 

              
Agree that it is a small optimization, which I put there because at 

              
the beginning there seemed to be a lot of worry on every extra AVP ;-)

              
 

              
I prefer having the AVP optional but with a default value just like it 

              
is now. We have the same for the reduction percentage and the validity 

              
time as well.

              
 

              
- Jouni

              
 

              
On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:

              
 

              

                
Hi Mcruz

                
 

                
The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 

                
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.

                
 

                
Best regards

                
 

                
JJacques

                
 

                
 

                
 

                
 

                
-----Message d'origine-----

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de 

                
lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À : 

                
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 

                
[dime] #54: OC-Report-Type as mandatory AVP

                
 

                
Hi Maria Cruz,

                
 

                
I'm assuming that you mean "required" instead of "mandatory", right?

                
 

                
So instead of:

                
 

                
OC-OLR ::= < AVP Header: TBD2 >

                
           < OC-Sequence-Number >

                
           [ OC-Report-Type ]

                
           [ OC-Reduction-Percentage ]

                
           [ OC-Validity-Duration ]

                
         * [ AVP ]

                
 

                
You would prefer:

                
 

                
OC-OLR ::= < AVP Header: TBD2 >

                
           < OC-Sequence-Number >

                
           { OC-Report-Type }

                
           [ OC-Reduction-Percentage ]

                
           [ OC-Validity-Duration ]

                
         * [ AVP ]

                
 

                
And I'm fine with this proposal.

                
 

                
Cheers,

                
 

                
Lionel

                
 

                
-----Message d'origine-----

                
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 

                
tracker Envoyé : mercredi 12 février 2014 15:26 À : 

                
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 

                
[dime] #54: OC-Report-Type as mandatory AVP

                
 

                
#54: OC-Report-Type as mandatory AVP

                
 

                
Now in chapter 4.6:

                
 

                
 The default value of the OC-Report-Type AVP is 0 (i.e. the host

                
 report).

                
 

                
This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.

                
 

                
--

                
-----------------------------------------------+---------------------

                
-----------------------------------------------+---

                
-----------------------------------------------+---

                
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

                
  Type:  defect                             |  Bartolomé

                
Priority:  major                              |     Status:  new

                
Component:  draft-docdt-dime-ovli              |  Milestone:

                
Severity:  Active WG Document                 |    Version:  1.0

                
                                            |   Keywords:

                
-----------------------------------------------+---------------------

                
-----------------------------------------------+---

                
-----------------------------------------------+---

                
 

                
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>

                
dime <http://tools.ietf.org/wg/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

          
 

        

        
 

      

    

    

  


--------------040805060409070302080805--


From nobody Tue Mar 18 13:34:04 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 8D02D1A044D for ; Tue, 18 Mar 2014 13:34:00 -0700 (PDT)
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 lft8DxxuqDxr for ; Tue, 18 Mar 2014 13:33:55 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) by ietfa.amsl.com (Postfix) with ESMTP id AAEFC1A02FB for ; Tue, 18 Mar 2014 13:33:55 -0700 (PDT)
Received: from [137.254.4.58] (port=46328 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQ0hk-0005sv-Kh for dime@ietf.org; Tue, 18 Mar 2014 13:33:46 -0700
Message-ID: <5328ADAA.40503@usdonovans.com>
Date: Tue, 18 Mar 2014 15:33:46 -0500
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: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------030003020708060108030304"
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/zPlKpVUyBhUXhibhH31VdY0Fx-M
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, 18 Mar 2014 20:34:00 -0000

This is a multi-part message in MIME format.
--------------030003020708060108030304
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

As Maria Cruz indicates, the tentative conclusion in the DIME working
group meeting in London was that this requirement be addressed in a
separate extension to the DOIC specification.

As a result, I propose that we close this issue indicating that no
changes will be made to the DOIC specification, with the statement that
it needs to be addressed in an extension.

Regards,

Steve

On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
>
> Dear Ulrich,
>
>  
>
> See comments below please.
>
> Anyway, since during IETF meeting it was commented that this could be
> considered as an extension, not sure how this should be managed from
> now on. I presume we should confirm that in this list.
>
>  
>
> Best regards
>
> /MCruz
>
>  
>
> *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
> *Sent:* jueves, 06 de marzo de 2014 10:12
> *To:* Maria Cruz Bartolome; dime@ietf.org 
> *Subject:* RE: [Dime] Issue#35 conclusion
>
>  
>
> Dear MCruz,
>
>  
>
> for my clarification:
>
> what you say about Host reports is also true for Realm-Routed-Request
> reports. Can you please confirm.
>
> [MCruz] I think this case is different. If we agree that realm reports
> are only generated by agents (as an aggregated report based on host
> reports and potentially another implementation dependent criteria),
> then the server itself does not require a traffic-to-realm reduction,
> on the contrary, the host only requests a traffic-to-host reduction.
> Agent may or not (I think this is up in the draft) to  forward back to
> the original client this host-report. Then, not sure if we really need
> something else here.
>
>  I don't know whether it is still relevant, but I would have
> thought that the agent that generates a realm-routed-request report,
> when taking the host reports received from servers into accout for the
> aggregation, may e.g. detect that all the severs request reduction of
> traffic from the same a specific client. Would it not be logical that
> the aggregated realm-routed-request report in this case also only
> requests reduction from that client (with the aggregated percentage)?
> 
>
> [MCruz] This could be something to be considered and could provide
> some added value, but it is up to interpretation whether this is
> required.
>
>  
>
> Proposal b) does not address the 3GPP requirement from TR 29.809
> clause 6.4.7.  please confirm.
>
> [MCruz] It does address the 3GPP requirement in general, but not for
> one specific case:  "There is one special case here, when the agent is
> acting on behalf of the client (i.e. for a non-supporting client or
> for an agent SFE with topology hiding)".
>
>  I'm not sure, see below
>
>  
>
> Also proposal b)  impacts the reporting node which must not send
> client specific OLRs (with separate sequence number streams for
> different clients)
>
> [MCruz] I do not think so. In the case I mentioned, when the agent is
> acting on behalf of the client, it is always the receiver of the
> answers (i.e. from a host perspective, the client is the agent
>
> This is not correct. The host (reporting node) does not know
> whether the reacting node is the client (identified by orig-host in
> the request) or an agent (acting on behalf of the client and possibly
> also on behalf of other clients); the reporting node receives a
> request that contains an OC-Supported-Features AVP; this indicates to
> the reporting node that there is a downstream node supporting DOIC.
> Let me give an example:
>
> Two non-supporting clients C1 and C2 send requests via the same
> supporting agent A to the server. Traffic from C1 increases, so S
> requests a 10% throttling from C1 (sequence number 1). As the agent A
> is acting on behalf of C1, A will do the throttling. As a not wanted
> but acceptable side effect A will also throttle traffic sent from C2
> to S. Now the situation improves and S only requests a 5% reduction
> from C1 (sequence number 2).  Again A will apply the 5% throttling
> also for traffic from C2, which again is not nice but acceptable. Now
>  Traffic from C2 increases (although throttled with 5%) and S request
> a 50% throttling from C2 (sequence number 1). 
>
> , and then there are not separate sequence number streams).
>
> [MCruz] I think your example is right, and it highlights something
> important I haven't realized. Since the server may send totally
> different reduction requests to different clients, as in your example,
> the key point is not even that they carry different sequence numbers,
> but that reduction to apply to "all" clients will oscillate a lot,
> depending on server requests towards one specific client. Then, a way
> to solve this is that the server knows whether or not an agent is
> acting on behalf of the final client. If so, reporting node should not
> request reductions per client (i.e. %reduction will be the same for
> any client).
>
>  
>
> Also, shouldn't b) read:
>
> We expect the agent to apply this host type / realm-routed-request
> type report to any *non-DOIC-supporting* client that is sending
> requests towards this host/realm.
>
> [MCruz] Yes, any non-DOIC-supporting client.
>
>  
>
> Also, you say:
>
> b) does not require any changes to the actual draft
>
>  
>
> I guess at least some clarification is required as some (Lionel,
> Nirav, but not Steve)  think it is "natural" and "implicit" that
> agents would do the per client behaviour as a default.
>
> [MCruz] Agreed, at least clarification is required.
>
>  
>
> An alternative proposal that addresses the complexity argument for
> agents but at the same time at least partly addresses the 3GPP
> requirement would be to make use of a feature flag: clients allways
> set the flag, agents do not set the flag, reporting nodes may send
> client specific OLRs when the flag in the request was set. This has no
> big impact to clients (only always set the feature flag), no impacts
> to agents, and allows (if so desired) reporting nodes to make use of
> the client specific throttling (at least in some cases).
>
> any comments?
>
> [MCruz] I agree this could be a way for the reporting node to know
> that an agent is not acting on behalf of a client
>
>  
>
> Best regards
>
> Ulrich
>
>  
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Maria
> Cruz Bartolome
> *Sent:* Thursday, March 06, 2014 9:00 AM
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
>  
>
>  
>
> Dear all,
>
>  
>
> This mail thread started proposing new OLR reports to request
> reduction for one specific client.
>
> However, the discussion clarified that as it is the draft today,
> *Host*-report is sent from a reporting node towards the client from
> where it receives the request. Then, reduction is requested per client
> in all cases already.
>
> There is one special case here, when the agent is acting on behalf of
> the client (i.e. for a non-supporting client or for an agent SFE with
> topology hiding). In this case, the reporting node sends host-report
> to agent. Here we have two options:
>
>  
>
> *a)     **We expect the agent to apply the host-report received in an
> answer to specifically the client that sent the corresponding request*
>
> This requires some extra complexity at agent side.
>
> But here we have one more option: allow the reporting node to choose
> whether it prefers to apply this host-report to "all-client" vs
> "one-client". That increases again the complexity (at reporting node,
> protocol-wise, and at agent).
>
>  
>
> *b)     **We expect the agent to apply this host-report to _any_
> client that is sending a request towards this agent*
>
> In my opinion, this is the best approach, it reduces complexity and
> increases robustness.
>
>  
>
> Therefore, I will be in favor of option b), which does not require any
> changes to the actual draft.
>
>  
>
> Let me know your opinions.
>
> Best regards
>
> /MCruz
>
>  
>
>  
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------030003020708060108030304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    All,

      

      As Maria Cruz indicates, the tentative conclusion in the DIME
      working group meeting in London was that this requirement be
      addressed in a separate extension to the DOIC specification.

      

      As a result, I propose that we close this issue indicating that no
      changes will be made to the DOIC specification, with the statement
      that it needs to be addressed in an extension.

      

      Regards,

      

      Steve

      

    
    
On 3/7/14 10:30 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Dear
            Ulrich,

        
 

        
See
          comments
          below
            please.

        
Anyway,
            since during IETF meeting it was commented that this could
            be considered as an extension, not sure how this should be
            managed from now on. I presume we should confirm that in
            this list.

        
 

        
Best
            regards

        
/MCruz

        
 

        

          

            
From:
                Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
                

                Sent: jueves, 06 de marzo de 2014 10:12

                To: Maria Cruz Bartolome; dime@ietf.org

                Subject: RE: [Dime] Issue#35 conclusion

          

        

        
 

        
Dear MCruz,

        
 

        
for
            my clarification:
            

        
what
            you say about Host reports is also true for
            Realm-Routed-Request reports. Can you please confirm.

        
[MCruz]
            I think this case is different. If we agree that realm
            reports are only generated by agents (as an aggregated
            report based on host reports and potentially another
            implementation dependent criteria), then the server itself
            does not require a traffic-to-realm reduction, on the
            contrary, the host only requests a traffic-to-host
            reduction. Agent may or not (I think this is up in the
            draft) to  forward back to the original client this
            host-report. Then, not sure if we really need something else
            here.

        
<Ulrich>
            I don’t know whether it is still relevant, but I would have
            thought that the agent that generates a realm-routed-request
            report, when taking the host reports received from servers
            into accout for the aggregation, may e.g. detect that all
            the severs request reduction of traffic from the same a
            specific client. Would it not be logical that the aggregated
            realm-routed-request report in this case also only requests
            reduction from that client (with the aggregated percentage)?
            </Ulrich>

        
[MCruz]
            This could be something to be considered and could provide
            some added value, but it is up to interpretation whether
            this is required.
            

        
 

        
Proposal
            b) does not address the 3GPP requirement from TR 29.809
            clause 6.4.7.  please confirm.

        
[MCruz]
            It does address the 3GPP requirement in general, but not for
            one specific case:  “There

            is one special case here, when the agent is acting on behalf
            of the client (i.e. for a non-supporting client or for an
            agent SFE with topology hiding)”.

        
<Ulrich>
            I’m not sure, see below</Ulrich>
            

        
 

        
Also
            proposal b)  impacts the reporting node which must not send
            client specific OLRs (with separate sequence number streams
            for different clients)

        
[MCruz]
            I do not think so. In the case I mentioned, when the agent
            is acting on behalf of the client, it is always the receiver
            of the answers (i.e. from a host perspective, the client is
            the agent

        
<Ulrich>This
            is not correct. The host (reporting node) does not know
            whether the reacting node is the client (identified by
            orig-host in the request) or an agent (acting on behalf of
            the client and possibly also on behalf of other clients);
            the reporting node receives a request that contains an
            OC-Supported-Features AVP; this indicates to the reporting
            node that there is a downstream node supporting DOIC. Let me
            give an example:

        
Two
            non-supporting clients C1 and C2 send requests via the same
            supporting agent A to the server. Traffic from C1 increases,
            so S requests a 10% throttling from C1 (sequence number 1).
            As the agent A is acting on behalf of C1, A will do the
            throttling. As a not wanted but acceptable side effect A
            will also throttle traffic sent from C2 to S. Now the
            situation improves and S only requests a 5% reduction from
            C1 (sequence number 2).  Again A will apply the 5%
            throttling also for traffic from C2, which again is not nice
            but acceptable. Now  Traffic from C2 increases (although
            throttled with 5%) and S request a 50% throttling from C2
            (sequence number 1). </Ulrich>
            

        
,
            and then there are not separate sequence number streams).

        
[MCruz]
            I think your example is right, and it highlights something
            important I haven’t realized. Since the server may send
            totally different reduction requests to different clients,
            as in your example, the key point is not even that they
            carry different sequence numbers, but that reduction to
            apply to “all” clients will oscillate a lot, depending on
            server requests towards one specific client. Then, a way to
            solve this is that the server knows whether or not an agent
            is acting on behalf of the final client. If so, reporting
            node should not request reductions per client (i.e.
            %reduction will be the same for any client).

        
 

        
Also,
            shouldn’t b) read:

        
We
            expect the agent to apply this host type /
            realm-routed-request type report to any
            non-DOIC-supporting client that is sending requests
            towards this host/realm.

        
[MCruz]
            Yes, any non-DOIC-supporting client.

        
 

        
Also,
            you say:

        
b)
            does not require any changes to the actual draft

        
 

        
I
            guess at least some clarification is required as some
            (Lionel, Nirav, but not Steve)  think it is “natural” and
            “implicit” that agents would do the per client behaviour as
            a default. 

        
[MCruz]
            Agreed, at least clarification is required.

        
 

        
An
            alternative proposal that addresses the complexity argument
            for agents but at the same time at least partly addresses
            the 3GPP requirement would be to make use of a feature flag:
            clients allways set the flag, agents do not set the flag,
            reporting nodes may send client specific OLRs when the flag
            in the request was set. This has no big impact to clients
            (only always set the feature flag), no impacts to agents,
            and allows (if so desired) reporting nodes to make use of
            the client specific throttling (at least in some cases).

        
<Ulrich>any
            comments?</Ulrich>

        
[MCruz]
            I agree this could be a way for the reporting node to know
            that an agent is not acting on behalf of a client

        
 

        
Best
            regards

        
Ulrich

        
 

        
 

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Maria Cruz Bartolome

                Sent: Thursday, March 06, 2014 9:00 AM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
 

        
 

        
Dear
            all,

        
 

        
This
            mail thread started proposing new OLR reports to request
            reduction for one specific client.
            

        
However,
            the discussion clarified that as it is the draft today,
            Host-report is sent from a reporting node towards the
            client from where it receives the request. Then, reduction
            is requested per client in all cases already.
            

        
There
            is one special case here, when the agent is acting on behalf
            of the client (i.e. for a non-supporting client or for an
            agent SFE with topology hiding). In this case, the reporting
            node sends host-report to agent. Here we have two options:

        
 

        
a)    
                We
              expect the agent to apply the host-report received in an
              answer to specifically the client that sent the
              corresponding request

        
This
            requires some extra complexity at agent side.

        
But
            here we have one more option: allow the reporting node to
            choose whether it prefers to apply this host-report to
            “all-client” vs “one-client”. That increases again the
            complexity (at reporting node, protocol-wise, and at agent).

        
 

        
b)    
                We
              expect the agent to apply this host-report to
              any client that is sending a request towards this
              agent

        
In
            my opinion, this is the best approach, it reduces complexity
            and increases robustness.
            

        
 

        
Therefore,
            I will be in favor of option b), which does not require any
            changes to the actual draft.

        
 

        
Let
            me know your opinions.

        
Best
            regards

        
/MCruz

        
 

        
 

      

      

      

      

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


    

    

  


--------------030003020708060108030304--


From nobody Wed Mar 19 01:36:18 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 7AF711A04B4 for ; Wed, 19 Mar 2014 01:36:14 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 S0WdeK0-JblF for ; Wed, 19 Mar 2014 01:36:08 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 837441A0344 for ; Wed, 19 Mar 2014 01:36:07 -0700 (PDT)
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 s2J8Zvmw022735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Mar 2014 09:35:57 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2J8Ztpk006361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Mar 2014 09:35:56 +0100
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 19 Mar 2014 09:35:55 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.73]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Wed, 19 Mar 2014 09:35:55 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/Xn9wvmyrSf2I+rd4YT2PBgAAVchQAAoVTgAAJYd7MAASGUMAAjGvvAAAGqE1AA==
Date: Wed, 19 Mar 2014 08:35:54 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151C8204@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se> <5328ADAA.40503@usdonovans.com>
In-Reply-To: <5328ADAA.40503@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.103]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151C8204DEMUMBX014nsnin_"
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: 42680
X-purgate-ID: 151667::1395218157-00003319-9F348B8F/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eRihwpkEpls1aw8npC1DibK3zlo
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: Wed, 19 Mar 2014 08:36:14 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C8204DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve, all,

one proposal to solve the issue was to let clients indicate in OC-Supported=
-Features that they support client specific throttling (while agents taking=
 the role of the reacting node on behalf of multiple clients would not indi=
cate such support).

This could certainly be done by a separate extension to the DOIC specificat=
ion, but, given that clients allways support  client specific throttling, c=
lients not aware of the extension would not indicate so in OC-Supported Fea=
tures which is realy a pitty.

Therefore I would like to ask people considering taking this small enhancem=
ent on board:

Clients allways indicate support of client specific throttling;
Agents (taking the role of  a reacting node on behalf of multiple clients) =
never indicate support of client specific throttling;
Reporting nodes may make use of this indication and request client specific=
 throttling only when the reacting node indicated support.

Best regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, March 18, 2014 9:34 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

All,

As Maria Cruz indicates, the tentative conclusion in the DIME working group=
 meeting in London was that this requirement be addressed in a separate ext=
ension to the DOIC specification.

As a result, I propose that we close this issue indicating that no changes =
will be made to the DOIC specification, with the statement that it needs to=
 be addressed in an extension.

Regards,

Steve
On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
Dear Ulrich,

See comments below please.
Anyway, since during IETF meeting it was commented that this could be consi=
dered as an extension, not sure how this should be managed from now on. I p=
resume we should confirm that in this list.

Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request repor=
ts. Can you please confirm.
[MCruz] I think this case is different. If we agree that realm reports are =
only generated by agents (as an aggregated report based on host reports and=
 potentially another implementation dependent criteria), then the server it=
self does not require a traffic-to-realm reduction, on the contrary, the ho=
st only requests a traffic-to-host reduction. Agent may or not (I think thi=
s is up in the draft) to  forward back to the original client this host-rep=
ort. Then, not sure if we really need something else here.
 I don't know whether it is still relevant, but I would have though=
t that the agent that generates a realm-routed-request report, when taking =
the host reports received from servers into accout for the aggregation, may=
 e.g. detect that all the severs request reduction of traffic from the same=
 a specific client. Would it not be logical that the aggregated realm-route=
d-request report in this case also only requests reduction from that client=
 (with the aggregated percentage)? 
[MCruz] This could be something to be considered and could provide some add=
ed value, but it is up to interpretation whether this is required.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4=
.7.  please confirm.
[MCruz] It does address the 3GPP requirement in general, but not for one sp=
ecific case:  "There is one special case here, when the agent is acting on =
behalf of the client (i.e. for a non-supporting client or for an agent SFE =
with topology hiding)".
 I'm not sure, see below

Also proposal b)  impacts the reporting node which must not send client spe=
cific OLRs (with separate sequence number streams for different clients)
[MCruz] I do not think so. In the case I mentioned, when the agent is actin=
g on behalf of the client, it is always the receiver of the answers (i.e. f=
rom a host perspective, the client is the agent
This is not correct. The host (reporting node) does not know whethe=
r the reacting node is the client (identified by orig-host in the request) =
or an agent (acting on behalf of the client and possibly also on behalf of =
other clients); the reporting node receives a request that contains an OC-S=
upported-Features AVP; this indicates to the reporting node that there is a=
 downstream node supporting DOIC. Let me give an example:
Two non-supporting clients C1 and C2 send requests via the same supporting =
agent A to the server. Traffic from C1 increases, so S requests a 10% throt=
tling from C1 (sequence number 1). As the agent A is acting on behalf of C1=
, A will do the throttling. As a not wanted but acceptable side effect A wi=
ll also throttle traffic sent from C2 to S. Now the situation improves and =
S only requests a 5% reduction from C1 (sequence number 2).  Again A will a=
pply the 5% throttling also for traffic from C2, which again is not nice bu=
t acceptable. Now  Traffic from C2 increases (although throttled with 5%) a=
nd S request a 50% throttling from C2 (sequence number 1). 
, and then there are not separate sequence number streams).
[MCruz] I think your example is right, and it highlights something importan=
t I haven't realized. Since the server may send totally different reduction=
 requests to different clients, as in your example, the key point is not ev=
en that they carry different sequence numbers, but that reduction to apply =
to "all" clients will oscillate a lot, depending on server requests towards=
 one specific client. Then, a way to solve this is that the server knows wh=
ether or not an agent is acting on behalf of the final client. If so, repor=
ting node should not request reductions per client (i.e. %reduction will be=
 the same for any client).

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type rep=
ort to any non-DOIC-supporting client that is sending requests towards this=
 host/realm.
[MCruz] Yes, any non-DOIC-supporting client.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but=
 not Steve)  think it is "natural" and "implicit" that agents would do the =
per client behaviour as a default.
[MCruz] Agreed, at least clarification is required.

An alternative proposal that addresses the complexity argument for agents b=
ut at the same time at least partly addresses the 3GPP requirement would be=
 to make use of a feature flag: clients allways set the flag, agents do not=
 set the flag, reporting nodes may send client specific OLRs when the flag =
in the request was set. This has no big impact to clients (only always set =
the feature flag), no impacts to agents, and allows (if so desired) reporti=
ng nodes to make use of the client specific throttling (at least in some ca=
ses).
any comments?
[MCruz] I agree this could be a way for the reporting node to know that an =
agent is not acting on behalf of a client

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)      We expect the agent to apply the host-report received in an answer =
to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)      We expect the agent to apply this host-report to any client that is=
 sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz






_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C8204DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve, all,


 <=
/p>

one propos=
al to solve the issue was to let clients indicate in OC-Supported-Features =
that they support client specific throttling (while agents
 taking the role of the reacting node on behalf of multiple clients would n=
ot indicate such support).


 =
;


This could=
 certainly be done by a separate extension to the DOIC specification, but, =
given that clients allways support  client specific throttling,
 clients not aware of the extension would not indicate so in OC-Supported F=
eatures which is realy a pitty.


 =
;


Therefore =
I would like to ask people considering taking this small enhancement on boa=
rd:


 =
;


Clients al=
lways indicate support of client specific throttling;


Agents (ta=
king the role of  a reacting node on behalf of multiple clients) never=
 indicate support of client specific throttling;


Reporting =
nodes may make use of this indication and request client specific throttlin=
g only when the reacting node indicated support.


 =
;


Best regar=
ds


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, March 18, 2014 9:34 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


All,



As Maria Cruz indicates, the tentative conclusion in the DIME working group=
 meeting in London was that this requirement be addressed in a separate ext=
ension to the DOIC specification.



As a result, I propose that we close this issue indicating that no changes =
will be made to the DOIC specification, with the statement that it needs to=
 be addressed in an extension.



Regards,



Steve




On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:=







Dear Ulrich,<=
/o:p>


 <=
/p>

See comments below please=
.


Anyway, since during IETF=
 meeting it was commented that this could be considered as an extension, no=
t sure how this should be managed from now on. I presume
 we should confirm that in this list.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: jueves, 06 de marzo de 2014 10:12

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: RE: [Dime] Issue#35 conclusion






 


Dear MCruz,


 <=
/p>

for my clarification:



what you say about Host r=
eports is also true for Realm-Routed-Request reports. Can you please confir=
m.


[MCruz] I think this case=
 is different. If we agree that realm reports are only generated by agents =
(as an aggregated report based on host reports and potentially
 another implementation dependent criteria), then the server itself does no=
t require a traffic-to-realm reduction, on the contrary, the host only requ=
ests a traffic-to-host reduction. Agent may or not (I think this is up in t=
he draft) to  forward back to the
 original client this host-report. Then, not sure if we really need somethi=
ng else here.


<Ulrich> I don’t =
know whether it is still relevant, but I would have thought that the agent =
that generates a realm-routed-request report, when taking the host reports
 received from servers into accout for the aggregation, may e.g. detect tha=
t all the severs request reduction of traffic from the same a specific clie=
nt. Would it not be logical that the aggregated realm-routed-request report=
 in this case also only requests
 reduction from that client (with the aggregated percentage)? </Ulrich&g=
t;


[MCruz] This could be =
something to be considered and could provide some added value, but it is up=
 to interpretation whether this is required.



 <=
/p>

Proposal b) does not addr=
ess the 3GPP requirement from TR 29.809 clause 6.4.7.  please confirm.=



[MCruz] It does address t=
he 3GPP requirement in general, but not for one specific case:  “=
;There
 is one special case here, when the agent is acting on behalf of the client=
 (i.e. for a non-supporting client or for an agent SFE with topology hiding=
)”.


<Ulrich> I’m not =
sure, see below</Ulrich>



 <=
/p>

Also proposal b)  im=
pacts the reporting node which must not send client specific OLRs (with sep=
arate sequence number streams for different clients)


[MCruz] I do not think so=
. In the case I mentioned, when the agent is acting on behalf of the client=
, it is always the receiver of the answers (i.e. from a
 host perspective, the client is the agent


<Ulrich>This is not cor=
rect. The host (reporting node) does not know whether the reacting node is =
the client (identified by orig-host in the request) or an agent
 (acting on behalf of the client and possibly also on behalf of other clien=
ts); the reporting node receives a request that contains an OC-Supported-Fe=
atures AVP; this indicates to the reporting node that there is a downstream=
 node supporting DOIC. Let me give
 an example:


Two non-supporting clients C1=
 and C2 send requests via the same supporting agent A to the server. Traffi=
c from C1 increases, so S requests a 10% throttling from
 C1 (sequence number 1). As the agent A is acting on behalf of C1, A will d=
o the throttling. As a not wanted but acceptable side effect A will also th=
rottle traffic sent from C2 to S. Now the situation improves and S only req=
uests a 5% reduction from C1 (sequence
 number 2).  Again A will apply the 5% throttling also for traffic fro=
m C2, which again is not nice but acceptable. Now  Traffic from C2 inc=
reases (although throttled with 5%) and S request a 50% throttling from C2 =
(sequence number 1). </Ulrich>



, and then there are not =
separate sequence number streams).


[MCruz] I think your e=
xample is right, and it highlights something important I haven’t real=
ized. Since the server may send totally different reduction requests
 to different clients, as in your example, the key point is not even that t=
hey carry different sequence numbers, but that reduction to apply to “=
;all” clients will oscillate a lot, depending on server requests towa=
rds one specific client. Then, a way to solve
 this is that the server knows whether or not an agent is acting on behalf =
of the final client. If so, reporting node should not request reductions pe=
r client (i.e. %reduction will be the same for any client).


 <=
/p>

Also, shouldn’t b) =
read:


We expect the agent to ap=
ply this host type / realm-routed-request type report to any
non-DOIC-supporting client that is sending requests towards this hos=
t/realm.


[MCruz] Yes, any non-DOIC=
-supporting client.


 <=
/p>

Also, you say:


b) does not require any c=
hanges to the actual draft


 <=
/p>

I guess at least some cla=
rification is required as some (Lionel, Nirav, but not Steve)  think i=
t is “natural” and “implicit” that agents would do =
the per client
 behaviour as a default. 


[MCruz] Agreed, at least =
clarification is required.


 <=
/p>

An alternative proposal t=
hat addresses the complexity argument for agents but at the same time at le=
ast partly addresses the 3GPP requirement would be to make
 use of a feature flag: clients allways set the flag, agents do not set the=
 flag, reporting nodes may send client specific OLRs when the flag in the r=
equest was set. This has no big impact to clients (only always set the feat=
ure flag), no impacts to agents,
 and allows (if so desired) reporting nodes to make use of the client speci=
fic throttling (at least in some cases).


<Ulrich>any comments?&l=
t;/Ulrich>


[MCruz] I agree this c=
ould be a way for the reporting node to know that an agent is not acting on=
 behalf of a client


 <=
/p>

Best regards<=
/o:p>


Ulrich<=
/p>

 <=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, March 06, 2014 9:00 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


 <=
/p>

 


Dear all,


 <=
/p>

This mail thread started =
proposing new OLR reports to request reduction for one specific client.



However, the discussion c=
larified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is one special case=
 here, when the agent is acting on behalf of the client (i.e. for a non-sup=
porting client or for an agent SFE with topology hiding).
 In this case, the reporting node sends host-report to agent. Here we have =
two options:


 <=
/p>

a)     
We expect the agent t=
o apply the host-report received in an answer to specifically the client th=
at sent the corresponding request


This requires some=
 extra complexity at agent side.


But here we have o=
ne more option: allow the reporting node to choose whether it prefers to ap=
ply this host-report to “all-client” vs “one-client”=
;. That
 increases again the complexity (at reporting node, protocol-wise, and at a=
gent).


 =



b)     
We expect the agent t=
o apply this host-report to
any client that is sending a request towards this agent


In my opinion, thi=
s is the best approach, it reduces complexity and increases robustness.



 <=
/p>

Therefore, I will be in f=
avor of option b), which does not require any changes to the actual draft.<=
/span>


 <=
/p>

Let me know your opinions=
.


Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 











_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C8204DEMUMBX014nsnin_--


From nobody Wed Mar 19 10:53: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 17C551A07B9 for ; Wed, 19 Mar 2014 10:52:59 -0700 (PDT)
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 sWbProSSlH9w for ; Wed, 19 Mar 2014 10:52:54 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF911A0729 for ; Wed, 19 Mar 2014 10:52:53 -0700 (PDT)
Received: from [137.254.4.53] (port=8697 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQKfO-0002Mf-4D; Wed, 19 Mar 2014 10:52:42 -0700
Message-ID: <5329D966.5000800@usdonovans.com>
Date: Wed, 19 Mar 2014 12:52:38 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se> <5328ADAA.40503@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C8204@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151C8204@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090607090102000800030302"
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/CQEZtbk47q3vP77oDuezz4p6czE
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: Wed, 19 Mar 2014 17:52:59 -0000

This is a multi-part message in MIME format.
--------------090607090102000800030302
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

I'm concerned there are issues with agents, and potentially reporting
nodes, that would lurk behind this proposal.  I think it is best to
leave this to a separate enhancement to be sure that those issues are
properly vetted.

Regards,

Steve

On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve, all,
>
>  
>
> one proposal to solve the issue was to let clients indicate in
> OC-Supported-Features that they support client specific throttling
> (while agents taking the role of the reacting node on behalf of
> multiple clients would not indicate such support).
>
>  
>
> This could certainly be done by a separate extension to the DOIC
> specification, but, given that clients allways support  client
> specific throttling, clients not aware of the extension would not
> indicate so in OC-Supported Features which is realy a pitty.
>
>  
>
> Therefore I would like to ask people considering taking this small
> enhancement on board:
>
>  
>
> Clients allways indicate support of client specific throttling;
>
> Agents (taking the role of  a reacting node on behalf of multiple
> clients) never indicate support of client specific throttling;
>
> Reporting nodes may make use of this indication and request client
> specific throttling only when the reacting node indicated support.
>
>  
>
> Best regards
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, March 18, 2014 9:34 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> All,
>
> As Maria Cruz indicates, the tentative conclusion in the DIME working
> group meeting in London was that this requirement be addressed in a
> separate extension to the DOIC specification.
>
> As a result, I propose that we close this issue indicating that no
> changes will be made to the DOIC specification, with the statement
> that it needs to be addressed in an extension.
>
> Regards,
>
> Steve
>
> On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
>
>     Dear Ulrich,
>
>      
>
>     See comments below please.
>
>     Anyway, since during IETF meeting it was commented that this could
>     be considered as an extension, not sure how this should be managed
>     from now on. I presume we should confirm that in this list.
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
>     *Sent:* jueves, 06 de marzo de 2014 10:12
>     *To:* Maria Cruz Bartolome; dime@ietf.org 
>     *Subject:* RE: [Dime] Issue#35 conclusion
>
>      
>
>     Dear MCruz,
>
>      
>
>     for my clarification:
>
>     what you say about Host reports is also true for
>     Realm-Routed-Request reports. Can you please confirm.
>
>     [MCruz] I think this case is different. If we agree that realm
>     reports are only generated by agents (as an aggregated report
>     based on host reports and potentially another implementation
>     dependent criteria), then the server itself does not require a
>     traffic-to-realm reduction, on the contrary, the host only
>     requests a traffic-to-host reduction. Agent may or not (I think
>     this is up in the draft) to  forward back to the original client
>     this host-report. Then, not sure if we really need something else
>     here.
>
>      I don't know whether it is still relevant, but I would
>     have thought that the agent that generates a realm-routed-request
>     report, when taking the host reports received from servers into
>     accout for the aggregation, may e.g. detect that all the severs
>     request reduction of traffic from the same a specific client.
>     Would it not be logical that the aggregated realm-routed-request
>     report in this case also only requests reduction from that client
>     (with the aggregated percentage)? 
>
>     [MCruz] This could be something to be considered and could provide
>     some added value, but it is up to interpretation whether this is
>     required.
>
>      
>
>     Proposal b) does not address the 3GPP requirement from TR 29.809
>     clause 6.4.7.  please confirm.
>
>     [MCruz] It does address the 3GPP requirement in general, but not
>     for one specific case:  "There is one special case here, when the
>     agent is acting on behalf of the client (i.e. for a non-supporting
>     client or for an agent SFE with topology hiding)".
>
>      I'm not sure, see below
>
>      
>
>     Also proposal b)  impacts the reporting node which must not send
>     client specific OLRs (with separate sequence number streams for
>     different clients)
>
>     [MCruz] I do not think so. In the case I mentioned, when the agent
>     is acting on behalf of the client, it is always the receiver of
>     the answers (i.e. from a host perspective, the client is the agent
>
>     This is not correct. The host (reporting node) does not
>     know whether the reacting node is the client (identified by
>     orig-host in the request) or an agent (acting on behalf of the
>     client and possibly also on behalf of other clients); the
>     reporting node receives a request that contains an
>     OC-Supported-Features AVP; this indicates to the reporting node
>     that there is a downstream node supporting DOIC. Let me give an
>     example:
>
>     Two non-supporting clients C1 and C2 send requests via the same
>     supporting agent A to the server. Traffic from C1 increases, so S
>     requests a 10% throttling from C1 (sequence number 1). As the
>     agent A is acting on behalf of C1, A will do the throttling. As a
>     not wanted but acceptable side effect A will also throttle traffic
>     sent from C2 to S. Now the situation improves and S only requests
>     a 5% reduction from C1 (sequence number 2).  Again A will apply
>     the 5% throttling also for traffic from C2, which again is not
>     nice but acceptable. Now  Traffic from C2 increases (although
>     throttled with 5%) and S request a 50% throttling from C2
>     (sequence number 1). 
>
>     , and then there are not separate sequence number streams).
>
>     [MCruz] I think your example is right, and it highlights something
>     important I haven't realized. Since the server may send totally
>     different reduction requests to different clients, as in your
>     example, the key point is not even that they carry different
>     sequence numbers, but that reduction to apply to "all" clients
>     will oscillate a lot, depending on server requests towards one
>     specific client. Then, a way to solve this is that the server
>     knows whether or not an agent is acting on behalf of the final
>     client. If so, reporting node should not request reductions per
>     client (i.e. %reduction will be the same for any client).
>
>      
>
>     Also, shouldn't b) read:
>
>     We expect the agent to apply this host type / realm-routed-request
>     type report to any *non-DOIC-supporting* client that is sending
>     requests towards this host/realm.
>
>     [MCruz] Yes, any non-DOIC-supporting client.
>
>      
>
>     Also, you say:
>
>     b) does not require any changes to the actual draft
>
>      
>
>     I guess at least some clarification is required as some (Lionel,
>     Nirav, but not Steve)  think it is "natural" and "implicit" that
>     agents would do the per client behaviour as a default.
>
>     [MCruz] Agreed, at least clarification is required.
>
>      
>
>     An alternative proposal that addresses the complexity argument for
>     agents but at the same time at least partly addresses the 3GPP
>     requirement would be to make use of a feature flag: clients
>     allways set the flag, agents do not set the flag, reporting nodes
>     may send client specific OLRs when the flag in the request was
>     set. This has no big impact to clients (only always set the
>     feature flag), no impacts to agents, and allows (if so desired)
>     reporting nodes to make use of the client specific throttling (at
>     least in some cases).
>
>     any comments?
>
>     [MCruz] I agree this could be a way for the reporting node to know
>     that an agent is not acting on behalf of a client
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>      
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Maria Cruz Bartolome
>     *Sent:* Thursday, March 06, 2014 9:00 AM
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>      
>
>      
>
>     Dear all,
>
>      
>
>     This mail thread started proposing new OLR reports to request
>     reduction for one specific client.
>
>     However, the discussion clarified that as it is the draft today,
>     *Host*-report is sent from a reporting node towards the client
>     from where it receives the request. Then, reduction is requested
>     per client in all cases already.
>
>     There is one special case here, when the agent is acting on behalf
>     of the client (i.e. for a non-supporting client or for an agent
>     SFE with topology hiding). In this case, the reporting node sends
>     host-report to agent. Here we have two options:
>
>      
>
>     a)      *We expect the agent to apply the host-report received in
>     an answer to specifically the client that sent the corresponding
>     request*
>
>     This requires some extra complexity at agent side.
>
>     But here we have one more option: allow the reporting node to
>     choose whether it prefers to apply this host-report to
>     "all-client" vs "one-client". That increases again the complexity
>     (at reporting node, protocol-wise, and at agent).
>
>      
>
>     b)      *We expect the agent to apply this host-report to _any_
>     client that is sending a request towards this agent*
>
>     In my opinion, this is the best approach, it reduces complexity
>     and increases robustness.
>
>      
>
>     Therefore, I will be in favor of option b), which does not require
>     any changes to the actual draft.
>
>      
>
>     Let me know your opinions.
>
>     Best regards
>
>     /MCruz
>
>      
>
>      
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>  
>


--------------090607090102000800030302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I'm concerned there are issues with agents, and potentially
      reporting nodes, that would lurk behind this proposal.  I think it
      is best to leave this to a separate enhancement to be sure that
      those issues are properly vetted.

      

      Regards,

      

      Steve

      

    
    
On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,
            all,

        
 

        
one proposal to solve the issue was to let
            clients indicate in OC-Supported-Features that they support
            client specific throttling (while agents taking the role of
            the reacting node on behalf of multiple clients would not
            indicate such support).

        
 

        
This could certainly be done by a separate
            extension to the DOIC specification, but, given that clients
            allways support  client specific throttling, clients not
            aware of the extension would not indicate so in OC-Supported
            Features which is realy a pitty.

        
 

        
Therefore I would like to ask people
            considering taking this small enhancement on board:

        
 

        
Clients allways indicate support of client
            specific throttling;

        
Agents (taking the role of  a reacting node on
            behalf of multiple clients) never indicate support of client
            specific throttling;

        
Reporting nodes may make use of this indication
            and request client specific throttling only when the
            reacting node indicated support.

        
 

        
Best regards

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Tuesday, March 18, 2014 9:34 PM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
All,

          

          As Maria Cruz indicates, the tentative conclusion in the DIME
          working group meeting in London was that this requirement be
          addressed in a separate extension to the DOIC specification.

          

          As a result, I propose that we close this issue indicating
          that no changes will be made to the DOIC specification, with
          the statement that it needs to be addressed in an extension.

          

          Regards,

          

          Steve

        

          
On 3/7/14 10:30 AM, Maria Cruz Bartolome
            wrote:

        

        

          
Dear
              Ulrich,

          
 

          
See
              comments below please.

          
Anyway,
              since during IETF meeting it was commented that this could
              be considered as an extension, not sure how this should be
              managed from now on. I presume we should confirm that in
              this list.

          
 

          
Best
              regards

          
/MCruz

          
 

          

            

              
From:
                  Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
                  

                  Sent: jueves, 06 de marzo de 2014 10:12

                  To: Maria Cruz Bartolome; dime@ietf.org

                  Subject: RE: [Dime] Issue#35 conclusion

            

          

          
 

          
Dear
              MCruz,

          
 

          
for
              my clarification:
            

          
what
              you say about Host reports is also true for
              Realm-Routed-Request reports. Can you please confirm.

          
[MCruz]
              I think this case is different. If we agree that realm
              reports are only generated by agents (as an aggregated
              report based on host reports and potentially another
              implementation dependent criteria), then the server itself
              does not require a traffic-to-realm reduction, on the
              contrary, the host only requests a traffic-to-host
              reduction. Agent may or not (I think this is up in the
              draft) to  forward back to the original client this
              host-report. Then, not sure if we really need something
              else here.

          
<Ulrich>
              I don’t know whether it is still relevant, but I would
              have thought that the agent that generates a
              realm-routed-request report, when taking the host reports
              received from servers into accout for the aggregation, may
              e.g. detect that all the severs request reduction of
              traffic from the same a specific client. Would it not be
              logical that the aggregated realm-routed-request report in
              this case also only requests reduction from that client
              (with the aggregated percentage)? </Ulrich>

          
[MCruz]
              This could be something to be considered and could provide
              some added value, but it is up to interpretation whether
              this is required.
            

          
 

          
Proposal
              b) does not address the 3GPP requirement from TR 29.809
              clause 6.4.7.  please confirm.

          
[MCruz]
              It does address the 3GPP requirement in general, but not
              for one specific case:  “There

              is one special case here, when the agent is acting on
              behalf of the client (i.e. for a non-supporting client or
              for an agent SFE with topology hiding)”.

          
<Ulrich>
              I’m not sure, see below</Ulrich>
            

          
 

          
Also
              proposal b)  impacts the reporting node which must not
              send client specific OLRs (with separate sequence number
              streams for different clients)

          
[MCruz]
              I do not think so. In the case I mentioned, when the agent
              is acting on behalf of the client, it is always the
              receiver of the answers (i.e. from a host perspective, the
              client is the agent

          
<Ulrich>This
              is not correct. The host (reporting node) does not know
              whether the reacting node is the client (identified by
              orig-host in the request) or an agent (acting on behalf of
              the client and possibly also on behalf of other clients);
              the reporting node receives a request that contains an
              OC-Supported-Features AVP; this indicates to the reporting
              node that there is a downstream node supporting DOIC. Let
              me give an example:

          
Two
              non-supporting clients C1 and C2 send requests via the
              same supporting agent A to the server. Traffic from C1
              increases, so S requests a 10% throttling from C1
              (sequence number 1). As the agent A is acting on behalf of
              C1, A will do the throttling. As a not wanted but
              acceptable side effect A will also throttle traffic sent
              from C2 to S. Now the situation improves and S only
              requests a 5% reduction from C1 (sequence number 2).
               Again A will apply the 5% throttling also for traffic
              from C2, which again is not nice but acceptable. Now
               Traffic from C2 increases (although throttled with 5%)
              and S request a 50% throttling from C2 (sequence number
              1). </Ulrich>
            

          
,
              and then there are not separate sequence number streams).

          
[MCruz]
              I think your example is right, and it highlights something
              important I haven’t realized. Since the server may send
              totally different reduction requests to different clients,
              as in your example, the key point is not even that they
              carry different sequence numbers, but that reduction to
              apply to “all” clients will oscillate a lot, depending on
              server requests towards one specific client. Then, a way
              to solve this is that the server knows whether or not an
              agent is acting on behalf of the final client. If so,
              reporting node should not request reductions per client
              (i.e. %reduction will be the same for any client).

          
 

          
Also,
              shouldn’t b) read:

          
We
              expect the agent to apply this host type /
              realm-routed-request type report to any
              non-DOIC-supporting client that is sending requests
              towards this host/realm.

          
[MCruz]
              Yes, any non-DOIC-supporting client.

          
 

          
Also,
              you say:

          
b)
              does not require any changes to the actual draft

          
 

          
I
              guess at least some clarification is required as some
              (Lionel, Nirav, but not Steve)  think it is “natural” and
              “implicit” that agents would do the per client behaviour
              as a default. 

          
[MCruz]
              Agreed, at least clarification is required.

          
 

          
An
              alternative proposal that addresses the complexity
              argument for agents but at the same time at least partly
              addresses the 3GPP requirement would be to make use of a
              feature flag: clients allways set the flag, agents do not
              set the flag, reporting nodes may send client specific
              OLRs when the flag in the request was set. This has no big
              impact to clients (only always set the feature flag), no
              impacts to agents, and allows (if so desired) reporting
              nodes to make use of the client specific throttling (at
              least in some cases).

          
<Ulrich>any
              comments?</Ulrich>

          
[MCruz]
              I agree this could be a way for the reporting node to know
              that an agent is not acting on behalf of a client

          
 

          
Best
              regards

          
Ulrich

          
 

          
 

          
 

          

            

              
From:
                  DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Maria Cruz Bartolome

                  Sent: Thursday, March 06, 2014 9:00 AM

                  To: dime@ietf.org

                  Subject: Re: [Dime] Issue#35 conclusion

            

          

          
 

          
 

          
 

          
Dear
              all,

          
 

          
This
              mail thread started proposing new OLR reports to request
              reduction for one specific client.
            

          
However,
              the discussion clarified that as it is the draft today,
              Host-report is sent from a reporting node towards
              the client from where it receives the request. Then,
              reduction is requested per client in all cases already.
            

          
There
              is one special case here, when the agent is acting on
              behalf of the client (i.e. for a non-supporting client or
              for an agent SFE with topology hiding). In this case, the
              reporting node sends host-report to agent. Here we have
              two options:

          
 

          
a)     
              We
                expect the agent to apply the host-report received in an
                answer to specifically the client that sent the
                corresponding request

          
This
              requires some extra complexity at agent side.

          
But
              here we have one more option: allow the reporting node to
              choose whether it prefers to apply this host-report to
              “all-client” vs “one-client”. That increases again the
              complexity (at reporting node, protocol-wise, and at
              agent).

          
 

          
b)     
              We
                expect the agent to apply this host-report to
                any client that is sending a request towards this
                agent

          
In
              my opinion, this is the best approach, it reduces
              complexity and increases robustness.
            

          
 

          
Therefore,
              I will be in favor of option b), which does not require
              any changes to the actual draft.

          
 

          
Let
              me know your opinions.

          
Best
              regards

          
/MCruz

          
 

          
 

          


            

            

            

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

        

        
 

      

    

    

  


--------------090607090102000800030302--


From nobody Wed Mar 19 10:56:55 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 B07A21A06EA for ; Wed, 19 Mar 2014 10:56:53 -0700 (PDT)
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 HJD9CNlcLbVs for ; Wed, 19 Mar 2014 10:56:52 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id EEF5E1A042C for ; Wed, 19 Mar 2014 10:56:51 -0700 (PDT)
Received: from localhost ([127.0.0.1]:34602 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WQKjK-0006gZ-EI; Wed, 19 Mar 2014 18:56:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Wed, 19 Mar 2014 17:56:42 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/36#comment:1
Message-ID: <090.b1d843a82ba2ba5c98226c5ac988b1c2@trac.tools.ietf.org>
References: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org>
X-Trac-Ticket-ID: 36
In-Reply-To: <075.376f1b94eeb48f20f90d9724b0e70c0e@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: srdonovan@usdonovans.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/dshn3xzSNQEwYzMnx19_uPAXFSE
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #36 (draft-docdt-dime-ovli): OC-Validity-Duration AVP
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: Wed, 19 Mar 2014 17:56:53 -0000

#36: OC-Validity-Duration AVP

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Closed based on agreement to make the following changes (copied from
 Lionel's email):

 4.3. OC-OLR AVP



 [skip]



   The Sequence-Number AVP indicates the "freshness" of the OC-OLR AVP.

   It is possible to replay the same OC-OLR AVP multiple times between

   the overload control endpoints, however, when the OC-OLR AVP content

   changes or sending endpoint otherwise wants the receiving endpoint to

   update its overload control information, then the OC-Sequence-Number

   AVP MUST contain a new greater value than the previously received.

   The receiver SHOULD discard an OC-OLR AVP with a sequence number that

   is less than previously received one.



 [New]



   The OC-Validity-Duration AVP indicates the validity time of the overload

   report associated with a specific sequence number, measured after
 reception

   of the OC-OLR AVP. The validity time MUST NOT be updated after reception

   of subsequent OC-OLR AVPs with the same sequence number. The default
 value

   for the OC-Validity-Duration AVP value is 5 (i.e., 5 seconds).  When the

   OC-Validity-Duration AVP is not present in the OC-OLR AVP, the default
 value

   applies.



 [Skip]



 4.5. OC-Validity-Duration AVP



 OLD:

   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32

   and describes the number of seconds the "new and fresh" OC-OLR AVP

   and its content is valid since the reception of the new OC-OLR AVP.

   The default value for the OC-Validity-Duration AVP value is 5 (i.e.,

   5 seconds).  When the OC-Validity-Duration AVP is not present in the

   OC-OLR AVP, the default value applies.  Validity duration values 0

   (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.

   Invalid validity duration values are treated as if the OC-Validity-

   Duration AVP were not present.





 NEW:

   The OC-Validity-Duration AVP (AVP code TBD4) is type of Unsigned32

   and indicates in seconds the validity time of the overload report.

   The number of seconds is measured after reception of the first

   OC-OLR AVP with a given value of OC-Sequence-Number AVP.

   The default value for the OC-Validity-Duration AVP is 5 (i.e.,

   5 seconds).  When the OC-Validity-Duration AVP is not present in the

   OC-OLR AVP, the default value applies. OC-Validity-Duration AVP values 0

   (i.e., 0 second) and above 86400 (i.e., 24 hours) MUST NOT be used.

   When invalid values are used, the default value for the OC-Validity-
 Duration

   AVP applies.

-- 
-----------------------------------------------+---------------------------
 Reporter:  maria.cruz.bartolome@ericsson.com  |       Owner:  MCruz
     Type:  enhancement                        |  Bartolomé
 Priority:  major                              |      Status:  closed
Component:  draft-docdt-dime-ovli              |   Milestone:
 Severity:  Active WG Document                 |     Version:
 Keywords:                                     |  Resolution:  fixed
-----------------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Thu Mar 20 00:45:39 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 016561A08B2 for ; Thu, 20 Mar 2014 00:45:35 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 8l0isbvzMIf0 for ; Thu, 20 Mar 2014 00:45:26 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B954C1A0655 for ; Thu, 20 Mar 2014 00:45:25 -0700 (PDT)
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 s2K7jFT5030291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 20 Mar 2014 08:45:15 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2K7jER6022032 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Mar 2014 08:45:14 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 20 Mar 2014 08:45:14 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.73]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 08:45:13 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/Xn9wvmyrSf2I+rd4YT2PBgAAVchQAAoVTgAAJYd7MAASGUMAAjGvvAAAGqE1AAASCMEAAB79sfA=
Date: Thu, 20 Mar 2014 07:45:13 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151C94B9@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se> <5328ADAA.40503@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C8204@DEMUMBX014.nsn-intra.net> <5329D966.5000800@usdonovans.com>
In-Reply-To: <5329D966.5000800@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.103]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151C94B9DEMUMBX014nsnin_"
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: 46596
X-purgate-ID: 151667::1395301515-00003319-AB1BE94D/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3nGbbfJhyUXkOWEZAxT6j105MnE
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: Thu, 20 Mar 2014 07:45:35 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C94B9DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

please be more specific.
What are the issues?

If there are issues, they need to be solved anyway, no matter whether we ch=
ose for a separate extension or not.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 19, 2014 6:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I'm concerned there are issues with agents, and potentially reporting nodes=
, that would lurk behind this proposal.  I think it is best to leave this t=
o a separate enhancement to be sure that those issues are properly vetted.

Regards,

Steve
On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve, all,

one proposal to solve the issue was to let clients indicate in OC-Supported=
-Features that they support client specific throttling (while agents taking=
 the role of the reacting node on behalf of multiple clients would not indi=
cate such support).

This could certainly be done by a separate extension to the DOIC specificat=
ion, but, given that clients allways support  client specific throttling, c=
lients not aware of the extension would not indicate so in OC-Supported Fea=
tures which is realy a pitty.

Therefore I would like to ask people considering taking this small enhancem=
ent on board:

Clients allways indicate support of client specific throttling;
Agents (taking the role of  a reacting node on behalf of multiple clients) =
never indicate support of client specific throttling;
Reporting nodes may make use of this indication and request client specific=
 throttling only when the reacting node indicated support.

Best regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, March 18, 2014 9:34 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

All,

As Maria Cruz indicates, the tentative conclusion in the DIME working group=
 meeting in London was that this requirement be addressed in a separate ext=
ension to the DOIC specification.

As a result, I propose that we close this issue indicating that no changes =
will be made to the DOIC specification, with the statement that it needs to=
 be addressed in an extension.

Regards,

Steve
On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
Dear Ulrich,

See comments below please.
Anyway, since during IETF meeting it was commented that this could be consi=
dered as an extension, not sure how this should be managed from now on. I p=
resume we should confirm that in this list.

Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request repor=
ts. Can you please confirm.
[MCruz] I think this case is different. If we agree that realm reports are =
only generated by agents (as an aggregated report based on host reports and=
 potentially another implementation dependent criteria), then the server it=
self does not require a traffic-to-realm reduction, on the contrary, the ho=
st only requests a traffic-to-host reduction. Agent may or not (I think thi=
s is up in the draft) to  forward back to the original client this host-rep=
ort. Then, not sure if we really need something else here.
 I don't know whether it is still relevant, but I would have though=
t that the agent that generates a realm-routed-request report, when taking =
the host reports received from servers into accout for the aggregation, may=
 e.g. detect that all the severs request reduction of traffic from the same=
 a specific client. Would it not be logical that the aggregated realm-route=
d-request report in this case also only requests reduction from that client=
 (with the aggregated percentage)? 
[MCruz] This could be something to be considered and could provide some add=
ed value, but it is up to interpretation whether this is required.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4=
.7.  please confirm.
[MCruz] It does address the 3GPP requirement in general, but not for one sp=
ecific case:  "There is one special case here, when the agent is acting on =
behalf of the client (i.e. for a non-supporting client or for an agent SFE =
with topology hiding)".
 I'm not sure, see below

Also proposal b)  impacts the reporting node which must not send client spe=
cific OLRs (with separate sequence number streams for different clients)
[MCruz] I do not think so. In the case I mentioned, when the agent is actin=
g on behalf of the client, it is always the receiver of the answers (i.e. f=
rom a host perspective, the client is the agent
This is not correct. The host (reporting node) does not know whethe=
r the reacting node is the client (identified by orig-host in the request) =
or an agent (acting on behalf of the client and possibly also on behalf of =
other clients); the reporting node receives a request that contains an OC-S=
upported-Features AVP; this indicates to the reporting node that there is a=
 downstream node supporting DOIC. Let me give an example:
Two non-supporting clients C1 and C2 send requests via the same supporting =
agent A to the server. Traffic from C1 increases, so S requests a 10% throt=
tling from C1 (sequence number 1). As the agent A is acting on behalf of C1=
, A will do the throttling. As a not wanted but acceptable side effect A wi=
ll also throttle traffic sent from C2 to S. Now the situation improves and =
S only requests a 5% reduction from C1 (sequence number 2).  Again A will a=
pply the 5% throttling also for traffic from C2, which again is not nice bu=
t acceptable. Now  Traffic from C2 increases (although throttled with 5%) a=
nd S request a 50% throttling from C2 (sequence number 1). 
, and then there are not separate sequence number streams).
[MCruz] I think your example is right, and it highlights something importan=
t I haven't realized. Since the server may send totally different reduction=
 requests to different clients, as in your example, the key point is not ev=
en that they carry different sequence numbers, but that reduction to apply =
to "all" clients will oscillate a lot, depending on server requests towards=
 one specific client. Then, a way to solve this is that the server knows wh=
ether or not an agent is acting on behalf of the final client. If so, repor=
ting node should not request reductions per client (i.e. %reduction will be=
 the same for any client).

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type rep=
ort to any non-DOIC-supporting client that is sending requests towards this=
 host/realm.
[MCruz] Yes, any non-DOIC-supporting client.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but=
 not Steve)  think it is "natural" and "implicit" that agents would do the =
per client behaviour as a default.
[MCruz] Agreed, at least clarification is required.

An alternative proposal that addresses the complexity argument for agents b=
ut at the same time at least partly addresses the 3GPP requirement would be=
 to make use of a feature flag: clients allways set the flag, agents do not=
 set the flag, reporting nodes may send client specific OLRs when the flag =
in the request was set. This has no big impact to clients (only always set =
the feature flag), no impacts to agents, and allows (if so desired) reporti=
ng nodes to make use of the client specific throttling (at least in some ca=
ses).
any comments?
[MCruz] I agree this could be a way for the reporting node to know that an =
agent is not acting on behalf of a client

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)      We expect the agent to apply the host-report received in an answer =
to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)      We expect the agent to apply this host-report to any client that is=
 sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz







_______________________________________________

DiME mailing list

DiME@ietf.org

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



--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C94B9DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

please be =
more specific.


What are t=
he issues?


 =
;


If there a=
re issues, they need to be solved anyway, no matter whether we chose for a =
separate extension or not.


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Wednesday, March 19, 2014 6:53 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Ulrich,



I'm concerned there are issues with agents, and potentially reporting nodes=
, that would lurk behind this proposal.  I think it is best to leave t=
his to a separate enhancement to be sure that those issues are properly vet=
ted.



Regards,



Steve




On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve, all,


 <=
/p>

one propos=
al to solve the issue was to let clients indicate in OC-Supported-Features =
that they support client specific throttling (while agents
 taking the role of the reacting node on behalf of multiple clients would n=
ot indicate such support).


 


This could=
 certainly be done by a separate extension to the DOIC specification, but, =
given that clients allways support  client specific throttling,
 clients not aware of the extension would not indicate so in OC-Supported F=
eatures which is realy a pitty.


 


Therefore =
I would like to ask people considering taking this small enhancement on boa=
rd:


 


Clients al=
lways indicate support of client specific throttling;


Agents (ta=
king the role of  a reacting node on behalf of multiple clients) never=
 indicate support of client specific throttling;


Reporting =
nodes may make use of this indication and request client specific throttlin=
g only when the reacting node indicated support.


 


Best regar=
ds


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, March 18, 2014 9:34 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


All,



As Maria Cruz indicates, the tentative conclusion in the DIME working group=
 meeting in London was that this requirement be addressed in a separate ext=
ension to the DOIC specification.



As a result, I propose that we close this issue indicating that no changes =
will be made to the DOIC specification, with the statement that it needs to=
 be addressed in an extension.



Regards,



Steve




On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:=







Dear Ulrich,<=
/o:p>


 <=
/p>

See comments below please=
.


Anyway, since during IETF=
 meeting it was commented that this could be considered as an extension, no=
t sure how this should be managed from now on. I presume
 we should confirm that in this list.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: jueves, 06 de marzo de 2014 10:12

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: RE: [Dime] Issue#35 conclusion






 


Dear MCruz,


 <=
/p>

for my clarification:



what you say about Host r=
eports is also true for Realm-Routed-Request reports. Can you please confir=
m.


[MCruz] I think this case=
 is different. If we agree that realm reports are only generated by agents =
(as an aggregated report based on host reports and potentially
 another implementation dependent criteria), then the server itself does no=
t require a traffic-to-realm reduction, on the contrary, the host only requ=
ests a traffic-to-host reduction. Agent may or not (I think this is up in t=
he draft) to  forward back to the
 original client this host-report. Then, not sure if we really need somethi=
ng else here.


<Ulrich> I don’t =
know whether it is still relevant, but I would have thought that the agent =
that generates a realm-routed-request report, when taking the host reports
 received from servers into accout for the aggregation, may e.g. detect tha=
t all the severs request reduction of traffic from the same a specific clie=
nt. Would it not be logical that the aggregated realm-routed-request report=
 in this case also only requests
 reduction from that client (with the aggregated percentage)? </Ulrich&g=
t;


[MCruz] This could be =
something to be considered and could provide some added value, but it is up=
 to interpretation whether this is required.



 <=
/p>

Proposal b) does not addr=
ess the 3GPP requirement from TR 29.809 clause 6.4.7.  please confirm.=



[MCruz] It does address t=
he 3GPP requirement in general, but not for one specific case:  “=
;There
 is one special case here, when the agent is acting on behalf of the client=
 (i.e. for a non-supporting client or for an agent SFE with topology hiding=
)”.


<Ulrich> I’m not =
sure, see below</Ulrich>



 <=
/p>

Also proposal b)  im=
pacts the reporting node which must not send client specific OLRs (with sep=
arate sequence number streams for different clients)


[MCruz] I do not think so=
. In the case I mentioned, when the agent is acting on behalf of the client=
, it is always the receiver of the answers (i.e. from a
 host perspective, the client is the agent


<Ulrich>This is not cor=
rect. The host (reporting node) does not know whether the reacting node is =
the client (identified by orig-host in the request) or an agent
 (acting on behalf of the client and possibly also on behalf of other clien=
ts); the reporting node receives a request that contains an OC-Supported-Fe=
atures AVP; this indicates to the reporting node that there is a downstream=
 node supporting DOIC. Let me give
 an example:


Two non-supporting clients C1=
 and C2 send requests via the same supporting agent A to the server. Traffi=
c from C1 increases, so S requests a 10% throttling from
 C1 (sequence number 1). As the agent A is acting on behalf of C1, A will d=
o the throttling. As a not wanted but acceptable side effect A will also th=
rottle traffic sent from C2 to S. Now the situation improves and S only req=
uests a 5% reduction from C1 (sequence
 number 2).  Again A will apply the 5% throttling also for traffic fro=
m C2, which again is not nice but acceptable. Now  Traffic from C2 inc=
reases (although throttled with 5%) and S request a 50% throttling from C2 =
(sequence number 1). </Ulrich>



, and then there are not =
separate sequence number streams).


[MCruz] I think your e=
xample is right, and it highlights something important I haven’t real=
ized. Since the server may send totally different reduction requests
 to different clients, as in your example, the key point is not even that t=
hey carry different sequence numbers, but that reduction to apply to “=
;all” clients will oscillate a lot, depending on server requests towa=
rds one specific client. Then, a way to solve
 this is that the server knows whether or not an agent is acting on behalf =
of the final client. If so, reporting node should not request reductions pe=
r client (i.e. %reduction will be the same for any client).


 <=
/p>

Also, shouldn’t b) =
read:


We expect the agent to ap=
ply this host type / realm-routed-request type report to any
non-DOIC-supporting client that is sending requests towards this hos=
t/realm.


[MCruz] Yes, any non-DOIC=
-supporting client.


 <=
/p>

Also, you say:


b) does not require any c=
hanges to the actual draft


 <=
/p>

I guess at least some cla=
rification is required as some (Lionel, Nirav, but not Steve)  think i=
t is “natural” and “implicit” that agents would do =
the per client
 behaviour as a default. 


[MCruz] Agreed, at least =
clarification is required.


 <=
/p>

An alternative proposal t=
hat addresses the complexity argument for agents but at the same time at le=
ast partly addresses the 3GPP requirement would be to make
 use of a feature flag: clients allways set the flag, agents do not set the=
 flag, reporting nodes may send client specific OLRs when the flag in the r=
equest was set. This has no big impact to clients (only always set the feat=
ure flag), no impacts to agents,
 and allows (if so desired) reporting nodes to make use of the client speci=
fic throttling (at least in some cases).


<Ulrich>any comments?&l=
t;/Ulrich>


[MCruz] I agree this c=
ould be a way for the reporting node to know that an agent is not acting on=
 behalf of a client


 <=
/p>

Best regards<=
/o:p>


Ulrich<=
/p>

 <=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, March 06, 2014 9:00 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


 <=
/p>

 


Dear all,


 <=
/p>

This mail thread started =
proposing new OLR reports to request reduction for one specific client.



However, the discussion c=
larified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is one special case=
 here, when the agent is acting on behalf of the client (i.e. for a non-sup=
porting client or for an agent SFE with topology hiding).
 In this case, the reporting node sends host-report to agent. Here we have =
two options:


 <=
/p>

a)     
We expect the agent t=
o apply the host-report received in an answer to specifically the client th=
at sent the corresponding request


This requires some=
 extra complexity at agent side.


But here we have o=
ne more option: allow the reporting node to choose whether it prefers to ap=
ply this host-report to “all-client” vs “one-client”=
;. That
 increases again the complexity (at reporting node, protocol-wise, and at a=
gent).


 =



b)     
We expect the agent t=
o apply this host-report to
any client that is sending a request towards this agent


In my opinion, thi=
s is the best approach, it reduces complexity and increases robustness.



 <=
/p>

Therefore, I will be in f=
avor of option b), which does not require any changes to the actual draft.<=
/span>


 <=
/p>

Let me know your opinions=
.


Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C94B9DEMUMBX014nsnin_--


From nobody Thu Mar 20 06:09:15 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 898241A08DB for ; Thu, 20 Mar 2014 06:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 JlHdveThc3B2 for ; Thu, 20 Mar 2014 06:08:49 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 27D901A08CA for ; Thu, 20 Mar 2014 06:08:38 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2KD8SGG015138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 20 Mar 2014 13:08:29 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2KD8SCW013311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Mar 2014 14:08:28 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 20 Mar 2014 14:08:28 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.73]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Thu, 20 Mar 2014 14:08:28 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dg==
Date: Thu, 20 Mar 2014 13:08:27 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151C95D6@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.103]
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: 3888
X-purgate-ID: 151667::1395320909-0000137C-368225D9/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Tz6Sv4eLYUsvIgn9B9H34fkELlI
Subject: [Dime] issue #56 proposed 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: Thu, 20 Mar 2014 13:09:05 -0000

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

Ulrich



From nobody Thu Mar 20 06:29: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 8C1561A0762 for ; Thu, 20 Mar 2014 06:29:44 -0700 (PDT)
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 S8xeki1EgYUW for ; Thu, 20 Mar 2014 06:29:40 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA5B1A06D2 for ; Thu, 20 Mar 2014 06:29:40 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:53899 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQd2E-0004T8-El; Thu, 20 Mar 2014 06:29:29 -0700
Message-ID: <532AED36.8070802@usdonovans.com>
Date: Thu, 20 Mar 2014 08:29:26 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se> <5328ADAA.40503@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C8204@DEMUMBX014.nsn-intra.net> <5329D966.5000800@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C94B9@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151C94B9@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------050109080604040808040207"
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/Gn1uvJCdmP3ubjUS6KFCu-O00vs
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: Thu, 20 Mar 2014 13:29:44 -0000

This is a multi-part message in MIME format.
--------------050109080604040808040207
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

The reason for this being an extension is so that we do not delay the
base DOIC specification spending time thinking through those issues. 
The same argument has been made about the agent overload extension.

Let's focus on getting the base specification done, then we can address
this and other extensions that are considered important.

Steve

On 3/20/14 2:45 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> please be more specific.
>
> What are the issues?
>
>  
>
> If there are issues, they need to be solved anyway, no matter whether
> we chose for a separate extension or not.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Wednesday, March 19, 2014 6:53 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Ulrich,
>
> I'm concerned there are issues with agents, and potentially reporting
> nodes, that would lurk behind this proposal.  I think it is best to
> leave this to a separate enhancement to be sure that those issues are
> properly vetted.
>
> Regards,
>
> Steve
>
> On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve, all,
>
>      
>
>     one proposal to solve the issue was to let clients indicate in
>     OC-Supported-Features that they support client specific throttling
>     (while agents taking the role of the reacting node on behalf of
>     multiple clients would not indicate such support).
>
>      
>
>     This could certainly be done by a separate extension to the DOIC
>     specification, but, given that clients allways support  client
>     specific throttling, clients not aware of the extension would not
>     indicate so in OC-Supported Features which is realy a pitty.
>
>      
>
>     Therefore I would like to ask people considering taking this small
>     enhancement on board:
>
>      
>
>     Clients allways indicate support of client specific throttling;
>
>     Agents (taking the role of  a reacting node on behalf of multiple
>     clients) never indicate support of client specific throttling;
>
>     Reporting nodes may make use of this indication and request client
>     specific throttling only when the reacting node indicated support.
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Tuesday, March 18, 2014 9:34 PM
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>     All,
>
>     As Maria Cruz indicates, the tentative conclusion in the DIME
>     working group meeting in London was that this requirement be
>     addressed in a separate extension to the DOIC specification.
>
>     As a result, I propose that we close this issue indicating that no
>     changes will be made to the DOIC specification, with the statement
>     that it needs to be addressed in an extension.
>
>     Regards,
>
>     Steve
>
>     On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
>
>         Dear Ulrich,
>
>          
>
>         See comments below please.
>
>         Anyway, since during IETF meeting it was commented that this
>         could be considered as an extension, not sure how this should
>         be managed from now on. I presume we should confirm that in
>         this list.
>
>          
>
>         Best regards
>
>         /MCruz
>
>          
>
>         *From:*Wiehe, Ulrich (NSN - DE/Munich)
>         [mailto:ulrich.wiehe@nsn.com]
>         *Sent:* jueves, 06 de marzo de 2014 10:12
>         *To:* Maria Cruz Bartolome; dime@ietf.org 
>         *Subject:* RE: [Dime] Issue#35 conclusion
>
>          
>
>         Dear MCruz,
>
>          
>
>         for my clarification:
>
>         what you say about Host reports is also true for
>         Realm-Routed-Request reports. Can you please confirm.
>
>         [MCruz] I think this case is different. If we agree that realm
>         reports are only generated by agents (as an aggregated report
>         based on host reports and potentially another implementation
>         dependent criteria), then the server itself does not require a
>         traffic-to-realm reduction, on the contrary, the host only
>         requests a traffic-to-host reduction. Agent may or not (I
>         think this is up in the draft) to  forward back to the
>         original client this host-report. Then, not sure if we really
>         need something else here.
>
>          I don't know whether it is still relevant, but I
>         would have thought that the agent that generates a
>         realm-routed-request report, when taking the host reports
>         received from servers into accout for the aggregation, may
>         e.g. detect that all the severs request reduction of traffic
>         from the same a specific client. Would it not be logical that
>         the aggregated realm-routed-request report in this case also
>         only requests reduction from that client (with the aggregated
>         percentage)? 
>
>         [MCruz] This could be something to be considered and could
>         provide some added value, but it is up to interpretation
>         whether this is required.
>
>          
>
>         Proposal b) does not address the 3GPP requirement from TR
>         29.809 clause 6.4.7.  please confirm.
>
>         [MCruz] It does address the 3GPP requirement in general, but
>         not for one specific case:  "There is one special case here,
>         when the agent is acting on behalf of the client (i.e. for a
>         non-supporting client or for an agent SFE with topology hiding)".
>
>          I'm not sure, see below
>
>          
>
>         Also proposal b)  impacts the reporting node which must not
>         send client specific OLRs (with separate sequence number
>         streams for different clients)
>
>         [MCruz] I do not think so. In the case I mentioned, when the
>         agent is acting on behalf of the client, it is always the
>         receiver of the answers (i.e. from a host perspective, the
>         client is the agent
>
>         This is not correct. The host (reporting node) does
>         not know whether the reacting node is the client (identified
>         by orig-host in the request) or an agent (acting on behalf of
>         the client and possibly also on behalf of other clients); the
>         reporting node receives a request that contains an
>         OC-Supported-Features AVP; this indicates to the reporting
>         node that there is a downstream node supporting DOIC. Let me
>         give an example:
>
>         Two non-supporting clients C1 and C2 send requests via the
>         same supporting agent A to the server. Traffic from C1
>         increases, so S requests a 10% throttling from C1 (sequence
>         number 1). As the agent A is acting on behalf of C1, A will do
>         the throttling. As a not wanted but acceptable side effect A
>         will also throttle traffic sent from C2 to S. Now the
>         situation improves and S only requests a 5% reduction from C1
>         (sequence number 2).  Again A will apply the 5% throttling
>         also for traffic from C2, which again is not nice but
>         acceptable. Now  Traffic from C2 increases (although throttled
>         with 5%) and S request a 50% throttling from C2 (sequence
>         number 1). 
>
>         , and then there are not separate sequence number streams).
>
>         [MCruz] I think your example is right, and it highlights
>         something important I haven't realized. Since the server may
>         send totally different reduction requests to different
>         clients, as in your example, the key point is not even that
>         they carry different sequence numbers, but that reduction to
>         apply to "all" clients will oscillate a lot, depending on
>         server requests towards one specific client. Then, a way to
>         solve this is that the server knows whether or not an agent is
>         acting on behalf of the final client. If so, reporting node
>         should not request reductions per client (i.e. %reduction will
>         be the same for any client).
>
>          
>
>         Also, shouldn't b) read:
>
>         We expect the agent to apply this host type /
>         realm-routed-request type report to any *non-DOIC-supporting*
>         client that is sending requests towards this host/realm.
>
>         [MCruz] Yes, any non-DOIC-supporting client.
>
>          
>
>         Also, you say:
>
>         b) does not require any changes to the actual draft
>
>          
>
>         I guess at least some clarification is required as some
>         (Lionel, Nirav, but not Steve)  think it is "natural" and
>         "implicit" that agents would do the per client behaviour as a
>         default.
>
>         [MCruz] Agreed, at least clarification is required.
>
>          
>
>         An alternative proposal that addresses the complexity argument
>         for agents but at the same time at least partly addresses the
>         3GPP requirement would be to make use of a feature flag:
>         clients allways set the flag, agents do not set the flag,
>         reporting nodes may send client specific OLRs when the flag in
>         the request was set. This has no big impact to clients (only
>         always set the feature flag), no impacts to agents, and allows
>         (if so desired) reporting nodes to make use of the client
>         specific throttling (at least in some cases).
>
>         any comments?
>
>         [MCruz] I agree this could be a way for the reporting node to
>         know that an agent is not acting on behalf of a client
>
>          
>
>         Best regards
>
>         Ulrich
>
>          
>
>          
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>         Maria Cruz Bartolome
>         *Sent:* Thursday, March 06, 2014 9:00 AM
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Issue#35 conclusion
>
>          
>
>          
>
>          
>
>         Dear all,
>
>          
>
>         This mail thread started proposing new OLR reports to request
>         reduction for one specific client.
>
>         However, the discussion clarified that as it is the draft
>         today, *Host*-report is sent from a reporting node towards the
>         client from where it receives the request. Then, reduction is
>         requested per client in all cases already.
>
>         There is one special case here, when the agent is acting on
>         behalf of the client (i.e. for a non-supporting client or for
>         an agent SFE with topology hiding). In this case, the
>         reporting node sends host-report to agent. Here we have two
>         options:
>
>          
>
>         a)      *We expect the agent to apply the host-report received
>         in an answer to specifically the client that sent the
>         corresponding request*
>
>         This requires some extra complexity at agent side.
>
>         But here we have one more option: allow the reporting node to
>         choose whether it prefers to apply this host-report to
>         "all-client" vs "one-client". That increases again the
>         complexity (at reporting node, protocol-wise, and at agent).
>
>          
>
>         b)      *We expect the agent to apply this host-report to
>         _any_ client that is sending a request towards this agent*
>
>         In my opinion, this is the best approach, it reduces
>         complexity and increases robustness.
>
>          
>
>         Therefore, I will be in favor of option b), which does not
>         require any changes to the actual draft.
>
>          
>
>         Let me know your opinions.
>
>         Best regards
>
>         /MCruz
>
>          
>
>          
>
>
>
>
>
>         _______________________________________________
>
>         DiME mailing list
>
>         DiME@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>  
>


--------------050109080604040808040207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      The reason for this being an extension is so that we do not delay
      the base DOIC specification spending time thinking through those
      issues.  The same argument has been made about the agent overload
      extension.

      

      Let's focus on getting the base specification done, then we can
      address this and other extensions that are considered important.

      

      Steve

      

    
    
On 3/20/14 2:45 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
please be more specific.

        
What are the issues?

        
 

        
If there are issues, they need to be solved
            anyway, no matter whether we chose for a separate extension
            or not.

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Wednesday, March 19, 2014 6:53 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Ulrich,

          

          I'm concerned there are issues with agents, and potentially
          reporting nodes, that would lurk behind this proposal.  I
          think it is best to leave this to a separate enhancement to be
          sure that those issues are properly vetted.

          

          Regards,

          

          Steve

        

          
On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve,
              all,

          
 

          
one proposal to solve the issue was to let
              clients indicate in OC-Supported-Features that they
              support client specific throttling (while agents taking
              the role of the reacting node on behalf of multiple
              clients would not indicate such support).

          
 

          
This could certainly be done by a separate
              extension to the DOIC specification, but, given that
              clients allways support  client specific throttling,
              clients not aware of the extension would not indicate so
              in OC-Supported Features which is realy a pitty.

          
 

          
Therefore I would like to ask people
              considering taking this small enhancement on board:

          
 

          
Clients allways indicate support of client
              specific throttling;

          
Agents (taking the role of  a reacting node
              on behalf of multiple clients) never indicate support of
              client specific throttling;

          
Reporting nodes may make use of this
              indication and request client specific throttling only
              when the reacting node indicated support.

          
 

          
Best regards

          
Ulrich

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Tuesday, March 18, 2014 9:34 PM

                  To: dime@ietf.org

                  Subject: Re: [Dime] Issue#35 conclusion

            

          

          
 

          
All,

            

            As Maria Cruz indicates, the tentative conclusion in the
            DIME working group meeting in London was that this
            requirement be addressed in a separate extension to the DOIC
            specification.

            

            As a result, I propose that we close this issue indicating
            that no changes will be made to the DOIC specification, with
            the statement that it needs to be addressed in an extension.

            

            Regards,

            

            Steve

          

            
On 3/7/14 10:30 AM, Maria Cruz
              Bartolome wrote:

          

          

            
Dear
                Ulrich,

            
 

            
See
                comments below please.

            
Anyway,
                since during IETF meeting it was commented that this
                could be considered as an extension, not sure how this
                should be managed from now on. I presume we should
                confirm that in this list.

            
 

            
Best
                regards

            
/MCruz

            
 

            

              

                
From:
                    Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
                    

                    Sent: jueves, 06 de marzo de 2014 10:12

                    To: Maria Cruz Bartolome; dime@ietf.org

                    Subject: RE: [Dime] Issue#35 conclusion

              

            

            
 

            
Dear
                MCruz,

            
 

            
for
                my clarification:
              

            
what
                you say about Host reports is also true for
                Realm-Routed-Request reports. Can you please confirm.

            
[MCruz]
                I think this case is different. If we agree that realm
                reports are only generated by agents (as an aggregated
                report based on host reports and potentially another
                implementation dependent criteria), then the server
                itself does not require a traffic-to-realm reduction, on
                the contrary, the host only requests a traffic-to-host
                reduction. Agent may or not (I think this is up in the
                draft) to  forward back to the original client this
                host-report. Then, not sure if we really need something
                else here.

            
<Ulrich>
                I don’t know whether it is still relevant, but I would
                have thought that the agent that generates a
                realm-routed-request report, when taking the host
                reports received from servers into accout for the
                aggregation, may e.g. detect that all the severs request
                reduction of traffic from the same a specific client.
                Would it not be logical that the aggregated
                realm-routed-request report in this case also only
                requests reduction from that client (with the aggregated
                percentage)? </Ulrich>

            
[MCruz]
                This could be something to be considered and could
                provide some added value, but it is up to interpretation
                whether this is required.
              

            
 

            
Proposal
                b) does not address the 3GPP requirement from TR 29.809
                clause 6.4.7.  please confirm.

            
[MCruz]
                It does address the 3GPP requirement in general, but not
                for one specific case:  “There

                is one special case here, when the agent is acting on
                behalf of the client (i.e. for a non-supporting client
                or for an agent SFE with topology hiding)”.

            
<Ulrich>
                I’m not sure, see below</Ulrich>
              

            
 

            
Also
                proposal b)  impacts the reporting node which must not
                send client specific OLRs (with separate sequence number
                streams for different clients)

            
[MCruz]
                I do not think so. In the case I mentioned, when the
                agent is acting on behalf of the client, it is always
                the receiver of the answers (i.e. from a host
                perspective, the client is the agent

            
<Ulrich>This
                is not correct. The host (reporting node) does not know
                whether the reacting node is the client (identified by
                orig-host in the request) or an agent (acting on behalf
                of the client and possibly also on behalf of other
                clients); the reporting node receives a request that
                contains an OC-Supported-Features AVP; this indicates to
                the reporting node that there is a downstream node
                supporting DOIC. Let me give an example:

            
Two
                non-supporting clients C1 and C2 send requests via the
                same supporting agent A to the server. Traffic from C1
                increases, so S requests a 10% throttling from C1
                (sequence number 1). As the agent A is acting on behalf
                of C1, A will do the throttling. As a not wanted but
                acceptable side effect A will also throttle traffic sent
                from C2 to S. Now the situation improves and S only
                requests a 5% reduction from C1 (sequence number 2).
                 Again A will apply the 5% throttling also for traffic
                from C2, which again is not nice but acceptable. Now
                 Traffic from C2 increases (although throttled with 5%)
                and S request a 50% throttling from C2 (sequence number
                1). </Ulrich>
              

            
,
                and then there are not separate sequence number
                streams).

            
[MCruz]
                I think your example is right, and it highlights
                something important I haven’t realized. Since the server
                may send totally different reduction requests to
                different clients, as in your example, the key point is
                not even that they carry different sequence numbers, but
                that reduction to apply to “all” clients will oscillate
                a lot, depending on server requests towards one specific
                client. Then, a way to solve this is that the server
                knows whether or not an agent is acting on behalf of the
                final client. If so, reporting node should not request
                reductions per client (i.e. %reduction will be the same
                for any client).

            
 

            
Also,
                shouldn’t b) read:

            
We
                expect the agent to apply this host type /
                realm-routed-request type report to any
                non-DOIC-supporting client that is sending
                requests towards this host/realm.

            
[MCruz]
                Yes, any non-DOIC-supporting client.

            
 

            
Also,
                you say:

            
b)
                does not require any changes to the actual draft

            
 

            
I
                guess at least some clarification is required as some
                (Lionel, Nirav, but not Steve)  think it is “natural”
                and “implicit” that agents would do the per client
                behaviour as a default. 

            
[MCruz]
                Agreed, at least clarification is required.

            
 

            
An
                alternative proposal that addresses the complexity
                argument for agents but at the same time at least partly
                addresses the 3GPP requirement would be to make use of a
                feature flag: clients allways set the flag, agents do
                not set the flag, reporting nodes may send client
                specific OLRs when the flag in the request was set. This
                has no big impact to clients (only always set the
                feature flag), no impacts to agents, and allows (if so
                desired) reporting nodes to make use of the client
                specific throttling (at least in some cases).

            
<Ulrich>any
                comments?</Ulrich>

            
[MCruz]
                I agree this could be a way for the reporting node to
                know that an agent is not acting on behalf of a client

            
 

            
Best
                regards

            
Ulrich

            
 

            
 

            
 

            

              

                
From:
                    DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of ext Maria Cruz Bartolome

                    Sent: Thursday, March 06, 2014 9:00 AM

                    To: dime@ietf.org

                    Subject: Re: [Dime] Issue#35 conclusion

              

            

            
 

            
 

            
 

            
Dear
                all,

            
 

            
This
                mail thread started proposing new OLR reports to request
                reduction for one specific client.
              

            
However,
                the discussion clarified that as it is the draft today,
                Host-report is sent from a reporting node towards
                the client from where it receives the request. Then,
                reduction is requested per client in all cases already.
              

            
There
                is one special case here, when the agent is acting on
                behalf of the client (i.e. for a non-supporting client
                or for an agent SFE with topology hiding). In this case,
                the reporting node sends host-report to agent. Here we
                have two options:

            
 

            
a)     
                We
                  expect the agent to apply the host-report received in
                  an answer to specifically the client that sent the
                  corresponding request

            
This
                requires some extra complexity at agent side.

            
But
                here we have one more option: allow the reporting node
                to choose whether it prefers to apply this host-report
                to “all-client” vs “one-client”. That increases again
                the complexity (at reporting node, protocol-wise, and at
                agent).

            
 

            
b)     
                We
                  expect the agent to apply this host-report to
                  any client that is sending a request towards
                  this agent

            
In
                my opinion, this is the best approach, it reduces
                complexity and increases robustness.
              

            
 

            
Therefore,
                I will be in favor of option b), which does not require
                any changes to the actual draft.

            
 

            
Let
                me know your opinions.

            
Best
                regards

            
/MCruz

            
 

            
 

            


              

              

              

              

            
_______________________________________________

            
DiME mailing list

            
DiME@ietf.org

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

          

          
 

        

        
 

      

    

    

  


--------------050109080604040808040207--


From nobody Fri Mar 21 01:22:27 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 33F621A0395 for ; Fri, 21 Mar 2014 01:22:26 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 eGcHhRElIOZY for ; Fri, 21 Mar 2014 01:22:19 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB501A0684 for ; Fri, 21 Mar 2014 01:22:19 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2L8M8DI021475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Mar 2014 08:22:09 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2L8M8kp006307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 09:22:08 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.73]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 09:22:08 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#35 conclusion
Thread-Index: Ac85Egw/Xn9wvmyrSf2I+rd4YT2PBgAAVchQAAoVTgAAJYd7MAASGUMAAjGvvAAAGqE1AAASCMEAAB79sfAAChu4AAAoACvw
Date: Fri, 21 Mar 2014 08:22:07 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151C969D@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se> <5328ADAA.40503@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C8204@DEMUMBX014.nsn-intra.net> <5329D966.5000800@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C94B9@DEMUMBX014.nsn-intra.net> <532AED36.8070802@usdonovans.com>
In-Reply-To: <532AED36.8070802@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.117]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151C969DDEMUMBX014nsnin_"
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: 52174
X-purgate-ID: 151667::1395390129-0000128C-C19A5124/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XhYrhE4psjnErmHVTdVT-AxI17Y
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: Fri, 21 Mar 2014 08:22:26 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C969DDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

while I understand and agree that we should not delay the base DOIC specifi=
cation, I do not understand why "stop thinking" is the way to achieve this.

Is it that you don't want to spend time on identified issues (if so, which =
issues?), or that you don't want to spend time on the proposal?
I still don't know what the issues with this proposal are.
On the other hand I have indicated what the issue is when addressing client=
 specific throttling with an extension: Clients which are not aware of the =
extension are still clients and therefore support client specific throttlin=
g but do not indicate so to reporting nodes which (when supporting the exte=
nsion) cannot make use of client specific throttling although supported by =
both reacting and reporting nodes.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, March 20, 2014 2:29 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

The reason for this being an extension is so that we do not delay the base =
DOIC specification spending time thinking through those issues.  The same a=
rgument has been made about the agent overload extension.

Let's focus on getting the base specification done, then we can address thi=
s and other extensions that are considered important.

Steve
On 3/20/14 2:45 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

please be more specific.
What are the issues?

If there are issues, they need to be solved anyway, no matter whether we ch=
ose for a separate extension or not.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 19, 2014 6:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

Ulrich,

I'm concerned there are issues with agents, and potentially reporting nodes=
, that would lurk behind this proposal.  I think it is best to leave this t=
o a separate enhancement to be sure that those issues are properly vetted.

Regards,

Steve
On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve, all,

one proposal to solve the issue was to let clients indicate in OC-Supported=
-Features that they support client specific throttling (while agents taking=
 the role of the reacting node on behalf of multiple clients would not indi=
cate such support).

This could certainly be done by a separate extension to the DOIC specificat=
ion, but, given that clients allways support  client specific throttling, c=
lients not aware of the extension would not indicate so in OC-Supported Fea=
tures which is realy a pitty.

Therefore I would like to ask people considering taking this small enhancem=
ent on board:

Clients allways indicate support of client specific throttling;
Agents (taking the role of  a reacting node on behalf of multiple clients) =
never indicate support of client specific throttling;
Reporting nodes may make use of this indication and request client specific=
 throttling only when the reacting node indicated support.

Best regards
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Tuesday, March 18, 2014 9:34 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion

All,

As Maria Cruz indicates, the tentative conclusion in the DIME working group=
 meeting in London was that this requirement be addressed in a separate ext=
ension to the DOIC specification.

As a result, I propose that we close this issue indicating that no changes =
will be made to the DOIC specification, with the statement that it needs to=
 be addressed in an extension.

Regards,

Steve
On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
Dear Ulrich,

See comments below please.
Anyway, since during IETF meeting it was commented that this could be consi=
dered as an extension, not sure how this should be managed from now on. I p=
resume we should confirm that in this list.

Best regards
/MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: jueves, 06 de marzo de 2014 10:12
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] Issue#35 conclusion

Dear MCruz,

for my clarification:
what you say about Host reports is also true for Realm-Routed-Request repor=
ts. Can you please confirm.
[MCruz] I think this case is different. If we agree that realm reports are =
only generated by agents (as an aggregated report based on host reports and=
 potentially another implementation dependent criteria), then the server it=
self does not require a traffic-to-realm reduction, on the contrary, the ho=
st only requests a traffic-to-host reduction. Agent may or not (I think thi=
s is up in the draft) to  forward back to the original client this host-rep=
ort. Then, not sure if we really need something else here.
 I don't know whether it is still relevant, but I would have though=
t that the agent that generates a realm-routed-request report, when taking =
the host reports received from servers into accout for the aggregation, may=
 e.g. detect that all the severs request reduction of traffic from the same=
 a specific client. Would it not be logical that the aggregated realm-route=
d-request report in this case also only requests reduction from that client=
 (with the aggregated percentage)? 
[MCruz] This could be something to be considered and could provide some add=
ed value, but it is up to interpretation whether this is required.

Proposal b) does not address the 3GPP requirement from TR 29.809 clause 6.4=
.7.  please confirm.
[MCruz] It does address the 3GPP requirement in general, but not for one sp=
ecific case:  "There is one special case here, when the agent is acting on =
behalf of the client (i.e. for a non-supporting client or for an agent SFE =
with topology hiding)".
 I'm not sure, see below

Also proposal b)  impacts the reporting node which must not send client spe=
cific OLRs (with separate sequence number streams for different clients)
[MCruz] I do not think so. In the case I mentioned, when the agent is actin=
g on behalf of the client, it is always the receiver of the answers (i.e. f=
rom a host perspective, the client is the agent
This is not correct. The host (reporting node) does not know whethe=
r the reacting node is the client (identified by orig-host in the request) =
or an agent (acting on behalf of the client and possibly also on behalf of =
other clients); the reporting node receives a request that contains an OC-S=
upported-Features AVP; this indicates to the reporting node that there is a=
 downstream node supporting DOIC. Let me give an example:
Two non-supporting clients C1 and C2 send requests via the same supporting =
agent A to the server. Traffic from C1 increases, so S requests a 10% throt=
tling from C1 (sequence number 1). As the agent A is acting on behalf of C1=
, A will do the throttling. As a not wanted but acceptable side effect A wi=
ll also throttle traffic sent from C2 to S. Now the situation improves and =
S only requests a 5% reduction from C1 (sequence number 2).  Again A will a=
pply the 5% throttling also for traffic from C2, which again is not nice bu=
t acceptable. Now  Traffic from C2 increases (although throttled with 5%) a=
nd S request a 50% throttling from C2 (sequence number 1). 
, and then there are not separate sequence number streams).
[MCruz] I think your example is right, and it highlights something importan=
t I haven't realized. Since the server may send totally different reduction=
 requests to different clients, as in your example, the key point is not ev=
en that they carry different sequence numbers, but that reduction to apply =
to "all" clients will oscillate a lot, depending on server requests towards=
 one specific client. Then, a way to solve this is that the server knows wh=
ether or not an agent is acting on behalf of the final client. If so, repor=
ting node should not request reductions per client (i.e. %reduction will be=
 the same for any client).

Also, shouldn't b) read:
We expect the agent to apply this host type / realm-routed-request type rep=
ort to any non-DOIC-supporting client that is sending requests towards this=
 host/realm.
[MCruz] Yes, any non-DOIC-supporting client.

Also, you say:
b) does not require any changes to the actual draft

I guess at least some clarification is required as some (Lionel, Nirav, but=
 not Steve)  think it is "natural" and "implicit" that agents would do the =
per client behaviour as a default.
[MCruz] Agreed, at least clarification is required.

An alternative proposal that addresses the complexity argument for agents b=
ut at the same time at least partly addresses the 3GPP requirement would be=
 to make use of a feature flag: clients allways set the flag, agents do not=
 set the flag, reporting nodes may send client specific OLRs when the flag =
in the request was set. This has no big impact to clients (only always set =
the feature flag), no impacts to agents, and allows (if so desired) reporti=
ng nodes to make use of the client specific throttling (at least in some ca=
ses).
any comments?
[MCruz] I agree this could be a way for the reporting node to know that an =
agent is not acting on behalf of a client

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Barto=
lome
Sent: Thursday, March 06, 2014 9:00 AM
To: dime@ietf.org
Subject: Re: [Dime] Issue#35 conclusion



Dear all,

This mail thread started proposing new OLR reports to request reduction for=
 one specific client.
However, the discussion clarified that as it is the draft today, Host-repor=
t is sent from a reporting node towards the client from where it receives t=
he request. Then, reduction is requested per client in all cases already.
There is one special case here, when the agent is acting on behalf of the c=
lient (i.e. for a non-supporting client or for an agent SFE with topology h=
iding). In this case, the reporting node sends host-report to agent. Here w=
e have two options:


a)      We expect the agent to apply the host-report received in an answer =
to specifically the client that sent the corresponding request

This requires some extra complexity at agent side.

But here we have one more option: allow the reporting node to choose whethe=
r it prefers to apply this host-report to "all-client" vs "one-client". Tha=
t increases again the complexity (at reporting node, protocol-wise, and at =
agent).



b)      We expect the agent to apply this host-report to any client that is=
 sending a request towards this agent

In my opinion, this is the best approach, it reduces complexity and increas=
es robustness.

Therefore, I will be in favor of option b), which does not require any chan=
ges to the actual draft.

Let me know your opinions.
Best regards
/MCruz








_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C969DDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

while I un=
derstand and agree that we should not delay the base DOIC specification, I =
do not understand why “stop thinking” is the way to achieve
 this.


 =
;


Is it that=
 you don’t want to spend time on identified issues (if so, which issu=
es?), or that you don’t want to spend time on the proposal?


I still do=
n’t know what the issues with this proposal are.

On the oth=
er hand I have indicated what the issue is when addressing client specific =
throttling with an extension: Clients which are not aware
 of the extension are still clients and therefore support client specific t=
hrottling but do not indicate so to reporting nodes which (when supporting =
the extension) cannot make use of client specific throttling although suppo=
rted by both reacting and reporting
 nodes.


 =
;


Ulrich



 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Thursday, March 20, 2014 2:29 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Ulrich,



The reason for this being an extension is so that we do not delay the base =
DOIC specification spending time thinking through those issues.  The s=
ame argument has been made about the agent overload extension.



Let's focus on getting the base specification done, then we can address thi=
s and other extensions that are considered important.



Steve




On 3/20/14 2:45 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve,<=
/p>

 <=
/p>

please be =
more specific.


What are t=
he issues?


 


If there a=
re issues, they need to be solved anyway, no matter whether we chose for a =
separate extension or not.


 


Ulrich


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Wednesday, March 19, 2014 6:53 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


Ulrich,



I'm concerned there are issues with agents, and potentially reporting nodes=
, that would lurk behind this proposal.  I think it is best to leave t=
his to a separate enhancement to be sure that those issues are properly vet=
ted.



Regards,



Steve




On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve, all,


 <=
/p>

one propos=
al to solve the issue was to let clients indicate in OC-Supported-Features =
that they support client specific throttling (while agents
 taking the role of the reacting node on behalf of multiple clients would n=
ot indicate such support).


 


This could=
 certainly be done by a separate extension to the DOIC specification, but, =
given that clients allways support  client specific throttling,
 clients not aware of the extension would not indicate so in OC-Supported F=
eatures which is realy a pitty.


 


Therefore =
I would like to ask people considering taking this small enhancement on boa=
rd:


 


Clients al=
lways indicate support of client specific throttling;


Agents (ta=
king the role of  a reacting node on behalf of multiple clients) never=
 indicate support of client specific throttling;


Reporting =
nodes may make use of this indication and request client specific throttlin=
g only when the reacting node indicated support.


 


Best regar=
ds


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Tuesday, March 18, 2014 9:34 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


All,



As Maria Cruz indicates, the tentative conclusion in the DIME working group=
 meeting in London was that this requirement be addressed in a separate ext=
ension to the DOIC specification.



As a result, I propose that we close this issue indicating that no changes =
will be made to the DOIC specification, with the statement that it needs to=
 be addressed in an extension.



Regards,



Steve




On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:=







Dear Ulrich,<=
/o:p>


 <=
/p>

See comments below please=
.


Anyway, since during IETF=
 meeting it was commented that this could be considered as an extension, no=
t sure how this should be managed from now on. I presume
 we should confirm that in this list.


 <=
/p>

Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>





From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]


Sent: jueves, 06 de marzo de 2014 10:12

To: Maria Cruz Bartolome; dime@ietf=
.org

Subject: RE: [Dime] Issue#35 conclusion






 


Dear MCruz,


 <=
/p>

for my clarification:



what you say about Host r=
eports is also true for Realm-Routed-Request reports. Can you please confir=
m.


[MCruz] I think this case=
 is different. If we agree that realm reports are only generated by agents =
(as an aggregated report based on host reports and potentially
 another implementation dependent criteria), then the server itself does no=
t require a traffic-to-realm reduction, on the contrary, the host only requ=
ests a traffic-to-host reduction. Agent may or not (I think this is up in t=
he draft) to  forward back to the
 original client this host-report. Then, not sure if we really need somethi=
ng else here.


<Ulrich> I don’t =
know whether it is still relevant, but I would have thought that the agent =
that generates a realm-routed-request report, when taking the host reports
 received from servers into accout for the aggregation, may e.g. detect tha=
t all the severs request reduction of traffic from the same a specific clie=
nt. Would it not be logical that the aggregated realm-routed-request report=
 in this case also only requests
 reduction from that client (with the aggregated percentage)? </Ulrich&g=
t;


[MCruz] This could be =
something to be considered and could provide some added value, but it is up=
 to interpretation whether this is required.



 <=
/p>

Proposal b) does not addr=
ess the 3GPP requirement from TR 29.809 clause 6.4.7.  please confirm.=



[MCruz] It does address t=
he 3GPP requirement in general, but not for one specific case:  “=
;There
 is one special case here, when the agent is acting on behalf of the client=
 (i.e. for a non-supporting client or for an agent SFE with topology hiding=
)”.


<Ulrich> I’m not =
sure, see below</Ulrich>



 <=
/p>

Also proposal b)  im=
pacts the reporting node which must not send client specific OLRs (with sep=
arate sequence number streams for different clients)


[MCruz] I do not think so=
. In the case I mentioned, when the agent is acting on behalf of the client=
, it is always the receiver of the answers (i.e. from a
 host perspective, the client is the agent


<Ulrich>This is not cor=
rect. The host (reporting node) does not know whether the reacting node is =
the client (identified by orig-host in the request) or an agent
 (acting on behalf of the client and possibly also on behalf of other clien=
ts); the reporting node receives a request that contains an OC-Supported-Fe=
atures AVP; this indicates to the reporting node that there is a downstream=
 node supporting DOIC. Let me give
 an example:


Two non-supporting clients C1=
 and C2 send requests via the same supporting agent A to the server. Traffi=
c from C1 increases, so S requests a 10% throttling from
 C1 (sequence number 1). As the agent A is acting on behalf of C1, A will d=
o the throttling. As a not wanted but acceptable side effect A will also th=
rottle traffic sent from C2 to S. Now the situation improves and S only req=
uests a 5% reduction from C1 (sequence
 number 2).  Again A will apply the 5% throttling also for traffic fro=
m C2, which again is not nice but acceptable. Now  Traffic from C2 inc=
reases (although throttled with 5%) and S request a 50% throttling from C2 =
(sequence number 1). </Ulrich>



, and then there are not =
separate sequence number streams).


[MCruz] I think your e=
xample is right, and it highlights something important I haven’t real=
ized. Since the server may send totally different reduction requests
 to different clients, as in your example, the key point is not even that t=
hey carry different sequence numbers, but that reduction to apply to “=
;all” clients will oscillate a lot, depending on server requests towa=
rds one specific client. Then, a way to solve
 this is that the server knows whether or not an agent is acting on behalf =
of the final client. If so, reporting node should not request reductions pe=
r client (i.e. %reduction will be the same for any client).


 <=
/p>

Also, shouldn’t b) =
read:


We expect the agent to ap=
ply this host type / realm-routed-request type report to any
non-DOIC-supporting client that is sending requests towards this hos=
t/realm.


[MCruz] Yes, any non-DOIC=
-supporting client.


 <=
/p>

Also, you say:


b) does not require any c=
hanges to the actual draft


 <=
/p>

I guess at least some cla=
rification is required as some (Lionel, Nirav, but not Steve)  think i=
t is “natural” and “implicit” that agents would do =
the per client
 behaviour as a default. 


[MCruz] Agreed, at least =
clarification is required.


 <=
/p>

An alternative proposal t=
hat addresses the complexity argument for agents but at the same time at le=
ast partly addresses the 3GPP requirement would be to make
 use of a feature flag: clients allways set the flag, agents do not set the=
 flag, reporting nodes may send client specific OLRs when the flag in the r=
equest was set. This has no big impact to clients (only always set the feat=
ure flag), no impacts to agents,
 and allows (if so desired) reporting nodes to make use of the client speci=
fic throttling (at least in some cases).


<Ulrich>any comments?&l=
t;/Ulrich>


[MCruz] I agree this c=
ould be a way for the reporting node to know that an agent is not acting on=
 behalf of a client


 <=
/p>

Best regards<=
/o:p>


Ulrich<=
/p>

 <=
/p>

 <=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Maria Cruz Bartolome

Sent: Thursday, March 06, 2014 9:00 AM

To: dime@ietf.org

Subject: Re: [Dime] Issue#35 conclusion






 


 <=
/p>

 


Dear all,


 <=
/p>

This mail thread started =
proposing new OLR reports to request reduction for one specific client.



However, the discussion c=
larified that as it is the draft today,
Host-report is sent from a reporting node towards the client from wh=
ere it receives the request. Then, reduction is requested per client in all=
 cases already.



There is one special case=
 here, when the agent is acting on behalf of the client (i.e. for a non-sup=
porting client or for an agent SFE with topology hiding).
 In this case, the reporting node sends host-report to agent. Here we have =
two options:


 <=
/p>

a)     
We expect the agent t=
o apply the host-report received in an answer to specifically the client th=
at sent the corresponding request


This requires some=
 extra complexity at agent side.


But here we have o=
ne more option: allow the reporting node to choose whether it prefers to ap=
ply this host-report to “all-client” vs “one-client”=
;. That
 increases again the complexity (at reporting node, protocol-wise, and at a=
gent).


 =



b)     
We expect the agent t=
o apply this host-report to
any client that is sending a request towards this agent


In my opinion, thi=
s is the best approach, it reduces complexity and increases robustness.



 <=
/p>

Therefore, I will be in f=
avor of option b), which does not require any changes to the actual draft.<=
/span>


 <=
/p>

Let me know your opinions=
.


Best regards<=
/o:p>


/MCruz<=
/p>

 <=
/p>

 















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C969DDEMUMBX014nsnin_--


From nobody Fri Mar 21 06:17: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 AD1441A096E for ; Fri, 21 Mar 2014 06:17:40 -0700 (PDT)
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 EezwxY9X0rUm for ; Fri, 21 Mar 2014 06:17:36 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 115A01A06A5 for ; Fri, 21 Mar 2014 06:17:36 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51339 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQzK7-0005E4-F1; Fri, 21 Mar 2014 06:17:25 -0700
Message-ID: <532C3BE3.9080108@usdonovans.com>
Date: Fri, 21 Mar 2014 08:17:23 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <087A34937E64E74E848732CFF8354B920978A014@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5A68@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A1E3@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D9000668151B5CA8@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920978A921@ESESSMB101.ericsson.se> <5328ADAA.40503@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C8204@DEMUMBX014.nsn-intra.net> <5329D966.5000800@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C94B9@DEMUMBX014.nsn-intra.net> <532AED36.8070802@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C969D@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151C969D@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090908060504040908030509"
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/R24n0vcI0YWlmz4KpcvC47PIaHA
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: Fri, 21 Mar 2014 13:17:41 -0000

This is a multi-part message in MIME format.
--------------090908060504040908030509
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

I am communicating the consensus in the room at the DIME meeting in
London.  The consensus was that this issue should be dealt with in an
extension.

Regards,

Steve


On 3/21/14 3:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> while I understand and agree that we should not delay the base DOIC
> specification, I do not understand why "stop thinking" is the way to
> achieve this.
>
>  
>
> Is it that you don't want to spend time on identified issues (if so,
> which issues?), or that you don't want to spend time on the proposal?
>
> I still don't know what the issues with this proposal are.
>
> On the other hand I have indicated what the issue is when addressing
> client specific throttling with an extension: Clients which are not
> aware of the extension are still clients and therefore support client
> specific throttling but do not indicate so to reporting nodes which
> (when supporting the extension) cannot make use of client specific
> throttling although supported by both reacting and reporting nodes.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Thursday, March 20, 2014 2:29 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] Issue#35 conclusion
>
>  
>
> Ulrich,
>
> The reason for this being an extension is so that we do not delay the
> base DOIC specification spending time thinking through those issues. 
> The same argument has been made about the agent overload extension.
>
> Let's focus on getting the base specification done, then we can
> address this and other extensions that are considered important.
>
> Steve
>
> On 3/20/14 2:45 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     please be more specific.
>
>     What are the issues?
>
>      
>
>     If there are issues, they need to be solved anyway, no matter
>     whether we chose for a separate extension or not.
>
>      
>
>     Ulrich
>
>      
>
>     *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Wednesday, March 19, 2014 6:53 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>     
>     *Subject:* Re: [Dime] Issue#35 conclusion
>
>      
>
>     Ulrich,
>
>     I'm concerned there are issues with agents, and potentially
>     reporting nodes, that would lurk behind this proposal.  I think it
>     is best to leave this to a separate enhancement to be sure that
>     those issues are properly vetted.
>
>     Regards,
>
>     Steve
>
>     On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Steve, all,
>
>          
>
>         one proposal to solve the issue was to let clients indicate in
>         OC-Supported-Features that they support client specific
>         throttling (while agents taking the role of the reacting node
>         on behalf of multiple clients would not indicate such support).
>
>          
>
>         This could certainly be done by a separate extension to the
>         DOIC specification, but, given that clients allways support 
>         client specific throttling, clients not aware of the extension
>         would not indicate so in OC-Supported Features which is realy
>         a pitty.
>
>          
>
>         Therefore I would like to ask people considering taking this
>         small enhancement on board:
>
>          
>
>         Clients allways indicate support of client specific throttling;
>
>         Agents (taking the role of  a reacting node on behalf of
>         multiple clients) never indicate support of client specific
>         throttling;
>
>         Reporting nodes may make use of this indication and request
>         client specific throttling only when the reacting node
>         indicated support.
>
>          
>
>         Best regards
>
>         Ulrich
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>         Steve Donovan
>         *Sent:* Tuesday, March 18, 2014 9:34 PM
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Issue#35 conclusion
>
>          
>
>         All,
>
>         As Maria Cruz indicates, the tentative conclusion in the DIME
>         working group meeting in London was that this requirement be
>         addressed in a separate extension to the DOIC specification.
>
>         As a result, I propose that we close this issue indicating
>         that no changes will be made to the DOIC specification, with
>         the statement that it needs to be addressed in an extension.
>
>         Regards,
>
>         Steve
>
>         On 3/7/14 10:30 AM, Maria Cruz Bartolome wrote:
>
>             Dear Ulrich,
>
>              
>
>             See comments below please.
>
>             Anyway, since during IETF meeting it was commented that
>             this could be considered as an extension, not sure how
>             this should be managed from now on. I presume we should
>             confirm that in this list.
>
>              
>
>             Best regards
>
>             /MCruz
>
>              
>
>             *From:*Wiehe, Ulrich (NSN - DE/Munich)
>             [mailto:ulrich.wiehe@nsn.com]
>             *Sent:* jueves, 06 de marzo de 2014 10:12
>             *To:* Maria Cruz Bartolome; dime@ietf.org
>             
>             *Subject:* RE: [Dime] Issue#35 conclusion
>
>              
>
>             Dear MCruz,
>
>              
>
>             for my clarification:
>
>             what you say about Host reports is also true for
>             Realm-Routed-Request reports. Can you please confirm.
>
>             [MCruz] I think this case is different. If we agree that
>             realm reports are only generated by agents (as an
>             aggregated report based on host reports and potentially
>             another implementation dependent criteria), then the
>             server itself does not require a traffic-to-realm
>             reduction, on the contrary, the host only requests a
>             traffic-to-host reduction. Agent may or not (I think this
>             is up in the draft) to  forward back to the original
>             client this host-report. Then, not sure if we really need
>             something else here.
>
>              I don't know whether it is still relevant, but I
>             would have thought that the agent that generates a
>             realm-routed-request report, when taking the host reports
>             received from servers into accout for the aggregation, may
>             e.g. detect that all the severs request reduction of
>             traffic from the same a specific client. Would it not be
>             logical that the aggregated realm-routed-request report in
>             this case also only requests reduction from that client
>             (with the aggregated percentage)? 
>
>             [MCruz] This could be something to be considered and could
>             provide some added value, but it is up to interpretation
>             whether this is required.
>
>              
>
>             Proposal b) does not address the 3GPP requirement from TR
>             29.809 clause 6.4.7.  please confirm.
>
>             [MCruz] It does address the 3GPP requirement in general,
>             but not for one specific case:  "There is one special case
>             here, when the agent is acting on behalf of the client
>             (i.e. for a non-supporting client or for an agent SFE with
>             topology hiding)".
>
>              I'm not sure, see below
>
>              
>
>             Also proposal b)  impacts the reporting node which must
>             not send client specific OLRs (with separate sequence
>             number streams for different clients)
>
>             [MCruz] I do not think so. In the case I mentioned, when
>             the agent is acting on behalf of the client, it is always
>             the receiver of the answers (i.e. from a host perspective,
>             the client is the agent
>
>             This is not correct. The host (reporting node)
>             does not know whether the reacting node is the client
>             (identified by orig-host in the request) or an agent
>             (acting on behalf of the client and possibly also on
>             behalf of other clients); the reporting node receives a
>             request that contains an OC-Supported-Features AVP; this
>             indicates to the reporting node that there is a downstream
>             node supporting DOIC. Let me give an example:
>
>             Two non-supporting clients C1 and C2 send requests via the
>             same supporting agent A to the server. Traffic from C1
>             increases, so S requests a 10% throttling from C1
>             (sequence number 1). As the agent A is acting on behalf of
>             C1, A will do the throttling. As a not wanted but
>             acceptable side effect A will also throttle traffic sent
>             from C2 to S. Now the situation improves and S only
>             requests a 5% reduction from C1 (sequence number 2).
>              Again A will apply the 5% throttling also for traffic
>             from C2, which again is not nice but acceptable. Now
>              Traffic from C2 increases (although throttled with 5%)
>             and S request a 50% throttling from C2 (sequence number
>             1). 
>
>             , and then there are not separate sequence number streams).
>
>             [MCruz] I think your example is right, and it highlights
>             something important I haven't realized. Since the server
>             may send totally different reduction requests to different
>             clients, as in your example, the key point is not even
>             that they carry different sequence numbers, but that
>             reduction to apply to "all" clients will oscillate a lot,
>             depending on server requests towards one specific client.
>             Then, a way to solve this is that the server knows whether
>             or not an agent is acting on behalf of the final client.
>             If so, reporting node should not request reductions per
>             client (i.e. %reduction will be the same for any client).
>
>              
>
>             Also, shouldn't b) read:
>
>             We expect the agent to apply this host type /
>             realm-routed-request type report to any
>             *non-DOIC-supporting* client that is sending requests
>             towards this host/realm.
>
>             [MCruz] Yes, any non-DOIC-supporting client.
>
>              
>
>             Also, you say:
>
>             b) does not require any changes to the actual draft
>
>              
>
>             I guess at least some clarification is required as some
>             (Lionel, Nirav, but not Steve)  think it is "natural" and
>             "implicit" that agents would do the per client behaviour
>             as a default.
>
>             [MCruz] Agreed, at least clarification is required.
>
>              
>
>             An alternative proposal that addresses the complexity
>             argument for agents but at the same time at least partly
>             addresses the 3GPP requirement would be to make use of a
>             feature flag: clients allways set the flag, agents do not
>             set the flag, reporting nodes may send client specific
>             OLRs when the flag in the request was set. This has no big
>             impact to clients (only always set the feature flag), no
>             impacts to agents, and allows (if so desired) reporting
>             nodes to make use of the client specific throttling (at
>             least in some cases).
>
>             any comments?
>
>             [MCruz] I agree this could be a way for the reporting node
>             to know that an agent is not acting on behalf of a client
>
>              
>
>             Best regards
>
>             Ulrich
>
>              
>
>              
>
>              
>
>             *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>             *ext Maria Cruz Bartolome
>             *Sent:* Thursday, March 06, 2014 9:00 AM
>             *To:* dime@ietf.org 
>             *Subject:* Re: [Dime] Issue#35 conclusion
>
>              
>
>              
>
>              
>
>             Dear all,
>
>              
>
>             This mail thread started proposing new OLR reports to
>             request reduction for one specific client.
>
>             However, the discussion clarified that as it is the draft
>             today, *Host*-report is sent from a reporting node towards
>             the client from where it receives the request. Then,
>             reduction is requested per client in all cases already.
>
>             There is one special case here, when the agent is acting
>             on behalf of the client (i.e. for a non-supporting client
>             or for an agent SFE with topology hiding). In this case,
>             the reporting node sends host-report to agent. Here we
>             have two options:
>
>              
>
>             a)      *We expect the agent to apply the host-report
>             received in an answer to specifically the client that sent
>             the corresponding request*
>
>             This requires some extra complexity at agent side.
>
>             But here we have one more option: allow the reporting node
>             to choose whether it prefers to apply this host-report to
>             "all-client" vs "one-client". That increases again the
>             complexity (at reporting node, protocol-wise, and at agent).
>
>              
>
>             b)      *We expect the agent to apply this host-report to
>             _any_ client that is sending a request towards this agent*
>
>             In my opinion, this is the best approach, it reduces
>             complexity and increases robustness.
>
>              
>
>             Therefore, I will be in favor of option b), which does not
>             require any changes to the actual draft.
>
>              
>
>             Let me know your opinions.
>
>             Best regards
>
>             /MCruz
>
>              
>
>              
>
>
>
>
>
>
>             _______________________________________________
>
>             DiME mailing list
>
>             DiME@ietf.org 
>
>             https://www.ietf.org/mailman/listinfo/dime
>
>          
>
>      
>
>  
>


--------------090908060504040908030509
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I am communicating the consensus in the room at the DIME meeting
      in London.  The consensus was that this issue should be dealt with
      in an extension.

      

      Regards,

      

      Steve

      

      

    
    
On 3/21/14 3:22 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
while I understand and agree that we should not
            delay the base DOIC specification, I do not understand why
            “stop thinking” is the way to achieve this.

        
 

        
Is it that you don’t want to spend time on
            identified issues (if so, which issues?), or that you don’t
            want to spend time on the proposal?

        
I still don’t know what the issues with this
            proposal are.

        
On the other hand I have indicated what the
            issue is when addressing client specific throttling with an
            extension: Clients which are not aware of the extension are
            still clients and therefore support client specific
            throttling but do not indicate so to reporting nodes which
            (when supporting the extension) cannot make use of client
            specific throttling although supported by both reacting and
            reporting nodes.

        
 

        
Ulrich
            

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Thursday, March 20, 2014 2:29 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] Issue#35 conclusion

          

        

        
 

        
Ulrich,

          

          The reason for this being an extension is so that we do not
          delay the base DOIC specification spending time thinking
          through those issues.  The same argument has been made about
          the agent overload extension.

          

          Let's focus on getting the base specification done, then we
          can address this and other extensions that are considered
          important.

          

          Steve

        

          
On 3/20/14 2:45 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve,

          
 

          
please be more specific.

          
What are the issues?

          
 

          
If there are issues, they need to be solved
              anyway, no matter whether we chose for a separate
              extension or not.

          
 

          
Ulrich

          
 

          

            

              
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Sent: Wednesday, March 19, 2014 6:53 PM

                  To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

                  Subject: Re: [Dime] Issue#35 conclusion

            

          

          
 

          
Ulrich,

            

            I'm concerned there are issues with agents, and potentially
            reporting nodes, that would lurk behind this proposal.  I
            think it is best to leave this to a separate enhancement to
            be sure that those issues are properly vetted.

            

            Regards,

            

            Steve

          

            
On 3/19/14 3:35 AM, Wiehe, Ulrich (NSN
              - DE/Munich) wrote:

          

          

            
Steve,
                all,

            
 

            
one proposal to solve the issue was to let
                clients indicate in OC-Supported-Features that they
                support client specific throttling (while agents taking
                the role of the reacting node on behalf of multiple
                clients would not indicate such support).

            
 

            
This could certainly be done by a separate
                extension to the DOIC specification, but, given that
                clients allways support  client specific throttling,
                clients not aware of the extension would not indicate so
                in OC-Supported Features which is realy a pitty.

            
 

            
Therefore I would like to ask people
                considering taking this small enhancement on board:

            
 

            
Clients allways indicate support of client
                specific throttling;

            
Agents (taking the role of  a reacting node
                on behalf of multiple clients) never indicate support of
                client specific throttling;

            
Reporting nodes may make use of this
                indication and request client specific throttling only
                when the reacting node indicated support.

            
 

            
Best regards

            
Ulrich

            
 

            

              

                
From: DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of ext Steve Donovan

                    Sent: Tuesday, March 18, 2014 9:34 PM

                    To: dime@ietf.org

                    Subject: Re: [Dime] Issue#35 conclusion

              

            

            
 

            
All,

              

              As Maria Cruz indicates, the tentative conclusion in the
              DIME working group meeting in London was that this
              requirement be addressed in a separate extension to the
              DOIC specification.

              

              As a result, I propose that we close this issue indicating
              that no changes will be made to the DOIC specification,
              with the statement that it needs to be addressed in an
              extension.

              

              Regards,

              

              Steve

            

              
On 3/7/14 10:30 AM, Maria Cruz
                Bartolome wrote:

            

            

              
Dear
                  Ulrich,

              
 

              
See
                  comments below please.

              
Anyway,
                  since during IETF meeting it was commented that this
                  could be considered as an extension, not sure how this
                  should be managed from now on. I presume we should
                  confirm that in this list.

              
 

              
Best
                  regards

              
/MCruz

              
 

              

                

                  
From:
                      Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
                      

                      Sent: jueves, 06 de marzo de 2014 10:12

                      To: Maria Cruz Bartolome; dime@ietf.org

                      Subject: RE: [Dime] Issue#35 conclusion

                

              

              
 

              
Dear
                  MCruz,

              
 

              
for
                  my clarification:
                

              
what
                  you say about Host reports is also true for
                  Realm-Routed-Request reports. Can you please confirm.

              
[MCruz]
                  I think this case is different. If we agree that realm
                  reports are only generated by agents (as an aggregated
                  report based on host reports and potentially another
                  implementation dependent criteria), then the server
                  itself does not require a traffic-to-realm reduction,
                  on the contrary, the host only requests a
                  traffic-to-host reduction. Agent may or not (I think
                  this is up in the draft) to  forward back to the
                  original client this host-report. Then, not sure if we
                  really need something else here.

              
<Ulrich>
                  I don’t know whether it is still relevant, but I would
                  have thought that the agent that generates a
                  realm-routed-request report, when taking the host
                  reports received from servers into accout for the
                  aggregation, may e.g. detect that all the severs
                  request reduction of traffic from the same a specific
                  client. Would it not be logical that the aggregated
                  realm-routed-request report in this case also only
                  requests reduction from that client (with the
                  aggregated percentage)? </Ulrich>

              
[MCruz]
                  This could be something to be considered and could
                  provide some added value, but it is up to
                  interpretation whether this is required.
                

              
 

              
Proposal
                  b) does not address the 3GPP requirement from TR
                  29.809 clause 6.4.7.  please confirm.

              
[MCruz]
                  It does address the 3GPP requirement in general, but
                  not for one specific case:  “There

                  is one special case here, when the agent is acting on
                  behalf of the client (i.e. for a non-supporting client
                  or for an agent SFE with topology hiding)”.

              
<Ulrich>
                  I’m not sure, see below</Ulrich>
                

              
 

              
Also
                  proposal b)  impacts the reporting node which must not
                  send client specific OLRs (with separate sequence
                  number streams for different clients)

              
[MCruz]
                  I do not think so. In the case I mentioned, when the
                  agent is acting on behalf of the client, it is always
                  the receiver of the answers (i.e. from a host
                  perspective, the client is the agent

              
<Ulrich>This
                  is not correct. The host (reporting node) does not
                  know whether the reacting node is the client
                  (identified by orig-host in the request) or an agent
                  (acting on behalf of the client and possibly also on
                  behalf of other clients); the reporting node receives
                  a request that contains an OC-Supported-Features AVP;
                  this indicates to the reporting node that there is a
                  downstream node supporting DOIC. Let me give an
                  example:

              
Two
                  non-supporting clients C1 and C2 send requests via the
                  same supporting agent A to the server. Traffic from C1
                  increases, so S requests a 10% throttling from C1
                  (sequence number 1). As the agent A is acting on
                  behalf of C1, A will do the throttling. As a not
                  wanted but acceptable side effect A will also throttle
                  traffic sent from C2 to S. Now the situation improves
                  and S only requests a 5% reduction from C1 (sequence
                  number 2).  Again A will apply the 5% throttling also
                  for traffic from C2, which again is not nice but
                  acceptable. Now  Traffic from C2 increases (although
                  throttled with 5%) and S request a 50% throttling from
                  C2 (sequence number 1). </Ulrich>
                

              
,
                  and then there are not separate sequence number
                  streams).

              
[MCruz]
                  I think your example is right, and it highlights
                  something important I haven’t realized. Since the
                  server may send totally different reduction requests
                  to different clients, as in your example, the key
                  point is not even that they carry different sequence
                  numbers, but that reduction to apply to “all” clients
                  will oscillate a lot, depending on server requests
                  towards one specific client. Then, a way to solve this
                  is that the server knows whether or not an agent is
                  acting on behalf of the final client. If so, reporting
                  node should not request reductions per client (i.e.
                  %reduction will be the same for any client).

              
 

              
Also,
                  shouldn’t b) read:

              
We
                  expect the agent to apply this host type /
                  realm-routed-request type report to any
                  non-DOIC-supporting client that is sending
                  requests towards this host/realm.

              
[MCruz]
                  Yes, any non-DOIC-supporting client.

              
 

              
Also,
                  you say:

              
b)
                  does not require any changes to the actual draft

              
 

              
I
                  guess at least some clarification is required as some
                  (Lionel, Nirav, but not Steve)  think it is “natural”
                  and “implicit” that agents would do the per client
                  behaviour as a default. 

              
[MCruz]
                  Agreed, at least clarification is required.

              
 

              
An
                  alternative proposal that addresses the complexity
                  argument for agents but at the same time at least
                  partly addresses the 3GPP requirement would be to make
                  use of a feature flag: clients allways set the flag,
                  agents do not set the flag, reporting nodes may send
                  client specific OLRs when the flag in the request was
                  set. This has no big impact to clients (only always
                  set the feature flag), no impacts to agents, and
                  allows (if so desired) reporting nodes to make use of
                  the client specific throttling (at least in some
                  cases).

              
<Ulrich>any
                  comments?</Ulrich>

              
[MCruz]
                  I agree this could be a way for the reporting node to
                  know that an agent is not acting on behalf of a client

              
 

              
Best
                  regards

              
Ulrich

              
 

              
 

              
 

              

                

                  
From:
                      DiME [mailto:dime-bounces@ietf.org]
                      On Behalf Of ext Maria Cruz Bartolome

                      Sent: Thursday, March 06, 2014 9:00 AM

                      To: dime@ietf.org

                      Subject: Re: [Dime] Issue#35 conclusion

                

              

              
 

              
 

              
 

              
Dear
                  all,

              
 

              
This
                  mail thread started proposing new OLR reports to
                  request reduction for one specific client.
                

              
However,
                  the discussion clarified that as it is the draft
                  today,
                  Host-report is sent from a reporting node
                  towards the client from where it receives the request.
                  Then, reduction is requested per client in all cases
                  already.
                

              
There
                  is one special case here, when the agent is acting on
                  behalf of the client (i.e. for a non-supporting client
                  or for an agent SFE with topology hiding). In this
                  case, the reporting node sends host-report to agent.
                  Here we have two options:

              
 

              
a)     
                  We
                    expect the agent to apply the host-report received
                    in an answer to specifically the client that sent
                    the corresponding request

              
This
                  requires some extra complexity at agent side.

              
But
                  here we have one more option: allow the reporting node
                  to choose whether it prefers to apply this host-report
                  to “all-client” vs “one-client”. That increases again
                  the complexity (at reporting node, protocol-wise, and
                  at agent).

              
 

              
b)     
                  We
                    expect the agent to apply this host-report to
                    any client that is sending a request towards
                    this agent

              
In
                  my opinion, this is the best approach, it reduces
                  complexity and increases robustness.
                

              
 

              
Therefore,
                  I will be in favor of option b), which does not
                  require any changes to the actual draft.

              
 

              
Let
                  me know your opinions.

              
Best
                  regards

              
/MCruz

              
 

              
 

              


                

                

                

                

                

              
_______________________________________________

              
DiME mailing list

              
DiME@ietf.org

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

            

            
 

          

          
 

        

        
 

      

    

    

  


--------------090908060504040908030509--


From nobody Fri Mar 21 06:20: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 027B31A096E for ; Fri, 21 Mar 2014 06:20:03 -0700 (PDT)
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 JOR8WIlYkftf for ; Fri, 21 Mar 2014 06:20:01 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 077E11A03E2 for ; Fri, 21 Mar 2014 06:20:01 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51392 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQzMU-0000JV-CO for dime@ietf.org; Fri, 21 Mar 2014 06:19:51 -0700
Message-ID: <532C3C76.4050200@usdonovans.com>
Date: Fri, 21 Mar 2014 08:19:50 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net> <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com> <530BA310.4090100@usdonovans.com> <8BE5229D-E276-4084-B6EB-DBF89817E02F@nostrum.com> <5327372B.1040600@usdonovans.com>
In-Reply-To: <5327372B.1040600@usdonovans.com>
Content-Type: multipart/alternative; boundary="------------030400090506030305070003"
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/6L8m-8RbTZD_J6s8HhUarO6foO0
Subject: Re: [Dime] Issue#29 proposed 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: Fri, 21 Mar 2014 13:20:03 -0000

This is a multi-part message in MIME format.
--------------030400090506030305070003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Having seen no additional discussion on this I will close the issue with
the suggested text.

Regards,

Steve

On 3/17/14 12:55 PM, Steve Donovan wrote:
> All,
>
> I believe we have consensus on this ticket.
>
> I had put the following into my issue status document:
>
> Agreed -- Removed OC-Sequence-Number from OC-Supported-Features AVP.
>
> Agreed -- The scope of an OC-Supported-Features AVP is a single
> transaction.
>
> Agreed -- Diameter nodes that support DOIC must include the
> OC-Supported-Features AVP in all requests.
>
>
> I believe that this translates into the text changes outlined below. 
> If we have agreement on the text below we can close the issue and I'll
> update the text in the -02 draft accordingly.
>
> Regards,
>
> Steve
>
> -----
>
> Section 4.1:
>
> Remove < OC-Sequence-Number >  from OC-Supported-Features syntax
> description.
>
> Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."
>
> Section 4.4, Paragraph 1:
>
> Remove reference to section 4.1.
>
> Section 5.3.1, Paragraph 1:
>
> Change:
>
> It is RECOMMENDED that the
>    request message initiating endpoint includes the capability
>    announcement into every request regardless it has had prior message
>    exchanges with the give remote endpoint. In a case of a Diameter
>    session maintaining application, sending the OC-Supported-Features
>    AVP in every message is not really necessary after the initial
>    capability announcement or until there is a change in supported
>    features. To: The lifetime of a capability announcement is limited
> to a single transaction. As a result, the reacting node MUST include
> the capability announcement in all request messages.
>
>
>
>
>
>
>
>
> On 2/24/14 5:02 PM, Ben Campbell wrote:
>> On Feb 24, 2014, at 1:52 PM, Steve Donovan  wrote:
>>
>>> I agree.
>>>
>>> I also think that we agreed that the lifetime of the OC-Supported-Features AVP is a single transaction and that the OC-Supported-Features AVP must be included in all requests originated by a Diameter node supporting DOIC.
>> +1, and my previous agreement was based on that assumption.
>>
>>
>>> Steve
>>>
>>> On 2/20/14 4:31 PM, Ben Campbell wrote:
>>>> I concur with removing the sequence number from OC-Supported-Features.
>>>>
>>>>
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------030400090506030305070003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Having seen no additional
      discussion on this I will close the issue with the suggested text.

      

      Regards,

      

      Steve

      

    
    
On 3/17/14 12:55 PM, Steve Donovan
      wrote:

    

    

      
      All,

        

        I believe we have consensus on this ticket.

        

        I had put the following into my issue status document:

      

      
        
      
      
Agreed – Removed OC-Sequence-Number from
        OC-Supported-Features AVP.

      
Agreed – The scope of an
        OC-Supported-Features AVP is a single transaction.

      
Agreed – Diameter nodes that support DOIC
        must include the OC-Supported-Features AVP in all requests.

      
        
        
        
        
        
        
        
        
        
         

        I believe that this translates into the text changes outlined
        below.  If we have agreement on the text below we can close the
        issue and I'll update the text in the -02 draft accordingly.

        

        Regards,

        

        Steve

        

        -----

        

        Section 4.1:

        

        Remove < OC-Sequence-Number >  from OC-Supported-Features
        syntax description.

        

        Remove paragraph 3 that starts "OC-Sequence-Number AVP is
        used..."

        

        Section 4.4, Paragraph 1:

        

        Remove reference to section 4.1.

        

        Section 5.3.1, Paragraph 1:

        

        Change:

      

      
        
      
      
It is RECOMMENDED that the
   request message initiating endpoint includes the capability
   announcement into every request regardless it has had prior message
   exchanges with the give remote endpoint.  In a case of a Diameter
   session maintaining application, sending the OC-Supported-Features
   AVP in every message is not really necessary after the initial
   capability announcement or until there is a change in supported
   features.

To:

The lifetime of a capability announcement is limited to a single transaction.  As a result, the reacting 
node MUST include the capability announcement in all request messages.




      

        

        

        

        

      

        

      

      
On 2/24/14 5:02 PM, Ben Campbell
        wrote:

      

      

        
On Feb 24, 2014, at 1:52 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



        

          
I agree.

I also think that we agreed that the lifetime of the OC-Supported-Features AVP is a single transaction and that the OC-Supported-Features AVP must be included in all requests originated by a Diameter node supporting DOIC.


        

        
+1, and my previous agreement was based on that assumption.




        

          
Steve

On 2/20/14 4:31 PM, Ben Campbell wrote:


          

            
I concur with removing the sequence number from OC-Supported-Features.




          

        

        

      

      

      

      

      

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


    

    

  


--------------030400090506030305070003--


From nobody Fri Mar 21 06:21:18 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 F22D21A074A for ; Fri, 21 Mar 2014 06:21:16 -0700 (PDT)
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 Ri0fVuD-cEiI for ; Fri, 21 Mar 2014 06:21:15 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 38AC71A03E2 for ; Fri, 21 Mar 2014 06:21:15 -0700 (PDT)
Received: from localhost ([127.0.0.1]:51167 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WQzNc-0007I5-SX; Fri, 21 Mar 2014 14:21:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Fri, 21 Mar 2014 13:21:00 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/27#comment:1
Message-ID: <081.4c825644f7aa6684a8771641ae43bac5@trac.tools.ietf.org>
References: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org>
X-Trac-Ticket-ID: 27
In-Reply-To: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mvuxCPj4WD278qQoo51JFlpEtrw
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #27 (draft-docdt-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC
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: Fri, 21 Mar 2014 13:21:17 -0000

#27: Behavior of agent acting on behalf of Client that does not support DOIC

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 I believe we have consensus on this ticket.

 I had put the following into my issue status document:

 Agreed – Removed OC-Sequence-Number from OC-Supported-Features AVP.

 Agreed – The scope of an OC-Supported-Features AVP is a single
 transaction.

 Agreed – Diameter nodes that support DOIC must include the OC-Supported-
 Features AVP in all requests.

 I believe that this translates into the text changes outlined below.  If
 we have agreement on the text below we can close the issue and I'll update
 the text in the -02 draft accordingly.

 Regards,

 Steve

 -----

 Section 4.1:

 Remove < OC-Sequence-Number >  from OC-Supported-Features syntax
 description.

 Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."

 Section 4.4, Paragraph 1:

 Remove reference to section 4.1.

 Section 5.3.1, Paragraph 1:

 Change:

 It is RECOMMENDED that the
    request message initiating endpoint includes the capability
    announcement into every request regardless it has had prior message
    exchanges with the give remote endpoint. In a case of a Diameter
    session maintaining application, sending the OC-Supported-Features
    AVP in every message is not really necessary after the initial
    capability announcement or until there is a change in supported
    features. To: The lifetime of a capability announcement is limited to a
 single transaction. As a result, the reacting node MUST include the
 capability announcement in all request messages.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  closed
 Priority:  critical                 |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:
 Severity:  Submitted WG Document    |  Resolution:  fixed
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Fri Mar 21 06:24:55 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 5F6951A06A5 for ; Fri, 21 Mar 2014 06:24:54 -0700 (PDT)
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 X79vzmZdir5s for ; Fri, 21 Mar 2014 06:24:52 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 767AD1A03E2 for ; Fri, 21 Mar 2014 06:24:52 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51412 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQzRB-0007Gd-IP for dime@ietf.org; Fri, 21 Mar 2014 06:24:42 -0700
Message-ID: <532C3D99.30809@usdonovans.com>
Date: Fri, 21 Mar 2014 08:24:41 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com>
In-Reply-To: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com>
Content-Type: multipart/alternative; boundary="------------060906030208040904020807"
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/0Oxe9ZoHIM6ztLhpR5gmkRIRsVM
Subject: Re: [Dime] DOIC Overview of Operation
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: Fri, 21 Mar 2014 13:24:54 -0000

This is a multi-part message in MIME format.
--------------060906030208040904020807
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I propose that we close issue 41 with Ben's text into section 3.0.  I
also propose that we open a new issue to capture the need to make the
rest of section 3 consistent.

I will do so unless I hear an alternative suggestion soon.

Regards,

Steve

On 3/17/14 1:34 PM, Ben Campbell wrote:
> Hi,
>
> the dime-ovli currently lacks any sort of high-level overview of operation. As written, it jumps into details without giving the reader a high-level view of how it works. I think that will create confusion for new readers that have not been involved in discussions so far.
>
> I propose adding the following text to the beginning of section 3. This would be entirely non-normative. I recognize that this would create some redundancies with later subsections. I don't address those here, but we would need to do so when integrating this text if we agree to add it.
>
> Thanks!
>
> Ben.
>
> --------------------------
>
>    The Diameter Overload Information Conveyance (DOIC) mechanism allows
>    Diameter nodes to request other nodes to perform overload abatement
>    actions, that is, actions to reduce the load offered to the
>    overloaded node.
>
>    A Diameter node that supports DOIC is known as a "DOIC endpoint".
>    Any Diameter node can act as a DOIC endpoint, including clients,
>    servers, and agents.  DOIC endpoints are further divided into
>    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
>    overload abatement by sending an Overload Report (OLR) to one or more
>    reacting nodes.
>
>    A reacting node consumes OLRs, and performs whatever actions are
>    needed to fulfill the requests.  A Reporting node may report overload
>    on its own behalf, or on behalf of other (typically upstream) nodes.
>    Likewise, a reacting node may perform overload abatement on its own
>    behalf, or on behalf of other (typically downstream) nodes.
>
>    A node's role as a DOIC endpoint is independent of its Diameter role.
>    For example, Diameter relay and proxy agents may act as DOIC
>    endpoints, even though they are not endpoints in the Diameter sense.
>    Since Diameter enables bi-directional applications, where Diameter
>    servers can send requests towards Diameter clients, a given Diameter
>    node can simultaneously act as a reporting node and reacting node.
>
>    Likewise, an relay or proxy agent may act as a reacting node from the
>    perspective of upstream nodes, and a reporting node from the
>    perspective of downstream nodes.
>
>    DOIC endpoints do not generate new messages to carry DOIC related
>    information.  Rather, they "piggyback" DOIC information over existing
>    Diameter messages by inserting new AVPs into existing Diameter
>    requests and responses.  Nodes indicate support for DOIC, and any
>    needed DOIC parameters by inserting an OC_Supported_Features AVP
>    (Section 4.1) into existing requests and responses.  Reporting nodes
>    send OLRs by inserting OC-OLR AVPs.  (Section 4.3)
>
>    A given OLR applies to the Diameter realm and application of the
>    Diameter message that carries it.  If a reporting node supports more
>    than one realm and/or application, it reports independently for each
>    combination of realm and application.  Similarly, OC-Feature-Vector
>    AVPs apply to the realm and application of the enclosing message.
>    This implies that a node may support DOIC for one application and/or
>    realm, but not another, and may indicate different DOIC parameters
>    for each application and realm for which it supports DOIC.
>
>    Reacting nodes perform overload abatement according to an agreed-upon
>    abatement algorithm.  An abatement algorithm defines the meaning of
>    the parameters of an OLR, and the procedures required for overload
>    abatement.  This document specifies a single must-support algorithm,
>    namely the "loss" algorithm [ref?].  Future specifications may
>    introduce new algorithms.
>
>    Overload conditions may vary in scope.  For example, a single
>    Diameter node may be overloaded, in which case reacting nodes may
>    reasonably attempt to send throttled requests to other destinations
>    or via other agents.  On the other hand, an entire Diameter realm may
>    be overloaded, in which case such attempts would do harm.  DOIC OLRs
>    have a concept of "report type" (Section 4.6), where the type defines
>    such behaviors.  Report types are extensible.  This document defines
>    report types for overload of a specific server, and for overload of
>    an entire realm.
>
>    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
>    that are "adjacent" for DOIC purposes may not be adjacent from a
>    Diameter, or transport, perspective.  For example, one or more
>    Diameter agents that do not support DOIC may exist between a given
>    pair of reporting and reacting nodes, as long as those agents pass
>    unknown AVPs through unmolested.  The report types described in this
>    document can safely pass through non-supporting agents.  This may not
>    be true for report types defined in future specifications.  Documents
>    that introduce new report types MUST describe any limitations on
>    their use across non-supporting agents.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------060906030208040904020807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I propose that we close
      issue 41 with Ben's text into section 3.0.  I also propose that we
      open a new issue to capture the need to make the rest of section 3
      consistent.

      

      I will do so unless I hear an alternative suggestion soon.

      

      Regards,

      

      Steve

      

    
    
On 3/17/14 1:34 PM, Ben Campbell wrote:

    

    

      
Hi,

the dime-ovli currently lacks any sort of high-level overview of operation. As written, it jumps into details without giving the reader a high-level view of how it works. I think that will create confusion for new readers that have not been involved in discussions so far.

I propose adding the following text to the beginning of section 3. This would be entirely non-normative. I recognize that this would create some redundancies with later subsections. I don't address those here, but we would need to do so when integrating this text if we agree to add it.

Thanks!

Ben.

--------------------------

   The Diameter Overload Information Conveyance (DOIC) mechanism allows
   Diameter nodes to request other nodes to perform overload abatement
   actions, that is, actions to reduce the load offered to the
   overloaded node.

   A Diameter node that supports DOIC is known as a "DOIC endpoint".
   Any Diameter node can act as a DOIC endpoint, including clients,
   servers, and agents.  DOIC endpoints are further divided into
   "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
   overload abatement by sending an Overload Report (OLR) to one or more
   reacting nodes.

   A reacting node consumes OLRs, and performs whatever actions are
   needed to fulfill the requests.  A Reporting node may report overload
   on its own behalf, or on behalf of other (typically upstream) nodes.
   Likewise, a reacting node may perform overload abatement on its own
   behalf, or on behalf of other (typically downstream) nodes.

   A node's role as a DOIC endpoint is independent of its Diameter role.
   For example, Diameter relay and proxy agents may act as DOIC
   endpoints, even though they are not endpoints in the Diameter sense.
   Since Diameter enables bi-directional applications, where Diameter
   servers can send requests towards Diameter clients, a given Diameter
   node can simultaneously act as a reporting node and reacting node.

   Likewise, an relay or proxy agent may act as a reacting node from the
   perspective of upstream nodes, and a reporting node from the
   perspective of downstream nodes.

   DOIC endpoints do not generate new messages to carry DOIC related
   information.  Rather, they "piggyback" DOIC information over existing
   Diameter messages by inserting new AVPs into existing Diameter
   requests and responses.  Nodes indicate support for DOIC, and any
   needed DOIC parameters by inserting an OC_Supported_Features AVP
   (Section 4.1) into existing requests and responses.  Reporting nodes
   send OLRs by inserting OC-OLR AVPs.  (Section 4.3)

   A given OLR applies to the Diameter realm and application of the
   Diameter message that carries it.  If a reporting node supports more
   than one realm and/or application, it reports independently for each
   combination of realm and application.  Similarly, OC-Feature-Vector
   AVPs apply to the realm and application of the enclosing message.
   This implies that a node may support DOIC for one application and/or
   realm, but not another, and may indicate different DOIC parameters
   for each application and realm for which it supports DOIC.

   Reacting nodes perform overload abatement according to an agreed-upon
   abatement algorithm.  An abatement algorithm defines the meaning of
   the parameters of an OLR, and the procedures required for overload
   abatement.  This document specifies a single must-support algorithm,
   namely the "loss" algorithm [ref?].  Future specifications may
   introduce new algorithms.

   Overload conditions may vary in scope.  For example, a single
   Diameter node may be overloaded, in which case reacting nodes may
   reasonably attempt to send throttled requests to other destinations
   or via other agents.  On the other hand, an entire Diameter realm may
   be overloaded, in which case such attempts would do harm.  DOIC OLRs
   have a concept of "report type" (Section 4.6), where the type defines
   such behaviors.  Report types are extensible.  This document defines
   report types for overload of a specific server, and for overload of
   an entire realm.

   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unmolested.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.  Documents
   that introduce new report types MUST describe any limitations on
   their use across non-supporting agents.

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



    

    

  


--------------060906030208040904020807--


From nobody Fri Mar 21 06:27:18 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 803CC1A0970 for ; Fri, 21 Mar 2014 06:27:17 -0700 (PDT)
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 Kf3ylq8IFLD0 for ; Fri, 21 Mar 2014 06:27:14 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBD71A03E2 for ; Fri, 21 Mar 2014 06:27:14 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2LDR1cv000480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Mar 2014 08:27:03 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2LDR0k1026454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 14:27:00 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 21 Mar 2014 14:27:00 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#29 proposed conclusion
Thread-Index: AQHPQgot3XtrIF/JAkC849Kre38mZ5rre6EAgAARfMA=
Date: Fri, 21 Mar 2014 13:26:59 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3B73@DEMUMBX014.nsn-intra.net> <32C8E469-48AE-4336-AF92-F6EB2B12EDA4@nostrum.com> <530BA310.4090100@usdonovans.com> <8BE5229D-E276-4084-B6EB-DBF89817E02F@nostrum.com> <5327372B.1040600@usdonovans.com> <532C3C76.4050200@usdonovans.com>
In-Reply-To: <532C3C76.4050200@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.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202671A3CFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/N4I9_dpA85wrw8ww-xzEKvdiGe4
Subject: Re: [Dime] Issue#29 proposed 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: Fri, 21 Mar 2014 13:27:18 -0000

--_000_E194C2E18676714DACA9C3A2516265D202671A3CFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Steve

I agree on the proposal

Best regards

JJacques





De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : vendredi 21 mars 2014 14:20
=C0 : dime@ietf.org
Objet : Re: [Dime] Issue#29 proposed conclusion

Having seen no additional discussion on this I will close the issue with th=
e suggested text.

Regards,

Steve
On 3/17/14 12:55 PM, Steve Donovan wrote:
All,

I believe we have consensus on this ticket.

I had put the following into my issue status document:


Agreed - Removed OC-Sequence-Number from OC-Supported-Features AVP.
Agreed - The scope of an OC-Supported-Features AVP is a single transaction.
Agreed - Diameter nodes that support DOIC must include the OC-Supported-Fea=
tures AVP in all requests.

I believe that this translates into the text changes outlined below.  If we=
 have agreement on the text below we can close the issue and I'll update th=
e text in the -02 draft accordingly.

Regards,

Steve

-----

Section 4.1:

Remove < OC-Sequence-Number >  from OC-Supported-Features syntax descriptio=
n.

Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."

Section 4.4, Paragraph 1:

Remove reference to section 4.1.

Section 5.3.1, Paragraph 1:

Change:

It is RECOMMENDED that the

   request message initiating endpoint includes the capability

   announcement into every request regardless it has had prior message

   exchanges with the give remote endpoint.  In a case of a Diameter

   session maintaining application, sending the OC-Supported-Features

   AVP in every message is not really necessary after the initial

   capability announcement or until there is a change in supported

   features.



To:



The lifetime of a capability announcement is limited to a single transactio=
n.  As a result, the reacting

node MUST include the capability announcement in all request messages.











On 2/24/14 5:02 PM, Ben Campbell wrote:

On Feb 24, 2014, at 1:52 PM, Steve Donovan  wrote:



I agree.



I also think that we agreed that the lifetime of the OC-Supported-Features =
AVP is a single transaction and that the OC-Supported-Features AVP must be =
included in all requests originated by a Diameter node supporting DOIC.

+1, and my previous agreement was based on that assumption.





Steve



On 2/20/14 4:31 PM, Ben Campbell wrote:

I concur with removing the sequence number from OC-Supported-Features.











_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_E194C2E18676714DACA9C3A2516265D202671A3CFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











=
 


Hi St=
eve


=
 


I agr=
ee on the proposal



=
 


Best =
regards


=
 


JJacq=
ues 


 =
;


=
 


=
 


=
 


=
 






De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : vendredi 21 mars 2014 14:20

=C0 : dime@ietf.org

Objet : Re: [Dime] Issue#29 proposed conclusion






 


Having seen no additi=
onal discussion on this I will close the issue with the suggested text.



Regards,



Steve




On 3/17/14 12:55 PM, Steve Donovan wrote:=







All,



I believe we have consensus on this ticket.



I had put the following into my issue status document:








Agreed – Removed OC-Sequence-Number from OC-Supported-Featur=
es AVP.


Agreed – The scope of an OC-Supported-Features AVP is a sing=
le transaction.


Agreed – Diameter nodes that support DOIC must include the O=
C-Supported-Features AVP in all requests.




I believe that this translates into the text changes outlined below.  =
If we have agreement on the text below we can close the issue and I'll upda=
te the text in the -02 draft accordingly.



Regards,



Steve



-----



Section 4.1:



Remove < OC-Sequence-Number >  from OC-Supported-Features syntax=
 description.



Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."=
;



Section 4.4, Paragraph 1:



Remove reference to section 4.1.



Section 5.3.1, Paragraph 1:



Change:




It is RECOMMENDED that the






   request message initiating endpoint includes the cap=
ability






   announcement into every request regardless it has ha=
d prior message






   exchanges with the give remote endpoint.  In a =
case of a Diameter






   session maintaining application, sending the OC-Supp=
orted-Features






   AVP in every message is not really necessary after t=
he initial






   capability announcement or until there is a change i=
n supported






   features.


 


To:


 


The lifetime of a capability announcement is limited to a single trans=
action.  As a result, the reacting 


node MUST include the capability announcement in all request messages.=



 


 























On 2/24/14 5:02 PM, Ben Campbell wrote:






On Feb 24, 2014, at 1:52 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

 




I agree.


 


I also think that we agreed that the lifetime of the OC-Supported-Feat=
ures AVP is a single transaction and that the OC-Supported-Features AVP mus=
t be included in all requests originated by a Diameter node supporting DOIC=
.




+1, and my previous agreement was based on that assumption.


 


 




Steve


 


On 2/20/14 4:31 PM, Ben Campbell wrote:




I concur with removing the sequence number from OC-Supported-Features.=



 


 






 















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_E194C2E18676714DACA9C3A2516265D202671A3CFR712WXCHMBA12z_--


From nobody Fri Mar 21 06:30: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 1F0F11A0970 for ; Fri, 21 Mar 2014 06:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 vgeJZRapFpJT for ; Fri, 21 Mar 2014 06:29:59 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 437D01A08C0 for ; Fri, 21 Mar 2014 06:29:59 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51424 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQzW9-0005xb-Cq for dime@ietf.org; Fri, 21 Mar 2014 06:29:49 -0700
Message-ID: <532C3ECD.8070200@usdonovans.com>
Date: Fri, 21 Mar 2014 08:29:49 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------020305030008020002090809"
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/fr4SAh_jE197aKFZeUM7XFB7sb4
Subject: [Dime] Plan for -02 version of the draft
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: Fri, 21 Mar 2014 13:30:00 -0000

This is a multi-part message in MIME format.
--------------020305030008020002090809
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

My goal is to have the -02 version of the draft submitted before the end
of next week.  This will allow discussion of the new version at the 3GPP
CT4 meeting happening the following week.

Based on the process discussed in the London DIME meeting, I will only
be making changes that have proposed text in a closed issue.  As such,
if you have open issues, please push them to a closed state if you want
the resolution in the -02 version.

Issues not resolved for the -02 draft can still be put into a subsequent
version of the document. 

Regards,

Steve

--------------020305030008020002090809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      My goal is to have the -02 version of the draft submitted before
      the end of next week.  This will allow discussion of the new
      version at the 3GPP CT4 meeting happening the following week.

      

      Based on the process discussed in the London DIME meeting, I will
      only be making changes that have proposed text in a closed issue. 
      As such, if you have open issues, please push them to a closed
      state if you want the resolution in the -02 version.

      

      Issues not resolved for the -02 draft can still be put into a
      subsequent version of the document.  

      

      Regards,

      

      Steve

    
  


--------------020305030008020002090809--


From nobody Fri Mar 21 06:31:46 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 CEFB81A0545 for ; Fri, 21 Mar 2014 06:31:44 -0700 (PDT)
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 BJozlBMdGmHE for ; Fri, 21 Mar 2014 06:31:43 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 872BF1A03E2 for ; Fri, 21 Mar 2014 06:31:43 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51425 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQzXi-0008Q9-KX; Fri, 21 Mar 2014 06:31:27 -0700
Message-ID: <532C3F2E.7020703@usdonovans.com>
Date: Fri, 21 Mar 2014 08:31:26 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ben Campbell 
References: <53274706.70201@usdonovans.com> <47CE5611-2743-45AA-94A5-2D4BCF33EFF2@nostrum.com>
In-Reply-To: <47CE5611-2743-45AA-94A5-2D4BCF33EFF2@nostrum.com>
Content-Type: multipart/alternative; boundary="------------070901060001060603030205"
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/gp4k-vfxHDyU11neZsnIYZezKE0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] Issue #30
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: Fri, 21 Mar 2014 13:31:45 -0000

This is a multi-part message in MIME format.
--------------070901060001060603030205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Having seen no further discussion on this issue, I will close it with
the agreed to text based on Ben's suggested change below.

Regards,

Steve

On 3/18/14 9:14 AM, Ben Campbell wrote:
> +1, with a minor suggested edit:
>
> On Mar 17, 2014, at 2:03 PM, Steve Donovan  wrote:
>
>> Change:
>>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>>    applies the traffic abatement based on the commonly supported
>>    algorithm with the reporting node and the current overload condition.
>>    The reacting node learns the reporting node supported abatement
>>    algorithms directly from the received answer message containing the
>>    OC-Supported-Features AVP or indirectly remembering the previously
>>    used traffic abatement algorithm with the given reporting node.
>> To: (removing the last portion of the last sentence)
>>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>>    applies the traffic abatement based on the commonly supported
> s/"commonly supported"/selected
>
> "Commonly supported" is no longer descriptive. There may be several commonly supported algorithm, but the reporting node selects just one.
>
>>    algorithm with the reporting node and the current overload condition.
>>    The reacting node learns the reporting node supported abatement
>>    algorithms directly from the received answer message containing the
>>    OC-Supported-Features AVP.
>>
>


--------------070901060001060603030205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Having seen no further
      discussion on this issue, I will close it with the agreed to text
      based on Ben's suggested change below.

      

      Regards,

      

      Steve

      

    
    
On 3/18/14 9:14 AM, Ben Campbell wrote:

    

    

      
+1, with a minor suggested edit:

On Mar 17, 2014, at 2:03 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
Change:
   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP or indirectly remembering the previously
   used traffic abatement algorithm with the given reporting node.


      

      

      

        
To: (removing the last portion of the last sentence)
   Once a reacting node receives an OC-OLR AVP from a reporting node, it
   applies the traffic abatement based on the commonly supported


      

      
s/"commonly supported"/selected

"Commonly supported" is no longer descriptive. There may be several commonly supported algorithm, but the reporting node selects just one.



      

        
   algorithm with the reporting node and the current overload condition.
   The reacting node learns the reporting node supported abatement
   algorithms directly from the received answer message containing the
   OC-Supported-Features AVP.



      

      



    

    

  


--------------070901060001060603030205--


From nobody Fri Mar 21 06:33: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 D06821A03E2 for ; Fri, 21 Mar 2014 06:33:24 -0700 (PDT)
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 bjpx0tyc4-a7 for ; Fri, 21 Mar 2014 06:33:22 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1DB1A072D for ; Fri, 21 Mar 2014 06:33:21 -0700 (PDT)
Received: from localhost ([127.0.0.1]:51652 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WQzZB-0005vJ-Br; Fri, 21 Mar 2014 14:33:04 +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: srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Fri, 21 Mar 2014 13:32:57 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/30#comment:1
Message-ID: <081.d67cf98bf010626435cad725cb5095f0@trac.tools.ietf.org>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org>
X-Trac-Ticket-ID: 30
In-Reply-To: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: srdonovan@usdonovans.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/g1ndOrwDLJHhyTcKK_B84SggDAQ
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages
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: Fri, 21 Mar 2014 13:33:25 -0000

#30: OC-Supported-Features AVP in answer messages

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 We reached the tentative agreement in the DIME meeting on the following:

 OC-Supported-Features handling:

 Agreed: OC-Supported-Features AVP MUST be included in all answer messages
 (we had already agreed that it must be included in all request messages).
 Agreed: Reacting node advertises all supported algorithms;
 Agreed: Reporting node responds with the single algorithm it will be
 using;
 Agreed: Handling of other feature bits is defined in the extension drafts

 Based on this I believe we need the text changes outlined below.

 Let me know if I have missed any.

 If we agree on the text changes then we can close the issue and I'll
 update the document accordingly.

 Regards,

 Steve

 -----

 Section 5.3.2, paragraph 1:

 Change:

 The answer message
    initiating endpoint MAY announce as many supported capabilities as it
    has (the announced set is a subject to local policy and
    configuration). However, at least one of the announced capabilities
    MUST be the same as received in the request message.


 To:

 The reporting node MUST include the OC-Supported-Features AVP in all
 response messages for transactions where the request message included the
 OC-Supported-Features AVP.  The reporting node MUST announce support of
 the single algorithm that the reporting node will request the reacting
 node to use to mitigate overload instances.  The reporting node MUST NOT
 change the selected algorithm during a period of time that it is in an
 overload state and, as a result, is sending OC-OLR AVPs in answer
 messages.

     Note: There will always be at least one algorithm supported by both
 the reacting and reporting nodes as all nodes that support DOIC must
 support the loss algorithm defined in this document.

 The handling of feature bits in the OC-Feature-Vector AVP that are not
 associated with overload abatement algorithms MUST be specified by the
 extension that defines the feature.

 Paragraph 2:

 Change:

 The answer message initiating endpoint MUST NOT include any overload
    control solution defined AVPs into its answer messages if the request
    message initiating endpoint has not indicated support at the
    beginning of the created session (or transaction in a case of non-
    session state maintaining applications). The same also applies if
    none of the announced capabilities match between the two endpoints.

 To:

 The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR
 AVP or any other overload control AVPs defined in extension drafts in
 response messages for transaction where the request message does not
 include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features
 AVP in the request message indicates that the sender of the request
 message does not support DOIC.

 Section 5.5.2, Paragraph 1:

 Change:

    Once a reacting node receives an OC-OLR AVP from a reporting node, it
    applies the traffic abatement based on the commonly supported
    algorithm with the reporting node and the current overload condition.
    The reacting node learns the reporting node supported abatement
    algorithms directly from the received answer message containing the
    OC-Supported-Features AVP or indirectly remembering the previously
    used traffic abatement algorithm with the given reporting node.

 To: (removing the last portion of the last sentence)

    Once a reacting node receives an OC-OLR AVP from a reporting node, it
    applies the traffic abatement based on the commonly supported
    algorithm with the reporting node and the current overload condition.
    The reacting node learns the reporting node supported abatement
    algorithms directly from the received answer message containing the
    OC-Supported-Features AVP.

 -----

 +1, with a minor suggested edit:

 On Mar 17, 2014, at 2:03 PM, Steve Donovan 
 wrote:

 > Change:
 >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
 >    applies the traffic abatement based on the commonly supported
 >    algorithm with the reporting node and the current overload condition.
 >    The reacting node learns the reporting node supported abatement
 >    algorithms directly from the received answer message containing the
 >    OC-Supported-Features AVP or indirectly remembering the previously
 >    used traffic abatement algorithm with the given reporting node.

 > To: (removing the last portion of the last sentence)
 >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
 >    applies the traffic abatement based on the commonly supported

 s/"commonly supported"/selected

 "Commonly supported" is no longer descriptive. There may be several
 commonly supported algorithm, but the reporting node selects just one.

 >    algorithm with the reporting node and the current overload condition.
 >    The reacting node learns the reporting node supported abatement
 >    algorithms directly from the received answer message containing the
 >    OC-Supported-Features AVP.
 >

-- 
--------------------------------------+---------------------------
 Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Fri Mar 21 06:35:59 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 005181A03E2 for ; Fri, 21 Mar 2014 06:35:58 -0700 (PDT)
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 tCDJGFMCm6Kh for ; Fri, 21 Mar 2014 06:35:55 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id B771E1A06C3 for ; Fri, 21 Mar 2014 06:35:55 -0700 (PDT)
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 s2LDZiKs019101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 21 Mar 2014 08:35:46 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2LDZiw4012944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Mar 2014 14:35:44 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 21 Mar 2014 14:35:44 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #27 (draft-docdt-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC
Thread-Index: AQHPRQiU/neYdCuGLEaJYcs/8McBm5rribDw
Date: Fri, 21 Mar 2014 13:35:43 +0000
Message-ID: 
References: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> <081.4c825644f7aa6684a8771641ae43bac5@trac.tools.ietf.org>
In-Reply-To: <081.4c825644f7aa6684a8771641ae43bac5@trac.tools.ietf.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/MKo8Fdz7EtJt5TCKnkXh-ogDC1A
Subject: Re: [Dime] [dime] #27 (draft-docdt-dime-ovli): 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: Fri, 21 Mar 2014 13:35:58 -0000

SGkgU3RldmUNCg0KVGhpcyBtYWlsIG1lbnRpb25zICMyNyB0aWNrZXQgOiBCZWhhdmlvciBvZiBh
Z2VudCBhY3Rpbmcgb24gYmVoYWxmIG9mIENsaWVudCB0aGF0IGRvZXMgbm90IHN1cHBvcnQgRE9J
Qw0KDQpCdXQgdGhlIGNvbW1lbnQgaXMgYWJvdXQgdGlja2V0ICMyOSB0aGF0IGlzIGFkZHJlc3Nl
ZCBzZXBhcmF0ZWx5Lg0KDQpJcyB0aGlzIEkgbm90IGFuIGVycm9yIG9yIHdoYXQgaXMgdGhlIHRl
eHQgcHJvcG9zZWQgZm9yIHRpY2tldCAjMjcuDQoNCkJlc3QgcmVnYXJkcw0KDQpKYWNxdWVzIA0K
DQoNCg0KLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBEaU1FIFttYWlsdG86ZGlt
ZS1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIGRpbWUgaXNzdWUgdHJhY2tlcg0KRW52
b3nDqcKgOiB2ZW5kcmVkaSAyMSBtYXJzIDIwMTQgMTQ6MjENCsOAwqA6IGRyYWZ0LWRvY2R0LWRp
bWUtb3ZsaUB0b29scy5pZXRmLm9yZzsgc3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tDQpDY8KgOiBk
aW1lQGlldGYub3JnDQpPYmpldMKgOiBSZTogW0RpbWVdIFtkaW1lXSAjMjcgKGRyYWZ0LWRvY2R0
LWRpbWUtb3ZsaSk6IEJlaGF2aW9yIG9mIGFnZW50IGFjdGluZyBvbiBiZWhhbGYgb2YgQ2xpZW50
IHRoYXQgZG9lcyBub3Qgc3VwcG9ydCBET0lDDQoNCiMyNzogQmVoYXZpb3Igb2YgYWdlbnQgYWN0
aW5nIG9uIGJlaGFsZiBvZiBDbGllbnQgdGhhdCBkb2VzIG5vdCBzdXBwb3J0IERPSUMNCg0KQ2hh
bmdlcyAoYnkgc3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tKToNCg0KICogc3RhdHVzOiAgbmV3ID0+
IGNsb3NlZA0KICogcmVzb2x1dGlvbjogICA9PiBmaXhlZA0KDQoNCkNvbW1lbnQ6DQoNCiBJIGJl
bGlldmUgd2UgaGF2ZSBjb25zZW5zdXMgb24gdGhpcyB0aWNrZXQuDQoNCiBJIGhhZCBwdXQgdGhl
IGZvbGxvd2luZyBpbnRvIG15IGlzc3VlIHN0YXR1cyBkb2N1bWVudDoNCg0KIEFncmVlZCDigJMg
UmVtb3ZlZCBPQy1TZXF1ZW5jZS1OdW1iZXIgZnJvbSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMgQVZQ
Lg0KDQogQWdyZWVkIOKAkyBUaGUgc2NvcGUgb2YgYW4gT0MtU3VwcG9ydGVkLUZlYXR1cmVzIEFW
UCBpcyBhIHNpbmdsZSAgdHJhbnNhY3Rpb24uDQoNCiBBZ3JlZWQg4oCTIERpYW1ldGVyIG5vZGVz
IHRoYXQgc3VwcG9ydCBET0lDIG11c3QgaW5jbHVkZSB0aGUgT0MtU3VwcG9ydGVkLSAgRmVhdHVy
ZXMgQVZQIGluIGFsbCByZXF1ZXN0cy4NCg0KIEkgYmVsaWV2ZSB0aGF0IHRoaXMgdHJhbnNsYXRl
cyBpbnRvIHRoZSB0ZXh0IGNoYW5nZXMgb3V0bGluZWQgYmVsb3cuICBJZiAgd2UgaGF2ZSBhZ3Jl
ZW1lbnQgb24gdGhlIHRleHQgYmVsb3cgd2UgY2FuIGNsb3NlIHRoZSBpc3N1ZSBhbmQgSSdsbCB1
cGRhdGUgIHRoZSB0ZXh0IGluIHRoZSAtMDIgZHJhZnQgYWNjb3JkaW5nbHkuDQoNCiBSZWdhcmRz
LA0KDQogU3RldmUNCg0KIC0tLS0tDQoNCiBTZWN0aW9uIDQuMToNCg0KIFJlbW92ZSA8IE9DLVNl
cXVlbmNlLU51bWJlciA+ICBmcm9tIE9DLVN1cHBvcnRlZC1GZWF0dXJlcyBzeW50YXggIGRlc2Ny
aXB0aW9uLg0KDQogUmVtb3ZlIHBhcmFncmFwaCAzIHRoYXQgc3RhcnRzICJPQy1TZXF1ZW5jZS1O
dW1iZXIgQVZQIGlzIHVzZWQuLi4iDQoNCiBTZWN0aW9uIDQuNCwgUGFyYWdyYXBoIDE6DQoNCiBS
ZW1vdmUgcmVmZXJlbmNlIHRvIHNlY3Rpb24gNC4xLg0KDQogU2VjdGlvbiA1LjMuMSwgUGFyYWdy
YXBoIDE6DQoNCiBDaGFuZ2U6DQoNCiBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZQ0KICAgIHJl
cXVlc3QgbWVzc2FnZSBpbml0aWF0aW5nIGVuZHBvaW50IGluY2x1ZGVzIHRoZSBjYXBhYmlsaXR5
DQogICAgYW5ub3VuY2VtZW50IGludG8gZXZlcnkgcmVxdWVzdCByZWdhcmRsZXNzIGl0IGhhcyBo
YWQgcHJpb3IgbWVzc2FnZQ0KICAgIGV4Y2hhbmdlcyB3aXRoIHRoZSBnaXZlIHJlbW90ZSBlbmRw
b2ludC4gSW4gYSBjYXNlIG9mIGEgRGlhbWV0ZXINCiAgICBzZXNzaW9uIG1haW50YWluaW5nIGFw
cGxpY2F0aW9uLCBzZW5kaW5nIHRoZSBPQy1TdXBwb3J0ZWQtRmVhdHVyZXMNCiAgICBBVlAgaW4g
ZXZlcnkgbWVzc2FnZSBpcyBub3QgcmVhbGx5IG5lY2Vzc2FyeSBhZnRlciB0aGUgaW5pdGlhbA0K
ICAgIGNhcGFiaWxpdHkgYW5ub3VuY2VtZW50IG9yIHVudGlsIHRoZXJlIGlzIGEgY2hhbmdlIGlu
IHN1cHBvcnRlZA0KICAgIGZlYXR1cmVzLiBUbzogVGhlIGxpZmV0aW1lIG9mIGEgY2FwYWJpbGl0
eSBhbm5vdW5jZW1lbnQgaXMgbGltaXRlZCB0byBhICBzaW5nbGUgdHJhbnNhY3Rpb24uIEFzIGEg
cmVzdWx0LCB0aGUgcmVhY3Rpbmcgbm9kZSBNVVNUIGluY2x1ZGUgdGhlICBjYXBhYmlsaXR5IGFu
bm91bmNlbWVudCBpbiBhbGwgcmVxdWVzdCBtZXNzYWdlcy4NCg0KLS0gDQotLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tDQogUmVwb3J0ZXI6
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICBPd25lcjogIGRyYWZ0LWRvY2R0LWRp
bWUtDQogIHNyZG9ub3ZhbkB1c2Rvbm92YW5zLmNvbSAgICAgICAgICAgfCAgb3ZsaUB0b29scy5p
ZXRmLm9yZw0KICAgICBUeXBlOiAgZGVmZWN0ICAgICAgICAgICAgICAgICAgIHwgICAgICBTdGF0
dXM6ICBjbG9zZWQNCiBQcmlvcml0eTogIGNyaXRpY2FsICAgICAgICAgICAgICAgICB8ICAgTWls
ZXN0b25lOg0KQ29tcG9uZW50OiAgZHJhZnQtZG9jZHQtZGltZS1vdmxpICAgIHwgICAgIFZlcnNp
b246DQogU2V2ZXJpdHk6ICBTdWJtaXR0ZWQgV0cgRG9jdW1lbnQgICAgfCAgUmVzb2x1dGlvbjog
IGZpeGVkDQogS2V5d29yZHM6ICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLQ0KDQpUaWNr
ZXQgVVJMOiA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUvdHJhYy90aWNrZXQvMjcjY29t
bWVudDoxPg0KZGltZSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2RpbWUvPg0KDQpfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRGlNRSBtYWlsaW5nIGxp
c3QNCkRpTUVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
ZGltZQ0K


From nobody Fri Mar 21 06:43: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 C8FB21A074A for ; Fri, 21 Mar 2014 06:43:20 -0700 (PDT)
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 UXK30WQRJ8q7 for ; Fri, 21 Mar 2014 06:43:19 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 392AF1A06C3 for ; Fri, 21 Mar 2014 06:43:19 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51478 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WQzj3-0008B4-32 for dime@ietf.org; Fri, 21 Mar 2014 06:43:09 -0700
Message-ID: <532C41EC.8020402@usdonovans.com>
Date: Fri, 21 Mar 2014 08:43:08 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org> <081.4c825644f7aa6684a8771641ae43bac5@trac.tools.ietf.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020404000804000107080401"
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/WENq3ISopIsUbVoItpBAtsnN4LI
Subject: Re: [Dime] [dime] #27 (draft-docdt-dime-ovli): 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: Fri, 21 Mar 2014 13:43:21 -0000

This is a multi-part message in MIME format.
--------------020404000804000107080401
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

JJ,

Thanks for catching that.  I have closed the wrong ticket.

I will reopen #27 and close #29. 

Thanks again,

Steve

On 3/21/14 8:35 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi Steve
>
> This mail mentions #27 ticket : Behavior of agent acting on behalf of Client that does not support DOIC
>
> But the comment is about ticket #29 that is addressed separately.
>
> Is this I not an error or what is the text proposed for ticket #27.
>
> Best regards
>
> Jacques 
>
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
> Envoyé : vendredi 21 mars 2014 14:21
> À : draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
> Cc : dime@ietf.org
> Objet : Re: [Dime] [dime] #27 (draft-docdt-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC
>
> #27: Behavior of agent acting on behalf of Client that does not support DOIC
>
> Changes (by srdonovan@usdonovans.com):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> Comment:
>
>  I believe we have consensus on this ticket.
>
>  I had put the following into my issue status document:
>
>  Agreed – Removed OC-Sequence-Number from OC-Supported-Features AVP.
>
>  Agreed – The scope of an OC-Supported-Features AVP is a single  transaction.
>
>  Agreed – Diameter nodes that support DOIC must include the OC-Supported-  Features AVP in all requests.
>
>  I believe that this translates into the text changes outlined below.  If  we have agreement on the text below we can close the issue and I'll update  the text in the -02 draft accordingly.
>
>  Regards,
>
>  Steve
>
>  -----
>
>  Section 4.1:
>
>  Remove < OC-Sequence-Number >  from OC-Supported-Features syntax  description.
>
>  Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."
>
>  Section 4.4, Paragraph 1:
>
>  Remove reference to section 4.1.
>
>  Section 5.3.1, Paragraph 1:
>
>  Change:
>
>  It is RECOMMENDED that the
>     request message initiating endpoint includes the capability
>     announcement into every request regardless it has had prior message
>     exchanges with the give remote endpoint. In a case of a Diameter
>     session maintaining application, sending the OC-Supported-Features
>     AVP in every message is not really necessary after the initial
>     capability announcement or until there is a change in supported
>     features. To: The lifetime of a capability announcement is limited to a  single transaction. As a result, the reacting node MUST include the  capability announcement in all request messages.
>


--------------020404000804000107080401
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    JJ,

      

      Thanks for catching that.  I have closed the wrong ticket.

      

      I will reopen #27 and close #29.  

      

      Thanks again,

      

      Steve

      

    
    
On 3/21/14 8:35 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
Hi Steve

This mail mentions #27 ticket : Behavior of agent acting on behalf of Client that does not support DOIC

But the comment is about ticket #29 that is addressed separately.

Is this I not an error or what is the text proposed for ticket #27.

Best regards

Jacques 



-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoyé : vendredi 21 mars 2014 14:21
À : draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #27 (draft-docdt-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC

#27: Behavior of agent acting on behalf of Client that does not support DOIC

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 I believe we have consensus on this ticket.

 I had put the following into my issue status document:

 Agreed – Removed OC-Sequence-Number from OC-Supported-Features AVP.

 Agreed – The scope of an OC-Supported-Features AVP is a single  transaction.

 Agreed – Diameter nodes that support DOIC must include the OC-Supported-  Features AVP in all requests.

 I believe that this translates into the text changes outlined below.  If  we have agreement on the text below we can close the issue and I'll update  the text in the -02 draft accordingly.

 Regards,

 Steve

 -----

 Section 4.1:

 Remove < OC-Sequence-Number >  from OC-Supported-Features syntax  description.

 Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."

 Section 4.4, Paragraph 1:

 Remove reference to section 4.1.

 Section 5.3.1, Paragraph 1:

 Change:

 It is RECOMMENDED that the
    request message initiating endpoint includes the capability
    announcement into every request regardless it has had prior message
    exchanges with the give remote endpoint. In a case of a Diameter
    session maintaining application, sending the OC-Supported-Features
    AVP in every message is not really necessary after the initial
    capability announcement or until there is a change in supported
    features. To: The lifetime of a capability announcement is limited to a  single transaction. As a result, the reacting node MUST include the  capability announcement in all request messages.



    

    

  


--------------020404000804000107080401--


From nobody Fri Mar 21 06:44: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 A06E61A072D for ; Fri, 21 Mar 2014 06:44:35 -0700 (PDT)
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 X40PbfEmhI6g for ; Fri, 21 Mar 2014 06:44:32 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BE54B1A074A for ; Fri, 21 Mar 2014 06:44:32 -0700 (PDT)
Received: from localhost ([127.0.0.1]:52218 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WQzk7-0007xn-K9; Fri, 21 Mar 2014 14:44: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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Fri, 21 Mar 2014 13:44:15 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/27#comment:2
Message-ID: <081.aef064555dae2b4afa73a3d0526024ba@trac.tools.ietf.org>
References: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org>
X-Trac-Ticket-ID: 27
In-Reply-To: <066.f61ef866d851ac5c96a3d95ef727dae3@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dkd-JniHeUI9ZTjsdvwxt-DWYxQ
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #27 (draft-docdt-dime-ovli): Behavior of agent acting on behalf of Client that does not support DOIC
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: Fri, 21 Mar 2014 13:44:35 -0000

#27: Behavior of agent acting on behalf of Client that does not support DOIC

Changes (by srdonovan@usdonovans.com):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Wrong ticket was closed.  These changes apply to issue @29.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |      Status:  reopened
 Priority:  critical                 |   Milestone:
Component:  draft-docdt-dime-ovli    |     Version:
 Severity:  Submitted WG Document    |  Resolution:
 Keywords:                           |
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Fri Mar 21 06:45: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 B10EB1A0994 for ; Fri, 21 Mar 2014 06:45:18 -0700 (PDT)
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 dnnfpqfeYsBg for ; Fri, 21 Mar 2014 06:45:17 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CB7CE1A074A for ; Fri, 21 Mar 2014 06:45:16 -0700 (PDT)
Received: from localhost ([127.0.0.1]:52288 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WQzkx-0005vs-7W; Fri, 21 Mar 2014 14:45:07 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Fri, 21 Mar 2014 13:45:07 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/29#comment:1
Message-ID: <089.d981037aaa50a23d27be8151a5a3432e@trac.tools.ietf.org>
References: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org>
X-Trac-Ticket-ID: 29
In-Reply-To: <074.f935b422e3c04ea6cc7d5a8fbf9fb3b3@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: srdonovan@usdonovans.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/FXBIrr1iRlBBYliLN8JmhviPDtU
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #29 (draft-docdt-dime-ovli): OC-Sequence-Number in OC-Supported-Features
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: Fri, 21 Mar 2014 13:45:18 -0000

#29: OC-Sequence-Number in OC-Supported-Features

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 I believe we have consensus on this ticket.

 I had put the following into my issue status document:

 Agreed – Removed OC-Sequence-Number from OC-Supported-Features AVP.

 Agreed – The scope of an OC-Supported-Features AVP is a single
 transaction.

 Agreed – Diameter nodes that support DOIC must include the OC-Supported-
 Features AVP in all requests.

 I believe that this translates into the text changes outlined below. If we
 have agreement on the text below we can close the issue and I'll update
 the text in the -02 draft accordingly.

 Regards,

 Steve

 Section 4.1:

 Remove < OC-Sequence-Number > from OC-Supported-Features syntax
 description.

 Remove paragraph 3 that starts "OC-Sequence-Number AVP is used..."

 Section 4.4, Paragraph 1:

 Remove reference to section 4.1.

 Section 5.3.1, Paragraph 1:

 Change:

 It is RECOMMENDED that the

     request message initiating endpoint includes the capability
 announcement into every request regardless it has had prior message
 exchanges with the give remote endpoint. In a case of a Diameter session
 maintaining application, sending the OC-Supported-Features AVP in every
 message is not really necessary after the initial capability announcement
 or until there is a change in supported features. To: The lifetime of a
 capability announcement is limited to a single transaction. As a result,
 the reacting node MUST include the capability announcement in all request
 messages.

-- 
----------------------------------------------+---------------------------
 Reporter:  lionel.morand@orange-ftgroup.com  |       Owner:  Ulrich Wiehe
     Type:  defect                            |      Status:  closed
 Priority:  major                             |   Milestone:
Component:  draft-docdt-dime-ovli             |     Version:  2.0
 Severity:  Active WG Document                |  Resolution:  fixed
 Keywords:                                    |
----------------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Fri Mar 21 07:09: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 7954A1A099A for ; Fri, 21 Mar 2014 07:09:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.561
X-Spam-Level: **
X-Spam-Status: No, score=2.561 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, 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 svnaeNxq_Q_5 for ; Fri, 21 Mar 2014 07:09:53 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 11E121A0996 for ; Fri, 21 Mar 2014 07:09:53 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51568 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WR08j-0007Np-LV for dime@ietf.org; Fri, 21 Mar 2014 07:09:43 -0700
Message-ID: <532C4824.5050009@usdonovans.com>
Date: Fri, 21 Mar 2014 09:09:40 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090303010000080100020100"
X-OutGoing-Spam-Status: No, score=-1.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/NwVfGXyX86Fjz9e_KnzHn3Pe4lw
Subject: [Dime] Issues #25 and #26 will not be resolved in -02
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: Fri, 21 Mar 2014 14:09:54 -0000

This is a multi-part message in MIME format.
--------------090303010000080100020100
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

I believe that the resolution of issue #25(Section 3.1.5 Diameter Agent
Behavior ) is dependent on
resolution of issue #26 (Overload Control Endpoints under specified
).

Given that we do not have resolution of issue #26, both of these issues
will remain open with the -02 version of the document.

Regards,

Steve



--------------090303010000080100020100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      I believe that the resolution of issue #25 (Section 3.1.5 Diameter Agent Behavior) is
      dependent on resolution of issue #26 (Overload Control Endpoints under specified).

      

      Given that we do not have resolution of issue #26, both of these
      issues will remain open with the -02 version of the document.

      

      Regards,

      

      Steve

      

    
  


--------------090303010000080100020100--


From nobody Fri Mar 21 07:33:14 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 198001A09B1 for ; Fri, 21 Mar 2014 07:33:08 -0700 (PDT)
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_20=-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 m8sdqYo2KkRX for ; Fri, 21 Mar 2014 07:33:06 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id B58EC1A09B5 for ; Fri, 21 Mar 2014 07:33:06 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:51729 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WR0VE-0002RD-II for dime@ietf.org; Fri, 21 Mar 2014 07:32:57 -0700
Message-ID: <532C4D98.7040303@usdonovans.com>
Date: Fri, 21 Mar 2014 09:32:56 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------000501010707030400030409"
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/i8fg8osGCoB1fQJfadw3GA1JQdc
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Fri, 21 Mar 2014 14:33:08 -0000

This is a multi-part message in MIME format.
--------------000501010707030400030409
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

Ben and I took the action item to discuss the need for the
Realm-Routed-Reports (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in
London was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the
host in the overload report (with the host implicitly determined from
the Origin-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP
matching the realm in the overload report (with the realm implicitly
determine from the Origin-Realm of the answer message carrying the
overload report).

The action Ben and I took was to come back with an opinion on whether
RRR reports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR
reports in the current version of the base DOIC draft. 

We still have some concerns with the granularity of control enabled by
having just the two report types but the analysis of whether RRR reports
are still needed can occur independent of the base DOIC draft.  If there
is a determination that RRRs are needed in time to include in the base
draft then it can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine
them per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with
RRRs).

There is also need for text describing the interaction between host and
the realm reports.  I don't expect we will have consensus on this
wording prior to the -02 draft being submitted.  To this end, I'll open
a new issue to deal with the need for wording on the interaction.

Regards,

Steve

--------------000501010707030400030409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      Ben and I took the action item to discuss the need for the
      Realm-Routed-Reports (RRR) report type.

      

      As you may recall, the consensus coming out of the DIME WG meeting
      in London was to support two report types:

      

      - Host -- Impacting requests with a Destination-Host AVP matching
      the host in the overload report (with the host implicitly
      determined from the Origin-Host AVP of the answer message carrying
      the overload report).

      

      - Realm -- Impacting 100% of the requests with a Destination-Realm
      AVP matching the realm in the overload report (with the realm
      implicitly determine from the Origin-Realm of the answer message
      carrying the overload report).

      

      The action Ben and I took was to come back with an opinion on
      whether RRR reports should also be supported.

      

      My summary of the discussion is that we recommend to NOT include
      RRR reports in the current version of the base DOIC draft.  

      

      We still have some concerns with the granularity of control
      enabled by having just the two report types but the analysis of
      whether RRR reports are still needed can occur independent of the
      base DOIC draft.  If there is a determination that RRRs are needed
      in time to include in the base draft then it can be considered at
      that time.

      

      Based on this, I propose the following 

      

      - Resolution to issue #23 is to remove RRR reports from the
      document.

      - Resolution to issue #55 is to add Realm reports (actually to
      redefine them per the above definition).

      - Resolution to issue #57 is that it no longer applies (as it
      deals with RRRs).

      

      There is also need for text describing the interaction between
      host and the realm reports.  I don't expect we will have consensus
      on this wording prior to the -02 draft being submitted.  To this
      end, I'll open a new issue to deal with the need for wording on
      the interaction.

      

      Regards,

      

      Steve
  


--------------000501010707030400030409--


From nobody Fri Mar 21 07:34:10 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 0243E1A09B4 for ; Fri, 21 Mar 2014 07:34:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level: 
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-5, 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 jyHvgWoiHXDi for ; Fri, 21 Mar 2014 07:34:04 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 989CA1A09AC for ; Fri, 21 Mar 2014 07:34:03 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2LEXr5H026298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Mar 2014 14:33:53 GMT
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 s2LEXr2o000596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 15:33:53 +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; Fri, 21 Mar 2014 15:33:52 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.73]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 15:33:52 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC Overview of Operation
Thread-Index: AQHPQg+Ei9WGGfM+0UexXrpcnFseGprrfPKAgAAhLpA=
Date: Fri, 21 Mar 2014 14:33:52 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151C9869@DEMUMBX014.nsn-intra.net>
References: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com> <532C3D99.30809@usdonovans.com>
In-Reply-To: <532C3D99.30809@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.117]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151C9869DEMUMBX014nsnin_"
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: 20406
X-purgate-ID: 151667::1395412433-0000128C-45466E94/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/T52goDa94w1RDJlyeipy54_C1f4
Subject: Re: [Dime] DOIC Overview of Operation
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: Fri, 21 Mar 2014 14:34:07 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C9869DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

please find some minor comments inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 2:25 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC Overview of Operation

I propose that we close issue 41 with Ben's text into section 3.0.  I also =
propose that we open a new issue to capture the need to make the rest of se=
ction 3 consistent.

I will do so unless I hear an alternative suggestion soon.

Regards,

Steve
On 3/17/14 1:34 PM, Ben Campbell wrote:

Hi,



the dime-ovli currently lacks any sort of high-level overview of operation.=
 As written, it jumps into details without giving the reader a high-level v=
iew of how it works. I think that will create confusion for new readers tha=
t have not been involved in discussions so far.



I propose adding the following text to the beginning of section 3. This wou=
ld be entirely non-normative. I recognize that this would create some redun=
dancies with later subsections. I don't address those here, but we would ne=
ed to do so when integrating this text if we agree to add it.



Thanks!



Ben.



--------------------------



   The Diameter Overload Information Conveyance (DOIC) mechanism allows

   Diameter nodes to request other nodes to perform overload abatement

   actions, that is, actions to reduce the load offered to the

   overloaded node.



   A Diameter node that supports DOIC is known as a "DOIC endpoint".

   Any Diameter node can act as a DOIC endpoint, including clients,

   servers, and agents.  DOIC endpoints are further divided into

   "Reporting Nodes" and "Reacting Nodes."  A reporting node requests

   overload abatement by sending an Overload Report (OLR) to one or more

   reacting nodes.



   A reacting node consumes OLRs, and performs whatever actions are

   needed to fulfill the requests.  A Reporting node may report overload

   on its own behalf, or on behalf of other (typically upstream) nodes.

   Likewise, a reacting node may perform overload abatement on its own

   behalf, or on behalf of other (typically downstream) nodes.



   A node's role as a DOIC endpoint is independent of its Diameter role.

   For example, Diameter relay and proxy agents may act as DOIC

   endpoints, even though they are not endpoints in the Diameter sense.

   Since Diameter enables bi-directional applications, where Diameter

   servers can send requests towards Diameter clients, a given Diameter

   node can simultaneously act as a reporting node and reacting node.



   Likewise, an relay or proxy agent may act as a reacting node from the

   perspective of upstream nodes, and a reporting node from the

   perspective of downstream nodes.



   DOIC endpoints do not generate new messages to carry DOIC related

   information.  Rather, they "piggyback" DOIC information over existing

   Diameter messages by inserting new AVPs into existing Diameter

   requests and responses.  Nodes indicate support for DOIC, and any

   needed DOIC parameters by inserting an OC_Supported_Features AVP

   (Section 4.1) into existing requests and responses.  Reporting nodes

   send OLRs by inserting OC-OLR AVPs[Wiehe, Ulrich (NSN - DE/Munich)]  int=
o existing responses.  (Section 4.3)



   A given OLR applies to the Diameter [Wiehe, Ulrich (NSN - DE/Munich)] or=
ig-realm and application of the

   Diameter [Wiehe, Ulrich (NSN - DE/Munich)] response message that carries=
 it.  If a reporting node supports more

   than one realm and/or application, it reports independently for each

   combination of realm and application.  Similarly, OC-Feature-Vector

   AVPs apply to the realm and application of the enclosing message.

   This implies that a node may support DOIC for one application and/or

   realm, but not another, and may indicate different DOIC parameters

   for each application and realm for which it supports DOIC.



   Reacting nodes perform overload abatement according to an agreed-upon

   abatement algorithm.  An abatement algorithm defines the meaning of

   the parameters of an OLR, and the procedures required for overload

   abatement.  This document specifies a single must-support algorithm,

   namely the "loss" algorithm [ref?].  Future specifications may

   introduce new algorithms.



   Overload conditions may vary in scope.  For example, a single

   Diameter node may be overloaded, in which case reacting nodes may

   reasonably attempt to send throttled requests to other destinations

   or via other agents

[Wiehe, Ulrich (NSN - DE/Munich)] sending requests to the same destination =
via other agents does not help and should actually be avoided

.  On the other hand, an entire Diameter realm may

   be overloaded, in which case such attempts would do harm.  DOIC OLRs

   have a concept of "report type" (Section 4.6), where the type defines

   such behaviors.  Report types are extensible.  This document defines

   report types for overload of a specific server, and for overload of

   an entire realm.



   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes

   that are "adjacent" for DOIC purposes may not be adjacent from a

   Diameter, or transport, perspective.  For example, one or more

   Diameter agents that do not support DOIC may exist between a given

   pair of reporting and reacting nodes, as long as those agents pass

   unknown AVPs through unmolested.  The report types described in this

   document can safely pass through non-supporting agents.  This may not

   be true for report types defined in future specifications.  Documents

   that introduce new report types MUST describe any limitations on

   their use across non-supporting agents.



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C9869DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

please fin=
d some minor comments inline.


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 2:25 PM

To: dime@ietf.org

Subject: Re: [Dime] DOIC Overview of Operation






 


I propose that we clo=
se issue 41 with Ben's text into section 3.0.  I also propose that we =
open a new issue to capture the need to make the rest of section 3 consiste=
nt.



I will do so unless I hear an alternative suggestion soon.



Regards,



Steve




On 3/17/14 1:34 PM, Ben Campbell wrote:





Hi,


 


the dime-ovli currently lacks any sort of high-level overview of opera=
tion. As written, it jumps into details without giving the reader a high-le=
vel view of how it works. I think that will create confusion for new reader=
s that have not been involved in discussions so far.


 


I propose adding the following text to the beginning of section 3. Thi=
s would be entirely non-normative. I recognize that this would create some =
redundancies with later subsections. I don't address those here, but we wou=
ld need to do so when integrating this text if we agree to add it.


 


Thanks!


 


Ben.


 


--------------------------


 


   The Diameter Overload Information Conveyance (DOIC) mecha=
nism allows


   Diameter nodes to request other nodes to perform overload=
 abatement


   actions, that is, actions to reduce the load offered to t=
he


   overloaded node.


 


   A Diameter node that supports DOIC is known as a "DO=
IC endpoint".


   Any Diameter node can act as a DOIC endpoint, including c=
lients,


   servers, and agents.  DOIC endpoints are further div=
ided into


   "Reporting Nodes" and "Reacting Nodes.&quo=
t;  A reporting node requests


   overload abatement by sending an Overload Report (OLR) to=
 one or more


   reacting nodes.


 


   A reacting node consumes OLRs, and performs whatever acti=
ons are


   needed to fulfill the requests.  A Reporting node ma=
y report overload


   on its own behalf, or on behalf of other (typically upstr=
eam) nodes.


   Likewise, a reacting node may perform overload abatement =
on its own


   behalf, or on behalf of other (typically downstream) node=
s.


 


   A node's role as a DOIC endpoint is independent of its Di=
ameter role.


   For example, Diameter relay and proxy agents may act as D=
OIC


   endpoints, even though they are not endpoints in the Diam=
eter sense.


   Since Diameter enables bi-directional applications, where=
 Diameter


   servers can send requests towards Diameter clients, a giv=
en Diameter


   node can simultaneously act as a reporting node and react=
ing node.


 


   Likewise, an relay or proxy agent may act as a reacting n=
ode from the


   perspective of upstream nodes, and a reporting node from =
the


   perspective of downstream nodes.


 


   DOIC endpoints do not generate new messages to carry DOIC=
 related


   information.  Rather, they "piggyback" DOI=
C information over existing


   Diameter messages by inserting new AVPs into existing Dia=
meter


   requests and responses.  Nodes indicate support for =
DOIC, and any


   needed DOIC parameters by inserting an OC_Supported_Featu=
res AVP


   (Section 4.1) into existing requests and responses. =
 Reporting nodes


   send OLRs by inserting OC-OLR AVPs[Wiehe, Ulrich (NSN=
 - DE/Munich)] =
 into existing responses.  (Se=
ction 4.3)


 


   A given OLR applies to the Diameter =
[Wiehe, Ulrich (N=
SN - DE/Munich)] orig-realm and application of the<=
/span>


   Diameter [Wiehe, Ulrich (NSN - DE/Munich)] response message that carries it.  If a reporting node suppo=
rts more


   than one realm and/or application, it reports independent=
ly for each


   combination of realm and application.  Similarly, OC=
-Feature-Vector


   AVPs apply to the realm and application of the enclosing =
message.


   This implies that a node may support DOIC for one applica=
tion and/or


   realm, but not another, and may indicate different DOIC p=
arameters


   for each application and realm for which it supports DOIC=
.


 


   Reacting nodes perform overload abatement according to an=
 agreed-upon


   abatement algorithm.  An abatement algorithm defines=
 the meaning of


   the parameters of an OLR, and the procedures required for=
 overload


   abatement.  This document specifies a single must-su=
pport algorithm,


   namely the "loss" algorithm [ref?].  Futur=
e specifications may


   introduce new algorithms.


 


   Overload conditions may vary in scope.  For example,=
 a single


   Diameter node may be overloaded, in which case reacting n=
odes may


   reasonably attempt to send throttled requests to other de=
stinations


   or=
 via other agents

[Wiehe, Ulrich (NSN - DE/Munich)] sending requests to the same dest=
ination via other agents does not help and should actually be avoided<=
/o:p>


.  On the other hand, an entire Diameter realm may

   be overloaded, in which case such attempts would do harm.=
  DOIC OLRs


   have a concept of "report type" (Section 4.6), =
where the type defines


   such behaviors.  Report types are extensible.  =
This document defines


   report types for overload of a specific server, and for o=
verload of


   an entire realm.


 


   While a reporting node sends OLRs to "adjacent"=
 reacting nodes, nodes


   that are "adjacent" for DOIC purposes may not b=
e adjacent from a


   Diameter, or transport, perspective.  For example, o=
ne or more


   Diameter agents that do not support DOIC may exist betwee=
n a given


   pair of reporting and reacting nodes, as long as those ag=
ents pass


   unknown AVPs through unmolested.  The report types d=
escribed in this


   document can safely pass through non-supporting agents.&n=
bsp; This may not


   be true for report types defined in future specifications=
.  Documents


   that introduce new report types MUST describe any limitat=
ions on


   their use across non-supporting agents.


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C9869DEMUMBX014nsnin_--


From nobody Fri Mar 21 08:10: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 3B0E51A0989 for ; Fri, 21 Mar 2014 08:09:57 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 7tpavYUrQOmI for ; Fri, 21 Mar 2014 08:09:53 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7431A09B8 for ; Fri, 21 Mar 2014 08:09:53 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2LF9h4d006876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 21 Mar 2014 15:09:43 GMT
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 s2LF9hmu013402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 16:09:43 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 21 Mar 2014 16:09:42 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.73]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 16:09:42 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRRJ5RxAw+eepFE2CRX+FLdDvpZrrnPag
Date: Fri, 21 Mar 2014 15:09:41 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net>
References: <532C4D98.7040303@usdonovans.com>
In-Reply-To: <532C4D98.7040303@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.117]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151C98A7DEMUMBX014nsnin_"
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: 9349
X-purgate-ID: 151667::1395414583-0000137C-8950013B/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ZPIKj9R6SHx_7XQANfDX0eSIbLM
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Fri, 21 Mar 2014 15:09:57 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C98A7DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C98A7DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

I don̵=
7;t know what happend in London.


Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151C98A7DEMUMBX014nsnin_--


From nobody Fri Mar 21 10:44:39 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 DBECA1A0904 for ; Fri, 21 Mar 2014 10:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 7VVKJKzXVnNP for ; Fri, 21 Mar 2014 10:44:33 -0700 (PDT)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 445031A07A0 for ; Fri, 21 Mar 2014 10:44:30 -0700 (PDT)
Received: by mail-pa0-f45.google.com with SMTP id kl14so2698594pab.32 for ; Fri, 21 Mar 2014 10:44:21 -0700 (PDT)
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=EHAa8nKzSq4sOGENwHAvgMoJs9swtr5UKQiNugWQ2Vg=; b=oxl0GlkFW0A3vAQ+sezR7l7eEL5qvR68ZjYN2+VE+cZXY1wPLXv609euS3IdW6BuL0 5cbioTb/FCfiVpyVprWfKSoE5/PjTPB/bT0zxhWIQY32tArRGdXXzCsU80bDDPjXMPA0 DGCF29R7hMg4SyIpit1cQwf2CSL09vBpex15TWtDhQLmFLtAuXpeOr5QzGGCij9CYtrn 1QM2prdLB7NDUE/Bh10t/h63a4oBO/tuVm/FyZvUkpk7gFTemMjh9nInHVwnZI8dTuqm tenNOxd+nTUBRg7q84+ZvxKvi+58aZA2E4ixBNcXtTyyfjk93tJDzkFM4QCzN2KezZiL WFqQ==
X-Received: by 10.68.235.6 with SMTP id ui6mr53799689pbc.45.1395423860997; Fri, 21 Mar 2014 10:44:20 -0700 (PDT)
Received: from [172.23.208.47] ([125.35.60.218]) by mx.google.com with ESMTPSA id vx10sm29351371pac.17.2014.03.21.10.44.18 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 10:44:20 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com>
Date: Sat, 22 Mar 2014 01:43:52 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/IT2pyzXtt_2m98U2UDpifOxTz3A
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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: Fri, 21 Mar 2014 17:44:37 -0000

Ben,

On Mar 18, 2014, at 1:59 AM, Ben Campbell  wrote:

>=20
> Hi,
>=20
> In the London meeting, I agreed that this issue was invalid based on =
statements in the room that the 6733 correct treatment of an unknown =
mandatory AVP inside a grouped AVP was to ignore the grouped AVP.
>=20
> On rereading that section of RFC 6733, I disagree with that =
interpretation. Section 4.4 says:
>=20
>> Receivers of a Grouped AVP that
>>   does not have the 'M' (mandatory) bit set and one or more of the
>>   encapsulated AVPs within the group has the 'M' (mandatory) bit set
>>   MAY simply be ignored if the Grouped AVP itself is unrecognized.
>=20
>=20
> That text only applies for _unrecognized_ grouped AVPs. The case in =
question is when you _recognize_ an optional grouped AVP, but do not =
recognize a mandatory AVP imbedded in it. The exception in 4.4 does not =
seem to cover that case.
>=20
> So I no longer believe that the issue is invalid. I think the best =
option is to simply forbid setting of the m-bit on any DOIC related AVP.
>=20
> To address other comments on the issue:
>=20
> Consider the case of a Diameter _relay_ that supports DOIC. It is not =
aware of any application-specific rules about m-bits. It receives an =
OC-Supported-Features or an OC-OLR that has a mandatory AVP that it =
doesn't recognize. Logically, it should probably ignore the entire =
OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a =
relay, it's not going to reject the message. Rather it's likely to try =
to apply the OC-Supported-Features or OC-OLR incorrectly.

RFC6733 also says that relays perform not do any application level
processing. If a relay supports DOIC and does something goofy that
is left for implementation, we should no care nor try to fix the
situation. The implementation is already bending the rules in that
case.

- Jouni


>=20
>=20
> On Feb 7, 2014, at 4:10 PM, dime issue tracker =
 wrote:
>=20
>> #48: Setting M-Bit gives wrong semantics
>>=20
>> Multiple sections indicate that a new application that incorporates =
DOIC
>> can set the M-Bit on DOIC sub-avps. I don't think this ever does the =
right
>> thing.
>>=20
>> IIUC, If a node that otherwise supports DOIC encounters a DOIC avp =
that it
>> doesn't understand, and has the M-Bit set, it will cause a failure of =
the
>> application command. I don't think we want the lack of support of =
some
>> DOIC feature or extension to ever cause an application-level failure. =
 I
>> think we are looking for something that would just cause the OLR to =
be
>> ignored.
>>=20
>> --=20
>> =
-------------------------+------------------------------------------------=
-
>> Reporter:               |      Owner:  draft-docdt-dime-
>> ben@nostrum.com        |  ovli@tools.ietf.org
>>    Type:  defect       |     Status:  new
>> Priority:  major        |  Milestone:
>> Component:  draft-       |    Version:  1.0
>> 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
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Mar 21 10:46:39 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 4474E1A07B7 for ; Fri, 21 Mar 2014 10:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 M8beJQqPGVpE for ; Fri, 21 Mar 2014 10:46:33 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 60AF51A03BF for ; Fri, 21 Mar 2014 10:46:33 -0700 (PDT)
Received: by mail-pd0-f177.google.com with SMTP id y10so2597747pdj.8 for ; Fri, 21 Mar 2014 10:46:24 -0700 (PDT)
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=sBVQKgvcb9C33zQeE37JuSk0l4lWG87wj+g9dABt0MI=; b=s/aBG5ZqUyUCI+y0iutPKyuccAjZ3uSAqfdOUkrO4nUCtBLqX9cnZi/YYcBVx3/xjP Dw376koVJZEmecVkUppR/8QUAmglM6gW4Z1/SQdoSOz3brxWA+tcJeOts0fMluYLR1b/ gA7UJoUMjiEI0cEpRTSlRczOpmOTImUjEL5OLraBdgXpf07yNDQFfxTnlhV33izEA9Jo eVs40LwsQBNizspnEkzz9liQOI/fdKxZPudFNl1zVlPHw2rD2g82B89qNWKelCoEn9ew DD990KEzn1vjPJ4h0cF126RRwdBNe28xyn26iyR0qh2LzpTx3bM5j19hjd71TWM6rirR Qaww==
X-Received: by 10.68.200.133 with SMTP id js5mr33558138pbc.138.1395423983922;  Fri, 21 Mar 2014 10:46:23 -0700 (PDT)
Received: from [172.23.208.47] ([125.35.60.218]) by mx.google.com with ESMTPSA id xn10sm29441225pab.0.2014.03.21.10.46.16 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 10:46:18 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <4857132E-EB7E-4844-B9F4-81DD209E0705@nostrum.com>
Date: Sat, 22 Mar 2014 01:46:12 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <5750EB10-9E07-4CD7-A122-CD5DDBD73003@gmail.com>
References: <4857132E-EB7E-4844-B9F4-81DD209E0705@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GJg-nJrjsZkol1Qy_YDSwbnJY1E
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] DOIC Default Algorithm Specification
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: Fri, 21 Mar 2014 17:46:35 -0000

On Mar 18, 2014, at 2:18 AM, Ben Campbell  wrote:

> Hi,
>=20
> In re-reading dime-ovli, I noticed that the procedures for the =
"default" abatement algorithm are spread through several parts of the =
text. That's going to make life difficult down the road for a couple of =
reasons:
>=20
> 1) There's no easily referenced section that fully defines the =
algorithm. That will be a problem for other docs that want to talk about =
the algorithm (e.g. 3GPP specs), or even other sections in dime-ovli =
that want to mention the default algorithm by reference.
>=20
> 2) It makes extensibility harder, as it will be more difficult to =
define new algorithms, if they need to modify behavior that is spread =
throughout dime-ovli, rather than simply supersede a specific section of =
dime-ovli.
>=20
> I propose that we move all algorithm-specific behavior to its own =
section, and have any other sections that need to talk about the default =
algorithm reference that section rather than attempt to describe the =
behavior.

That would work for me.

- Jouni


>=20
> Thanks!
>=20
> Ben.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Mar 21 11:44:30 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 D34F91A0A38 for ; Fri, 21 Mar 2014 11:44:28 -0700 (PDT)
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 rOiadm_W1_Ft for ; Fri, 21 Mar 2014 11:44:27 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 986F81A0A3A for ; Fri, 21 Mar 2014 11:44:26 -0700 (PDT)
Received: from [172.20.10.9] (mobile-166-147-071-120.mycingular.net [166.147.71.120]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2LIi8mx083760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 21 Mar 2014 13:44:10 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host mobile-166-147-071-120.mycingular.net [166.147.71.120] claimed to be [172.20.10.9]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>
Date: Fri, 21 Mar 2014 13:44:03 -0500
X-Mao-Original-Outgoing-Id: 417120243.331986-e45018d442cacca90b153f1a0dd54564
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/O3uJ0ykoOaj77XRB53_AmzmRLrA
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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: Fri, 21 Mar 2014 18:44:29 -0000

On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  =
wrote:

>>=20
>> Consider the case of a Diameter _relay_ that supports DOIC. It is not =
aware of any application-specific rules about m-bits. It receives an =
OC-Supported-Features or an OC-OLR that has a mandatory AVP that it =
doesn't recognize. Logically, it should probably ignore the entire =
OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a =
relay, it's not going to reject the message. Rather it's likely to try =
to apply the OC-Supported-Features or OC-OLR incorrectly.
>=20
> RFC6733 also says that relays perform not do any application level
> processing. If a relay supports DOIC and does something goofy that
> is left for implementation, we should no care nor try to fix the
> situation. The implementation is already bending the rules in that
> case.

Hi Jouni,

I'm not talking about the case of the relay doing something goofy. =
Rather, I mean when a relay tries to perform basic DOIC processing of an =
OLR as described in the base DOIC spec, but ignores some extension AVP =
that changes the meaning of the OLR. It's not bending the rules so much =
as failing to recognize someone else changing the rules.=


From nobody Fri Mar 21 14:05:55 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 6A31D1A08D0 for ; Fri, 21 Mar 2014 14:05:53 -0700 (PDT)
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 P-2whpNNiLs2 for ; Fri, 21 Mar 2014 14:05:50 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id AF1621A08C6 for ; Fri, 21 Mar 2014 14:05:50 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54177 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WR6dD-0000cs-Bi for dime@ietf.org; Fri, 21 Mar 2014 14:05:40 -0700
Message-ID: <532CA99F.4070409@usdonovans.com>
Date: Fri, 21 Mar 2014 16:05:35 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090103040003030708080205"
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/EeY89jwgC08NV3xSh6l8C_1gGL4
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Fri, 21 Mar 2014 21:05:53 -0000

This is a multi-part message in MIME format.
--------------090103040003030708080205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

The discussion should be captured in the minutes to the meeting.  I
wasn't able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from
yours.  I believe we had come to the conclusion that we needed host and
realm (with the definition of realm as outlined below).  We were still
discussing the need for Realm-Routed-Request reports.

Regards,

Steve

On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> I don't know what happend in London.
>
> Can you please summarize the technical reasons that led to the London
> agreement.
>
> E-mail discussions prior to London have clearly directed towards a
> report type that requests throttling of realm routed request messages
> (i.e. not containing a destination host) rather than a report type
> that requests throttling of messages routed towards a realm (no matter
> whether they contain a destination host or not).   
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Friday, March 21, 2014 3:33 PM
> *To:* dime@ietf.org
> *Subject:* [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> All,
>
> Ben and I took the action item to discuss the need for the
> Realm-Routed-Reports (RRR) report type.
>
> As you may recall, the consensus coming out of the DIME WG meeting in
> London was to support two report types:
>
> - Host -- Impacting requests with a Destination-Host AVP matching the
> host in the overload report (with the host implicitly determined from
> the Origin-Host AVP of the answer message carrying the overload report).
>
> - Realm -- Impacting 100% of the requests with a Destination-Realm AVP
> matching the realm in the overload report (with the realm implicitly
> determine from the Origin-Realm of the answer message carrying the
> overload report).
>
> The action Ben and I took was to come back with an opinion on whether
> RRR reports should also be supported.
>
> My summary of the discussion is that we recommend to NOT include RRR
> reports in the current version of the base DOIC draft. 
>
> We still have some concerns with the granularity of control enabled by
> having just the two report types but the analysis of whether RRR
> reports are still needed can occur independent of the base DOIC
> draft.  If there is a determination that RRRs are needed in time to
> include in the base draft then it can be considered at that time.
>
> Based on this, I propose the following
>
> - Resolution to issue #23 is to remove RRR reports from the document.
> - Resolution to issue #55 is to add Realm reports (actually to
> redefine them per the above definition).
> - Resolution to issue #57 is that it no longer applies (as it deals
> with RRRs).
>
> There is also need for text describing the interaction between host
> and the realm reports.  I don't expect we will have consensus on this
> wording prior to the -02 draft being submitted.  To this end, I'll
> open a new issue to deal with the need for wording on the interaction.
>
> Regards,
>
> Steve
>


--------------090103040003030708080205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      The discussion should be captured in the minutes to the meeting. 
      I wasn't able to find them posted yet.

      

      Jouni, Lionel, what is the status of the minutes for the meeting?

      

      My reading of emails prior to the London meeting is different from
      yours.  I believe we had come to the conclusion that we needed
      host and realm (with the definition of realm as outlined below). 
      We were still discussing the need for Realm-Routed-Request
      reports.

      

      Regards,

      

      Steve

      

    
    
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
I don’t know what happend in London.

        
Can you please summarize the technical reasons
            that led to the London agreement.
            

        
E-mail discussions prior to London have clearly
            directed towards a report type that requests throttling of
            realm routed request messages (i.e. not containing a
            destination host) rather than a report type that requests
            throttling of messages routed towards a realm (no matter
            whether they contain a destination host or not).   

        
 

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Friday, March 21, 2014 3:33 PM

                To: dime@ietf.org

                Subject: [Dime] Resolution on action to discuss
                the need for Realm-Routed-Reports

          

        

        
 

        
All,

          

          Ben and I took the action item to discuss the need for the
          Realm-Routed-Reports (RRR) report type.

          

          As you may recall, the consensus coming out of the DIME WG
          meeting in London was to support two report types:

          

          - Host -- Impacting requests with a Destination-Host AVP
          matching the host in the overload report (with the host
          implicitly determined from the Origin-Host AVP of the answer
          message carrying the overload report).

          

          - Realm -- Impacting 100% of the requests with a
          Destination-Realm AVP matching the realm in the overload
          report (with the realm implicitly determine from the
          Origin-Realm of the answer message carrying the overload
          report).

          

          The action Ben and I took was to come back with an opinion on
          whether RRR reports should also be supported.

          

          My summary of the discussion is that we recommend to NOT
          include RRR reports in the current version of the base DOIC
          draft. 
          

          

          We still have some concerns with the granularity of control
          enabled by having just the two report types but the analysis
          of whether RRR reports are still needed can occur independent
          of the base DOIC draft.  If there is a determination that RRRs
          are needed in time to include in the base draft then it can be
          considered at that time.

          

          Based on this, I propose the following 

          

          - Resolution to issue #23 is to remove RRR reports from the
          document.

          - Resolution to issue #55 is to add Realm reports (actually to
          redefine them per the above definition).

          - Resolution to issue #57 is that it no longer applies (as it
          deals with RRRs).

          

          There is also need for text describing the interaction between
          host and the realm reports.  I don't expect we will have
          consensus on this wording prior to the -02 draft being
          submitted.  To this end, I'll open a new issue to deal with
          the need for wording on the interaction.

          

          Regards,

          

          Steve 

      

    

    

  


--------------090103040003030708080205--


From nobody Fri Mar 21 14:10:34 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 227321A0720 for ; Fri, 21 Mar 2014 14:10:32 -0700 (PDT)
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 zr80AOOkM4qM for ; Fri, 21 Mar 2014 14:10:27 -0700 (PDT)
Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 758551A0410 for ; Fri, 21 Mar 2014 14:10:27 -0700 (PDT)
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-9.tower-85.messagelabs.com!1395436217!35894268!1
X-Originating-IP: [20.137.2.180]
X-StarScan-Received: 
X-StarScan-Version: 6.11.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 3114 invoked from network); 21 Mar 2014 21:10:17 -0000
Received: from amer-mta103.csc.com (HELO amer-mta113.csc.com) (20.137.2.180) by server-9.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Mar 2014 21:10:17 -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 s2LLAGhm007666 for ; Fri, 21 Mar 2014 17:10:16 -0400
In-Reply-To: <081.d67cf98bf010626435cad725cb5095f0@trac.tools.ietf.org>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <081.d67cf98bf010626435cad725cb5095f0@trac.tools.ietf.org>
To: dime@ietf.org
MIME-Version: 1.0
X-KeepSent: 59AF5D5B:CF7EF2B0-85257CA2:0073F414; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012
From: Janet P Gunn 
Message-ID: 
Date: Fri, 21 Mar 2014 17:10:14 -0400
X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 03/21/2014 05:10:16 PM, Serialize complete at 03/21/2014 05:10:16 PM
Content-Type: multipart/alternative; boundary="=_alternative 00744BC985257CA2_="
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CUNgj7DCSARQEMQaVelXby9Rn-g
Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages
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: Fri, 21 Mar 2014 21:10:32 -0000

This is a multipart message in MIME format.
--=_alternative 00744BC985257CA2_=
Content-Type: text/plain; charset="US-ASCII"

Just a question.

In the phrase " it
    applies the traffic abatement based on the commonly supported/selected
    algorithm with the reporting node and the current overload condition."

Is it really the "current overload CONDITION", or the "current abatement 
REQUESTED"?

If the message is asking for a 10% reduction in traffic, that does not 
actually identify the "current overload condition".


Janet




From:   "dime issue tracker" 
To:     srdonovan@usdonovans.com
Cc:     dime@ietf.org
Date:   03/21/2014 09:33 AM
Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): 
OC-Supported-Features AVP in answer messages
Sent by:        "DiME" 



#30: OC-Supported-Features AVP in answer messages

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 We reached the tentative agreement in the DIME meeting on the following:

 OC-Supported-Features handling:

 Agreed: OC-Supported-Features AVP MUST be included in all answer messages
 (we had already agreed that it must be included in all request messages).
 Agreed: Reacting node advertises all supported algorithms;
 Agreed: Reporting node responds with the single algorithm it will be
 using;
 Agreed: Handling of other feature bits is defined in the extension drafts

 Based on this I believe we need the text changes outlined below.

 Let me know if I have missed any.

 If we agree on the text changes then we can close the issue and I'll
 update the document accordingly.

 Regards,

 Steve

 -----

 Section 5.3.2, paragraph 1:

 Change:

 The answer message
    initiating endpoint MAY announce as many supported capabilities as it
    has (the announced set is a subject to local policy and
    configuration). However, at least one of the announced capabilities
    MUST be the same as received in the request message.


 To:

 The reporting node MUST include the OC-Supported-Features AVP in all
 response messages for transactions where the request message included the
 OC-Supported-Features AVP.  The reporting node MUST announce support of
 the single algorithm that the reporting node will request the reacting
 node to use to mitigate overload instances.  The reporting node MUST NOT
 change the selected algorithm during a period of time that it is in an
 overload state and, as a result, is sending OC-OLR AVPs in answer
 messages.

     Note: There will always be at least one algorithm supported by both
 the reacting and reporting nodes as all nodes that support DOIC must
 support the loss algorithm defined in this document.

 The handling of feature bits in the OC-Feature-Vector AVP that are not
 associated with overload abatement algorithms MUST be specified by the
 extension that defines the feature.

 Paragraph 2:

 Change:

 The answer message initiating endpoint MUST NOT include any overload
    control solution defined AVPs into its answer messages if the request
    message initiating endpoint has not indicated support at the
    beginning of the created session (or transaction in a case of non-
    session state maintaining applications). The same also applies if
    none of the announced capabilities match between the two endpoints.

 To:

 The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR
 AVP or any other overload control AVPs defined in extension drafts in
 response messages for transaction where the request message does not
 include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features
 AVP in the request message indicates that the sender of the request
 message does not support DOIC.

 Section 5.5.2, Paragraph 1:

 Change:

    Once a reacting node receives an OC-OLR AVP from a reporting node, it
    applies the traffic abatement based on the commonly supported
    algorithm with the reporting node and the current overload condition.
    The reacting node learns the reporting node supported abatement
    algorithms directly from the received answer message containing the
    OC-Supported-Features AVP or indirectly remembering the previously
    used traffic abatement algorithm with the given reporting node.

 To: (removing the last portion of the last sentence)

    Once a reacting node receives an OC-OLR AVP from a reporting node, it
    applies the traffic abatement based on the commonly supported
    algorithm with the reporting node and the current overload condition.
    The reacting node learns the reporting node supported abatement
    algorithms directly from the received answer message containing the
    OC-Supported-Features AVP.

 -----

 +1, with a minor suggested edit:

 On Mar 17, 2014, at 2:03 PM, Steve Donovan 
 wrote:

 > Change:
 >    Once a reacting node receives an OC-OLR AVP from a reporting node, 
it
 >    applies the traffic abatement based on the commonly supported
 >    algorithm with the reporting node and the current overload 
condition.
 >    The reacting node learns the reporting node supported abatement
 >    algorithms directly from the received answer message containing the
 >    OC-Supported-Features AVP or indirectly remembering the previously
 >    used traffic abatement algorithm with the given reporting node.

 > To: (removing the last portion of the last sentence)
 >    Once a reacting node receives an OC-OLR AVP from a reporting node, 
it
 >    applies the traffic abatement based on the commonly supported

 s/"commonly supported"/selected

 "Commonly supported" is no longer descriptive. There may be several
 commonly supported algorithm, but the reporting node selects just one.

 >    algorithm with the reporting node and the current overload 
condition.
 >    The reacting node learns the reporting node supported abatement
 >    algorithms directly from the received answer message containing the
 >    OC-Supported-Features AVP.
 >

-- 
--------------------------------------+---------------------------
 Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: 
dime 

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


--=_alternative 00744BC985257CA2_=
Content-Type: text/html; charset="US-ASCII"

Just a question.



In the phrase "
it

    applies the traffic abatement based on the commonly supported/selected

    algorithm with the reporting node and the current overload
condition."



Is it really the "current overload CONDITION",
or the "current abatement REQUESTED"?



If the message is asking for a 10% reduction in traffic,
that does not actually identify the "current overload condition".





Janet









From:      
 "dime issue tracker"
<trac+dime@grenache.tools.ietf.org>

To:      
 srdonovan@usdonovans.com

Cc:      
 dime@ietf.org

Date:      
 03/21/2014 09:33 AM

Subject:    
   Re: [Dime] [dime]
#30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages

Sent by:    
   "DiME"
<dime-bounces@ietf.org>









#30: OC-Supported-Features AVP in answer messages



Changes (by srdonovan@usdonovans.com):



 * status:  new => closed

 * resolution:   => fixed





Comment:



 We reached the tentative agreement in the DIME meeting on the following:



 OC-Supported-Features handling:



 Agreed: OC-Supported-Features AVP MUST be included in all answer messages

 (we had already agreed that it must be included in all request messages).

 Agreed: Reacting node advertises all supported algorithms;

 Agreed: Reporting node responds with the single algorithm it will be

 using;

 Agreed: Handling of other feature bits is defined in the extension drafts



 Based on this I believe we need the text changes outlined below.



 Let me know if I have missed any.



 If we agree on the text changes then we can close the issue and I'll

 update the document accordingly.



 Regards,



 Steve



 -----



 Section 5.3.2, paragraph 1:



 Change:



 The answer message

    initiating endpoint MAY announce as many supported capabilities
as it

    has (the announced set is a subject to local policy and

    configuration). However, at least one of the announced capabilities

    MUST be the same as received in the request message.





 To:



 The reporting node MUST include the OC-Supported-Features AVP in all

 response messages for transactions where the request message included
the

 OC-Supported-Features AVP.  The reporting node MUST announce support
of

 the single algorithm that the reporting node will request the reacting

 node to use to mitigate overload instances.  The reporting node MUST
NOT

 change the selected algorithm during a period of time that it is in an

 overload state and, as a result, is sending OC-OLR AVPs in answer

 messages.



     Note: There will always be at least one algorithm supported
by both

 the reacting and reporting nodes as all nodes that support DOIC must

 support the loss algorithm defined in this document.



 The handling of feature bits in the OC-Feature-Vector AVP that are not

 associated with overload abatement algorithms MUST be specified by the

 extension that defines the feature.



 Paragraph 2:



 Change:



 The answer message initiating endpoint MUST NOT include any overload

    control solution defined AVPs into its answer messages if
the request

    message initiating endpoint has not indicated support at
the

    beginning of the created session (or transaction in a case
of non-

    session state maintaining applications). The same also applies
if

    none of the announced capabilities match between the two
endpoints.



 To:



 The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR

 AVP or any other overload control AVPs defined in extension drafts in

 response messages for transaction where the request message does not

 include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features

 AVP in the request message indicates that the sender of the request

 message does not support DOIC.



 Section 5.5.2, Paragraph 1:



 Change:



    Once a reacting node receives an OC-OLR AVP from a reporting
node, it

    applies the traffic abatement based on the commonly supported

    algorithm with the reporting node and the current overload
condition.

    The reacting node learns the reporting node supported abatement

    algorithms directly from the received answer message containing
the

    OC-Supported-Features AVP or indirectly remembering the previously

    used traffic abatement algorithm with the given reporting
node.



 To: (removing the last portion of the last sentence)



    Once a reacting node receives an OC-OLR AVP from a reporting
node, it

    applies the traffic abatement based on the commonly supported

    algorithm with the reporting node and the current overload
condition.

    The reacting node learns the reporting node supported abatement

    algorithms directly from the received answer message containing
the

    OC-Supported-Features AVP.



 -----



 +1, with a minor suggested edit:



 On Mar 17, 2014, at 2:03 PM, Steve Donovan <srdonovan@usdonovans.com>

 wrote:



 > Change:

 >    Once a reacting node receives an OC-OLR AVP from a reporting
node, it

 >    applies the traffic abatement based on the commonly
supported

 >    algorithm with the reporting node and the current overload
condition.

 >    The reacting node learns the reporting node supported
abatement

 >    algorithms directly from the received answer message
containing the

 >    OC-Supported-Features AVP or indirectly remembering
the previously

 >    used traffic abatement algorithm with the given reporting
node.



 > To: (removing the last portion of the last sentence)

 >    Once a reacting node receives an OC-OLR AVP from a reporting
node, it

 >    applies the traffic abatement based on the commonly
supported



 s/"commonly supported"/selected



 "Commonly supported" is no longer descriptive. There may be
several

 commonly supported algorithm, but the reporting node selects just one.



 >    algorithm with the reporting node and the current overload
condition.

 >    The reacting node learns the reporting node supported
abatement

 >    algorithms directly from the received answer message
containing the

 >    OC-Supported-Features AVP.

 >



-- 

--------------------------------------+---------------------------

 Reporter:  lionel.morand@orange.com  |      
Owner:  Ulrich Wiehe

     Type:  defect            
       |      Status:  closed

 Priority:  major              
      |   Milestone:

Component:  draft-docdt-dime-ovli     |     Version:

 Severity:  Active WG Document        |  Resolution:
 fixed

 Keywords:                  
         |

--------------------------------------+---------------------------



Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/30#comment:1>

dime <http://tools.ietf.org/wg/dime/>



_______________________________________________

DiME mailing list

DiME@ietf.org

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




--=_alternative 00744BC985257CA2_=--


From nobody Fri Mar 21 19:33:52 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 1D7C41A09B1 for ; Fri, 21 Mar 2014 19:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 6QF4Ww6RCJvY for ; Fri, 21 Mar 2014 19:33:48 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 38E771A0564 for ; Fri, 21 Mar 2014 19:33:48 -0700 (PDT)
Received: by mail-pd0-f177.google.com with SMTP id y10so3057625pdj.36 for ; Fri, 21 Mar 2014 19:33:38 -0700 (PDT)
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=LBR2kScqFTVYG2xUlS85BDLXdzI3k7goKLeKg2/zPxg=; b=hZuxlKPtr38VPqwvyYOge+6LdWWnVeQNPlKgaiiBpuetpf94oZnx20owv0/ayOJuMb 4QArg0F9S8NfYYPU28Z42vQMyVQuDVOQ2kZa2URix7Ht5Lmw/gMsPTrFIok8fx+sx9Bv bgS6XMJ6NWo3IvygSxUoPAIruDdv775ivCmmkriQZJvY6tEUIaaTABhgmzs7jKxl4+i4 DzO1aWa5sNmK06+8J9/Qq9ZuAkzUAj0sbw66lVHOtuQYU6l/mvXOG0bAFa2TZgCtgjRE f11PymTpOhcGItgU56rGhcvcCaKwn2odMzFckbMuTQUfm00xJFKL0QqtKrfbfHa7UOWI oSaA==
X-Received: by 10.68.0.35 with SMTP id 3mr56877427pbb.52.1395455618623; Fri, 21 Mar 2014 19:33:38 -0700 (PDT)
Received: from [10.64.80.209] ([124.127.168.211]) by mx.google.com with ESMTPSA id eb5sm34369716pad.22.2014.03.21.19.33.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 19:33:37 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: 
Date: Sat, 22 Mar 2014 10:33:31 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com> 
To: Ben Campbell 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/FGBOXvVNLTagScczoCH8pk-9QnU
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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, 22 Mar 2014 02:33:50 -0000

Ben,

On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:

>=20
> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  =
wrote:
>=20
>>>=20
>>> Consider the case of a Diameter _relay_ that supports DOIC. It is =
not aware of any application-specific rules about m-bits. It receives an =
OC-Supported-Features or an OC-OLR that has a mandatory AVP that it =
doesn't recognize. Logically, it should probably ignore the entire =
OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a =
relay, it's not going to reject the message. Rather it's likely to try =
to apply the OC-Supported-Features or OC-OLR incorrectly.
>>=20
>> RFC6733 also says that relays perform not do any application level
>> processing. If a relay supports DOIC and does something goofy that
>> is left for implementation, we should no care nor try to fix the
>> situation. The implementation is already bending the rules in that
>> case.
>=20
> Hi Jouni,
>=20
> I'm not talking about the case of the relay doing something goofy. =
Rather, I mean when a relay tries to perform basic DOIC processing of an =
OLR as described in the base DOIC spec, but ignores some extension AVP =
that changes the meaning of the OLR. It's not bending the rules so much =
as failing to recognize someone else changing the rules.

Ah, I see your point. But if one adds AVPs to the default algorithm
that change he behaviour and does not a) declare it as a new algorithm
or b) add a new supported feature flag, then that is a proprietary
(broken) implementation. We cannot really protect against those..

- Jouni=


From nobody Fri Mar 21 19:38: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 7459A1A0564 for ; Fri, 21 Mar 2014 19:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 p-QaMCe2rT9Q for ; Fri, 21 Mar 2014 19:38:39 -0700 (PDT)
Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 248FF1A0A09 for ; Fri, 21 Mar 2014 19:38:39 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id r10so3069464pdi.30 for ; Fri, 21 Mar 2014 19:38:29 -0700 (PDT)
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=ORq2d9CQX3iGPkjB5R9Y+xMgvmoTqoRhfedA3tZfdrU=; b=k1srYufEAWXFi8Q55hpf+j7WL/sGF7qLvYjMPKKZAP3qnC7SGCP6yjMFyEAtisEo9b YGfYXV7gtrMrAPaGYyKzY8siWCjh1uSyzjh4eIJR9TeU0HHa30b8fGfZk7aGTThH8LHG k6+OPJwmatJ08sMSxFmsajoPaooxnToxy3Dv03wtPNnpoeen6SD6cKeAFbFYedBQPWy3 JY39YPtsPTSnm79mBmvZfYsR3D4l2ndLPP7nrOQjiDdDVkil6oOtXuvkR2wwNB7rmJ1N WvTklRG6odIUFcIpnkbnddSWQIwYd1ppK7bQyKdqurfApZns3fK1/L6AP26xBPuTfrRn 6cFA==
X-Received: by 10.67.14.69 with SMTP id fe5mr58059764pad.120.1395455909770; Fri, 21 Mar 2014 19:38:29 -0700 (PDT)
Received: from [10.64.80.209] ([124.127.168.211]) by mx.google.com with ESMTPSA id j3sm12598893pbh.38.2014.03.21.19.38.26 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Mar 2014 19:38:29 -0700 (PDT)
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: <53288284.5040606@usdonovans.com>
Date: Sat, 22 Mar 2014 10:38:19 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1FBfcvMKt2KbUxsi_uc2BvV8Atw
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 22 Mar 2014 02:38:41 -0000

Lets have it explicit then. Use '<' and '>' to make the position
fixed.

- Jouni

On Mar 19, 2014, at 1:29 AM, Steve Donovan  =
wrote:

> I'm ok with either direction but generally lean toward being explicit.
>=20
> Do we have other opinions? =20
>=20
> Steve
> On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
>> Hello,
>> I think the agreement tendency is the contrary: OC-Report-Type is not =
required, while default value is Host. i.e. it will remain as it is now =
in the draft.
>> This may be of some advantage for some applications that may only use =
Host, as long as they may never generate Realm reports.
>> If there is consensus on this, I will go with this.
>> Best regards
>> /MCruz
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>> Sent: martes, 18 de marzo de 2014 17:47
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> All,
>>=20
>> Do we have consensus that the OC-Report-Type AVP is required?
>>=20
>> If so then one change would be as indicated in the syntax definition =
proposed by Lionel.  We would also remove wording on the default value.
>>=20
>> Jouni,
>>=20
>> How do we indicate a fixed position for an AVP? =20
>>=20
>> I presonally don't see this as critical but we can add this =
requirement if there is consensus.
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>> On 2/28/14 10:27 AM, Jouni Korhonen wrote:
>> =20
>> Hi,
>> =20
>> How having the AVP could be less error prone if it has a default
>> value and the receiver knows exactly how to proceed when the AVP
>> is not present?
>> =20
>> If a node does not include it when it should, the implementation
>> is broken. Wouldn't a broken node be able to put wrong report
>> type into the AVP even if the AVP is mandatory?
>> =20
>> Anyway, if it is my statement keeping issue #54 still open, consider
>> it resolved from my side. I am OK making the OC-Report-Type AVP as
>> required/mandatory AVP. Should we also consider it having a fixed
>> position just after the OC-Sequence-Number AVP as well since it is
>> going to in every OC-OLR?
>> =20
>> - Jouni
>> =20
>> =20
>> =20
>> On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome =
 wrote:
>> =20
>> =20
>> Hello all,
>> =20
>> I understand JJ point of view, but I still tend to prefer to make it =
mandatory, since I think this is less error-prone, since the only node =
that knows the requested Report-Type is the reporting, if for any reason =
a reporting is omitting it (since it is optional), it will be always =
interpreted as HOST, but this type may be wrong.
>> =20
>> I think DEFAULT values should never be error-prone, but used in =
"general cases", as a simplification, like e.g. a default for the =
Validity-Duration. Default Validity-Duration will never be an "error", =
it could be not the best value (compared with another value perfectly =
tuned to reporting node overload situation) but never the use of a =
Default value should lead to an erroneous behavior.
>> =20
>> Best regards
>> /MCruz
>> =20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>> Sent: viernes, 14 de febrero de 2014 23:13
>> To: Jouni Korhonen
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> I actually prefer making it mandatory. The cost of adding it is =
trivial--even more so for a reporting node that only supports the =
default. The value of having it is less opportunity for interop errors.
>> =20
>> On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  =
wrote:
>> =20
>> =20
>> Agree that it is a small optimization, which I put there because at=20=

>> the beginning there seemed to be a lot of worry on every extra AVP =
;-)
>> =20
>> I prefer having the AVP optional but with a default value just like =
it=20
>> is now. We have the same for the reduction percentage and the =
validity=20
>> time as well.
>> =20
>> - Jouni
>> =20
>> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:
>> =20
>> Hi Mcruz
>> =20
>> The current description indicates that when not present the OLR is of =
type Host, which was fine for me and keeps my preference.=20
>> We may have  deployments where Realm OLR is not used, or where =
statistically the HOST type is the most frequent, so to have the grouped =
OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a =
small optimization.
>> =20
>> Best regards
>> =20
>> JJacques
>> =20
>> =20
>> =20
>> =20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de=20
>> lionel.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =
=C0 :=20
>> dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]=20=

>> [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> Hi Maria Cruz,
>> =20
>> I'm assuming that you mean "required" instead of "mandatory", right?
>> =20
>> So instead of:
>> =20
>> OC-OLR ::=3D < AVP Header: TBD2 >
>>            < OC-Sequence-Number >
>>            [ OC-Report-Type ]
>>            [ OC-Reduction-Percentage ]
>>            [ OC-Validity-Duration ]
>>          * [ AVP ]
>> =20
>> You would prefer:
>> =20
>> OC-OLR ::=3D < AVP Header: TBD2 >
>>            < OC-Sequence-Number >
>>            { OC-Report-Type }
>>            [ OC-Reduction-Percentage ]
>>            [ OC-Validity-Duration ]
>>          * [ AVP ]
>> =20
>> And I'm fine with this proposal.
>> =20
>> Cheers,
>> =20
>> Lionel
>> =20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue=20
>> tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :=20
>> maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime]=20=

>> [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> #54: OC-Report-Type as mandatory AVP
>> =20
>> Now in chapter 4.6:
>> =20
>>  The default value of the OC-Report-Type AVP is 0 (i.e. the host
>>  report).
>> =20
>> This AVP is always required, right? Then, I think it is more precise =
that  we define this AVP as mandatory.
>> =20
>> --
>> -----------------------------------------------+---------------------
>> -----------------------------------------------+---
>> -----------------------------------------------+---
>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>   Type:  defect                             |  Bartolom=E9
>> Priority:  major                              |     Status:  new
>> Component:  draft-docdt-dime-ovli              |  Milestone:
>> Severity:  Active WG Document                 |    Version:  1.0
>>                                             |   Keywords:
>> -----------------------------------------------+---------------------
>> -----------------------------------------------+---
>> -----------------------------------------------+---
>> =20
>> Ticket URL: 
>> 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
>> _______________________________________________
>> 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
>> =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
>> =20
>> =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Fri Mar 21 22:36: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 CF5EB1A0473 for ; Fri, 21 Mar 2014 22:36:39 -0700 (PDT)
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 Kf8zy8rjxwVk for ; Fri, 21 Mar 2014 22:36:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id B24571A07A8 for ; Fri, 21 Mar 2014 22:36:36 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2M5aFWo032525 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 22 Mar 2014 00:36:17 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: 
Date: Sat, 22 Mar 2014 00:36:15 -0500
X-Mao-Original-Outgoing-Id: 417159375.191007-682bd30dd7548b4118a0c5ac726affc7
Content-Transfer-Encoding: quoted-printable
Message-Id: <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>  
To: Jouni Korhonen 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Z6W2dXbvJ9Kha90ZI0pK7lI53-Y
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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, 22 Mar 2014 05:36:40 -0000

On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  =
wrote:

>=20
> Ben,
>=20
> On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:
>=20
>>=20
>> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  =
wrote:
>>=20
>>>>=20
>>>> Consider the case of a Diameter _relay_ that supports DOIC. It is =
not aware of any application-specific rules about m-bits. It receives an =
OC-Supported-Features or an OC-OLR that has a mandatory AVP that it =
doesn't recognize. Logically, it should probably ignore the entire =
OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a =
relay, it's not going to reject the message. Rather it's likely to try =
to apply the OC-Supported-Features or OC-OLR incorrectly.
>>>=20
>>> RFC6733 also says that relays perform not do any application level
>>> processing. If a relay supports DOIC and does something goofy that
>>> is left for implementation, we should no care nor try to fix the
>>> situation. The implementation is already bending the rules in that
>>> case.
>>=20
>> Hi Jouni,
>>=20
>> I'm not talking about the case of the relay doing something goofy. =
Rather, I mean when a relay tries to perform basic DOIC processing of an =
OLR as described in the base DOIC spec, but ignores some extension AVP =
that changes the meaning of the OLR. It's not bending the rules so much =
as failing to recognize someone else changing the rules.
>=20
> Ah, I see your point. But if one adds AVPs to the default algorithm
> that change he behaviour and does not a) declare it as a new algorithm
> or b) add a new supported feature flag, then that is a proprietary
> (broken) implementation. We cannot really protect against those..

I think that's reasonable. My original point was that extensions should =
not try to use the m-bit for that purpose. If they have something that =
is not backwards compatible, it needs to be negotiated in the feature =
vector.



From nobody Sat Mar 22 04:44: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 30B2F1A08A4 for ; Sat, 22 Mar 2014 04:44:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.009
X-Spam-Level: 
X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 Z33Qd67fBJNx for ; Sat, 22 Mar 2014 04:44:01 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id F0B851A06B4 for ; Sat, 22 Mar 2014 04:44:00 -0700 (PDT)
Received: from WTL-EXCHP-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa]) by wtl-exchp-2.sandvine.com ([fe80::68ac:f071:19ff:3455%20]) with mapi id 14.01.0339.001; Sat, 22 Mar 2014 07:44:00 -0400
From: Dave Dolson 
To: "'srdonovan@usdonovans.com'" , "'dime@ietf.org'" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRcQDA2ffHLo0HUCi0RgLiLXnGA==
Date: Sat, 22 Mar 2014 11:43:59 +0000
Message-ID: 
In-Reply-To: <532CA99F.4070409@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.194.115]
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9818AD87AFwtlexchp1sandvi_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/J3GF2WiQt03PNnfWMVvABEErIkk
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 22 Mar 2014 11:44:03 -0000

--_000_E8355113905631478EFF04F5AA706E9818AD87AFwtlexchp1sandvi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SXQgaXMgZGlmZmljdWx0IHRvIGp1ZGdlIHRoaXMgaXNzdWUgd2l0aG91dCBrbm93aW5nIGhvdyB0
aGUgcmVwb3J0ZWQgdmFsdWVzIGFyZSB0byBiZSByZXNvbHZlZCB3aGVuIGNvbnRyYWRpY3Rvcnku
DQoNClRvIHNlbmQgYSByZXF1ZXN0IHdpdGggYm90aCByZWFsbSBhbmQgaG9zdCBuYW1lLCBhbmQg
aGF2aW5nIHJlcG9ydGVkIHJlYWxtIGFuZCBob3N0IHBlcmNlbnRhZ2VzLCB3aGF0IHNob3VsZCBi
ZSBkb25lPw0KDQpEb2VzIHRoZSBjbGllbnQgaGF2ZSB0byBrZWVwIHRyYWNrIG9mIGhvdyBtdWNo
IGl0IGhhcyBzZW50IHRvIGVhY2ggaG9zdCwgYW5kIGFsc28gdGhlIHJlYWxtIGFzIGEgd2hvbGU/
DQoNClRoaXMgbmVlZHMgdG8gYmUgcGFydCBvZiB0aGUgc3BlYywgbm90IGxlZnQgdG8gdmVuZG9y
LXNwZWNpZmljIGltcGxlbWVudGF0aW9uLCBiZWNhdXNlIHRoZSBvdmVybG9hZGVkIHJlYWxtL25v
ZGUgbmVlZHMgYSBtb2RlbCBvZiBob3cgdGhlIGNsaWVudCB3aWxsIHJlYWN0Lg0KDQoNClRoZSBh
cHByb2FjaCBvZiBoYXZpbmcgZmVlZGJhY2sgZm9yIHJlYWxtLW9ubHkgbWVzc2FnZXMgbWFkZSBp
dCBlYXNpZXIgdG8gdW5kZXJzdGFuZCB3aGF0IHRoZSBjbGllbnQgc2hvdWxkIGRvLg0KDQotRGF2
ZQ0KDQoNCg0KRnJvbTogU3RldmUgRG9ub3ZhbiBbbWFpbHRvOnNyZG9ub3ZhbkB1c2Rvbm92YW5z
LmNvbV0NClNlbnQ6IEZyaWRheSwgTWFyY2ggMjEsIDIwMTQgMDU6MDUgUE0NClRvOiBkaW1lQGll
dGYub3JnIDxkaW1lQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtEaW1lXSBSZXNvbHV0aW9uIG9u
IGFjdGlvbiB0byBkaXNjdXNzIHRoZSBuZWVkIGZvciBSZWFsbS1Sb3V0ZWQtUmVwb3J0cw0KDQpV
bHJpY2gsDQoNClRoZSBkaXNjdXNzaW9uIHNob3VsZCBiZSBjYXB0dXJlZCBpbiB0aGUgbWludXRl
cyB0byB0aGUgbWVldGluZy4gIEkgd2Fzbid0IGFibGUgdG8gZmluZCB0aGVtIHBvc3RlZCB5ZXQu
DQoNCkpvdW5pLCBMaW9uZWwsIHdoYXQgaXMgdGhlIHN0YXR1cyBvZiB0aGUgbWludXRlcyBmb3Ig
dGhlIG1lZXRpbmc/DQoNCk15IHJlYWRpbmcgb2YgZW1haWxzIHByaW9yIHRvIHRoZSBMb25kb24g
bWVldGluZyBpcyBkaWZmZXJlbnQgZnJvbSB5b3Vycy4gIEkgYmVsaWV2ZSB3ZSBoYWQgY29tZSB0
byB0aGUgY29uY2x1c2lvbiB0aGF0IHdlIG5lZWRlZCBob3N0IGFuZCByZWFsbSAod2l0aCB0aGUg
ZGVmaW5pdGlvbiBvZiByZWFsbSBhcyBvdXRsaW5lZCBiZWxvdykuICBXZSB3ZXJlIHN0aWxsIGRp
c2N1c3NpbmcgdGhlIG5lZWQgZm9yIFJlYWxtLVJvdXRlZC1SZXF1ZXN0IHJlcG9ydHMuDQoNClJl
Z2FyZHMsDQoNClN0ZXZlDQoNCk9uIDMvMjEvMTQgMTA6MDkgQU0sIFdpZWhlLCBVbHJpY2ggKE5T
TiAtIERFL011bmljaCkgd3JvdGU6DQpTdGV2ZSwNCg0KSSBkb27igJl0IGtub3cgd2hhdCBoYXBw
ZW5kIGluIExvbmRvbi4NCkNhbiB5b3UgcGxlYXNlIHN1bW1hcml6ZSB0aGUgdGVjaG5pY2FsIHJl
YXNvbnMgdGhhdCBsZWQgdG8gdGhlIExvbmRvbiBhZ3JlZW1lbnQuDQpFLW1haWwgZGlzY3Vzc2lv
bnMgcHJpb3IgdG8gTG9uZG9uIGhhdmUgY2xlYXJseSBkaXJlY3RlZCB0b3dhcmRzIGEgcmVwb3J0
IHR5cGUgdGhhdCByZXF1ZXN0cyB0aHJvdHRsaW5nIG9mIHJlYWxtIHJvdXRlZCByZXF1ZXN0IG1l
c3NhZ2VzIChpLmUuIG5vdCBjb250YWluaW5nIGEgZGVzdGluYXRpb24gaG9zdCkgcmF0aGVyIHRo
YW4gYSByZXBvcnQgdHlwZSB0aGF0IHJlcXVlc3RzIHRocm90dGxpbmcgb2YgbWVzc2FnZXMgcm91
dGVkIHRvd2FyZHMgYSByZWFsbSAobm8gbWF0dGVyIHdoZXRoZXIgdGhleSBjb250YWluIGEgZGVz
dGluYXRpb24gaG9zdCBvciBub3QpLg0KDQpVbHJpY2gNCg0KRnJvbTogRGlNRSBbbWFpbHRvOmRp
bWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGV4dCBTdGV2ZSBEb25vdmFuDQpTZW50
OiBGcmlkYXksIE1hcmNoIDIxLCAyMDE0IDM6MzMgUE0NClRvOiBkaW1lQGlldGYub3JnPG1haWx0
bzpkaW1lQGlldGYub3JnPg0KU3ViamVjdDogW0RpbWVdIFJlc29sdXRpb24gb24gYWN0aW9uIHRv
IGRpc2N1c3MgdGhlIG5lZWQgZm9yIFJlYWxtLVJvdXRlZC1SZXBvcnRzDQoNCkFsbCwNCg0KQmVu
IGFuZCBJIHRvb2sgdGhlIGFjdGlvbiBpdGVtIHRvIGRpc2N1c3MgdGhlIG5lZWQgZm9yIHRoZSBS
ZWFsbS1Sb3V0ZWQtUmVwb3J0cyAoUlJSKSByZXBvcnQgdHlwZS4NCg0KQXMgeW91IG1heSByZWNh
bGwsIHRoZSBjb25zZW5zdXMgY29taW5nIG91dCBvZiB0aGUgRElNRSBXRyBtZWV0aW5nIGluIExv
bmRvbiB3YXMgdG8gc3VwcG9ydCB0d28gcmVwb3J0IHR5cGVzOg0KDQotIEhvc3QgLS0gSW1wYWN0
aW5nIHJlcXVlc3RzIHdpdGggYSBEZXN0aW5hdGlvbi1Ib3N0IEFWUCBtYXRjaGluZyB0aGUgaG9z
dCBpbiB0aGUgb3ZlcmxvYWQgcmVwb3J0ICh3aXRoIHRoZSBob3N0IGltcGxpY2l0bHkgZGV0ZXJt
aW5lZCBmcm9tIHRoZSBPcmlnaW4tSG9zdCBBVlAgb2YgdGhlIGFuc3dlciBtZXNzYWdlIGNhcnJ5
aW5nIHRoZSBvdmVybG9hZCByZXBvcnQpLg0KDQotIFJlYWxtIC0tIEltcGFjdGluZyAxMDAlIG9m
IHRoZSByZXF1ZXN0cyB3aXRoIGEgRGVzdGluYXRpb24tUmVhbG0gQVZQIG1hdGNoaW5nIHRoZSBy
ZWFsbSBpbiB0aGUgb3ZlcmxvYWQgcmVwb3J0ICh3aXRoIHRoZSByZWFsbSBpbXBsaWNpdGx5IGRl
dGVybWluZSBmcm9tIHRoZSBPcmlnaW4tUmVhbG0gb2YgdGhlIGFuc3dlciBtZXNzYWdlIGNhcnJ5
aW5nIHRoZSBvdmVybG9hZCByZXBvcnQpLg0KDQpUaGUgYWN0aW9uIEJlbiBhbmQgSSB0b29rIHdh
cyB0byBjb21lIGJhY2sgd2l0aCBhbiBvcGluaW9uIG9uIHdoZXRoZXIgUlJSIHJlcG9ydHMgc2hv
dWxkIGFsc28gYmUgc3VwcG9ydGVkLg0KDQpNeSBzdW1tYXJ5IG9mIHRoZSBkaXNjdXNzaW9uIGlz
IHRoYXQgd2UgcmVjb21tZW5kIHRvIE5PVCBpbmNsdWRlIFJSUiByZXBvcnRzIGluIHRoZSBjdXJy
ZW50IHZlcnNpb24gb2YgdGhlIGJhc2UgRE9JQyBkcmFmdC4NCg0KV2Ugc3RpbGwgaGF2ZSBzb21l
IGNvbmNlcm5zIHdpdGggdGhlIGdyYW51bGFyaXR5IG9mIGNvbnRyb2wgZW5hYmxlZCBieSBoYXZp
bmcganVzdCB0aGUgdHdvIHJlcG9ydCB0eXBlcyBidXQgdGhlIGFuYWx5c2lzIG9mIHdoZXRoZXIg
UlJSIHJlcG9ydHMgYXJlIHN0aWxsIG5lZWRlZCBjYW4gb2NjdXIgaW5kZXBlbmRlbnQgb2YgdGhl
IGJhc2UgRE9JQyBkcmFmdC4gIElmIHRoZXJlIGlzIGEgZGV0ZXJtaW5hdGlvbiB0aGF0IFJSUnMg
YXJlIG5lZWRlZCBpbiB0aW1lIHRvIGluY2x1ZGUgaW4gdGhlIGJhc2UgZHJhZnQgdGhlbiBpdCBj
YW4gYmUgY29uc2lkZXJlZCBhdCB0aGF0IHRpbWUuDQoNCkJhc2VkIG9uIHRoaXMsIEkgcHJvcG9z
ZSB0aGUgZm9sbG93aW5nDQoNCi0gUmVzb2x1dGlvbiB0byBpc3N1ZSAjMjMgaXMgdG8gcmVtb3Zl
IFJSUiByZXBvcnRzIGZyb20gdGhlIGRvY3VtZW50Lg0KLSBSZXNvbHV0aW9uIHRvIGlzc3VlICM1
NSBpcyB0byBhZGQgUmVhbG0gcmVwb3J0cyAoYWN0dWFsbHkgdG8gcmVkZWZpbmUgdGhlbSBwZXIg
dGhlIGFib3ZlIGRlZmluaXRpb24pLg0KLSBSZXNvbHV0aW9uIHRvIGlzc3VlICM1NyBpcyB0aGF0
IGl0IG5vIGxvbmdlciBhcHBsaWVzIChhcyBpdCBkZWFscyB3aXRoIFJSUnMpLg0KDQpUaGVyZSBp
cyBhbHNvIG5lZWQgZm9yIHRleHQgZGVzY3JpYmluZyB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBo
b3N0IGFuZCB0aGUgcmVhbG0gcmVwb3J0cy4gIEkgZG9uJ3QgZXhwZWN0IHdlIHdpbGwgaGF2ZSBj
b25zZW5zdXMgb24gdGhpcyB3b3JkaW5nIHByaW9yIHRvIHRoZSAtMDIgZHJhZnQgYmVpbmcgc3Vi
bWl0dGVkLiAgVG8gdGhpcyBlbmQsIEknbGwgb3BlbiBhIG5ldyBpc3N1ZSB0byBkZWFsIHdpdGgg
dGhlIG5lZWQgZm9yIHdvcmRpbmcgb24gdGhlIGludGVyYWN0aW9uLg0KDQpSZWdhcmRzLA0KDQpT
dGV2ZQ0KDQo=

--_000_E8355113905631478EFF04F5AA706E9818AD87AFwtlexchp1sandvi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IiNGRkZG
RkYiIHRleHQ9IiMwMDAwMDAiPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkl0IGlzIGRpZmZpY3VsdCB0byBqdWRnZSB0aGlzIGlzc3VlIHdpdGhvdXQga25vd2lu
ZyBob3cgdGhlIHJlcG9ydGVkIHZhbHVlcyBhcmUgdG8gYmUgcmVzb2x2ZWQgd2hlbiBjb250cmFk
aWN0b3J5Lg0KPGJyPg0KPGJyPg0KVG8gc2VuZCBhIHJlcXVlc3Qgd2l0aCBib3RoIHJlYWxtIGFu
ZCBob3N0IG5hbWUsIGFuZCBoYXZpbmcgcmVwb3J0ZWQgcmVhbG0gYW5kIGhvc3QgcGVyY2VudGFn
ZXMsIHdoYXQgc2hvdWxkIGJlIGRvbmU/PGJyPg0KPGJyPg0KRG9lcyB0aGUgY2xpZW50IGhhdmUg
dG8ga2VlcCB0cmFjayBvZiBob3cgbXVjaCBpdCBoYXMgc2VudCB0byBlYWNoIGhvc3QsIGFuZCBh
bHNvIHRoZSByZWFsbSBhcyBhIHdob2xlPzxicj4NCjxicj4NClRoaXMgbmVlZHMgdG8gYmUgcGFy
dCBvZiB0aGUgc3BlYywgbm90IGxlZnQgdG8gdmVuZG9yLXNwZWNpZmljIGltcGxlbWVudGF0aW9u
LCBiZWNhdXNlIHRoZSBvdmVybG9hZGVkIHJlYWxtL25vZGUgbmVlZHMgYSBtb2RlbCBvZiBob3cg
dGhlIGNsaWVudCB3aWxsIHJlYWN0Lg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGFwcHJvYWNoIG9m
IGhhdmluZyBmZWVkYmFjayBmb3IgcmVhbG0tb25seSBtZXNzYWdlcyBtYWRlIGl0IGVhc2llciB0
byB1bmRlcnN0YW5kIHdoYXQgdGhlIGNsaWVudCBzaG91bGQgZG8uPGJyPg0KPGJyPg0KLURhdmU8
YnI+DQo8YnI+DQo8L2ZvbnQ+PGJyPg0KJm5ic3A7PGJyPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v
bmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw
aW4iPg0KPGZvbnQgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo
b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxiPkZyb208L2I+OiBTdGV2ZSBEb25v
dmFuIFttYWlsdG86c3Jkb25vdmFuQHVzZG9ub3ZhbnMuY29tXQ0KPGJyPg0KPGI+U2VudDwvYj46
IEZyaWRheSwgTWFyY2ggMjEsIDIwMTQgMDU6MDUgUE08YnI+DQo8Yj5UbzwvYj46IGRpbWVAaWV0
Zi5vcmcgJmx0O2RpbWVAaWV0Zi5vcmcmZ3Q7IDxicj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW0Rp
bWVdIFJlc29sdXRpb24gb24gYWN0aW9uIHRvIGRpc2N1c3MgdGhlIG5lZWQgZm9yIFJlYWxtLVJv
dXRlZC1SZXBvcnRzDQo8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0KPC9kaXY+DQo8Zm9udCBmYWNl
PSJUaW1lcyBOZXcgUm9tYW4sIFRpbWVzLCBzZXJpZiI+VWxyaWNoLDxicj4NCjxicj4NClRoZSBk
aXNjdXNzaW9uIHNob3VsZCBiZSBjYXB0dXJlZCBpbiB0aGUgbWludXRlcyB0byB0aGUgbWVldGlu
Zy4mbmJzcDsgSSB3YXNuJ3QgYWJsZSB0byBmaW5kIHRoZW0gcG9zdGVkIHlldC48YnI+DQo8YnI+
DQpKb3VuaSwgTGlvbmVsLCB3aGF0IGlzIHRoZSBzdGF0dXMgb2YgdGhlIG1pbnV0ZXMgZm9yIHRo
ZSBtZWV0aW5nPzxicj4NCjxicj4NCk15IHJlYWRpbmcgb2YgZW1haWxzIHByaW9yIHRvIHRoZSBM
b25kb24gbWVldGluZyBpcyBkaWZmZXJlbnQgZnJvbSB5b3Vycy4mbmJzcDsgSSBiZWxpZXZlIHdl
IGhhZCBjb21lIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgd2UgbmVlZGVkIGhvc3QgYW5kIHJlYWxt
ICh3aXRoIHRoZSBkZWZpbml0aW9uIG9mIHJlYWxtIGFzIG91dGxpbmVkIGJlbG93KS4mbmJzcDsg
V2Ugd2VyZSBzdGlsbCBkaXNjdXNzaW5nIHRoZSBuZWVkIGZvciBSZWFsbS1Sb3V0ZWQtUmVxdWVz
dCByZXBvcnRzLjxicj4NCjxicj4NClJlZ2FyZHMsPGJyPg0KPGJyPg0KU3RldmU8YnI+DQo8YnI+
DQo8L2ZvbnQ+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDMvMjEvMTQgMTA6MDkg
QU0sIFdpZWhlLCBVbHJpY2ggKE5TTiAtIERFL011bmljaCkgd3JvdGU6PGJyPg0KPC9kaXY+DQo8
YmxvY2txdW90ZSBjaXRlPSJtaWQ6NUJDQkExRkMyQjdGMEI0QzlEOTM1NTcyRDkwMDA2NjgxNTFD
OThBN0BERU1VTUJYMDE0Lm5zbi1pbnRyYS5uZXQiIHR5cGU9ImNpdGUiPg0KPG1ldGEgbmFtZT0i
R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQNCiAgICAgICAg
bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj
ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2
IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy
IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsN
CglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNt
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBz
cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp
bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl
eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxl
LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np
emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7
fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp
ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s
Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh
dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlN0ZXZlLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCIgbGFuZz0iRU4tVVMiPkkg
ZG9u4oCZdCBrbm93IHdoYXQgaGFwcGVuZCBpbiBMb25kb24uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj5DYW4geW91IHBsZWFzZSBzdW1tYXJpemUgdGhlIHRlY2hu
aWNhbCByZWFzb25zIHRoYXQgbGVkIHRvIHRoZSBMb25kb24gYWdyZWVtZW50Lg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm
JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiIGxhbmc9IkVOLVVTIj5FLW1haWwgZGlzY3Vzc2lvbnMgcHJp
b3IgdG8gTG9uZG9uIGhhdmUgY2xlYXJseSBkaXJlY3RlZCB0b3dhcmRzIGEgcmVwb3J0IHR5cGUg
dGhhdCByZXF1ZXN0cyB0aHJvdHRsaW5nIG9mIHJlYWxtIHJvdXRlZCByZXF1ZXN0IG1lc3NhZ2Vz
IChpLmUuDQogbm90IGNvbnRhaW5pbmcgYSBkZXN0aW5hdGlvbiBob3N0KSByYXRoZXIgdGhhbiBh
IHJlcG9ydCB0eXBlIHRoYXQgcmVxdWVzdHMgdGhyb3R0bGluZyBvZiBtZXNzYWdlcyByb3V0ZWQg
dG93YXJkcyBhIHJlYWxtIChubyBtYXR0ZXIgd2hldGhlciB0aGV5IGNvbnRhaW4gYSBkZXN0aW5h
dGlvbiBob3N0IG9yIG5vdCkuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1
b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiIGxh
bmc9IkVOLVVTIj5VbHJpY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCIgbGFuZz0iRU4t
VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk
ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYNCiAgICAgICAgICAgIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCIgbGFuZz0iRU4tVVMiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjp3aW5kb3d0ZXh0IiBsYW5n
PSJFTi1VUyI+IERpTUUgWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Im1h
aWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpkaW1lLWJvdW5jZXNAaWV0Zi5vcmc8
L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5leHQgU3RldmUgRG9ub3Zhbjxicj4NCjxiPlNlbnQ6
PC9iPiBGcmlkYXksIE1hcmNoIDIxLCAyMDE0IDM6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGNs
YXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3Jn
Ij5kaW1lQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRGltZV0gUmVzb2x1dGlv
biBvbiBhY3Rpb24gdG8gZGlzY3VzcyB0aGUgbmVlZCBmb3IgUmVhbG0tUm91dGVkLVJlcG9ydHM8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwsPGJyPg0K
PGJyPg0KQmVuIGFuZCBJIHRvb2sgdGhlIGFjdGlvbiBpdGVtIHRvIGRpc2N1c3MgdGhlIG5lZWQg
Zm9yIHRoZSBSZWFsbS1Sb3V0ZWQtUmVwb3J0cyAoUlJSKSByZXBvcnQgdHlwZS48YnI+DQo8YnI+
DQpBcyB5b3UgbWF5IHJlY2FsbCwgdGhlIGNvbnNlbnN1cyBjb21pbmcgb3V0IG9mIHRoZSBESU1F
IFdHIG1lZXRpbmcgaW4gTG9uZG9uIHdhcyB0byBzdXBwb3J0IHR3byByZXBvcnQgdHlwZXM6PGJy
Pg0KPGJyPg0KLSBIb3N0IC0tIEltcGFjdGluZyByZXF1ZXN0cyB3aXRoIGEgRGVzdGluYXRpb24t
SG9zdCBBVlAgbWF0Y2hpbmcgdGhlIGhvc3QgaW4gdGhlIG92ZXJsb2FkIHJlcG9ydCAod2l0aCB0
aGUgaG9zdCBpbXBsaWNpdGx5IGRldGVybWluZWQgZnJvbSB0aGUgT3JpZ2luLUhvc3QgQVZQIG9m
IHRoZSBhbnN3ZXIgbWVzc2FnZSBjYXJyeWluZyB0aGUgb3ZlcmxvYWQgcmVwb3J0KS48YnI+DQo8
YnI+DQotIFJlYWxtIC0tIEltcGFjdGluZyAxMDAlIG9mIHRoZSByZXF1ZXN0cyB3aXRoIGEgRGVz
dGluYXRpb24tUmVhbG0gQVZQIG1hdGNoaW5nIHRoZSByZWFsbSBpbiB0aGUgb3ZlcmxvYWQgcmVw
b3J0ICh3aXRoIHRoZSByZWFsbSBpbXBsaWNpdGx5IGRldGVybWluZSBmcm9tIHRoZSBPcmlnaW4t
UmVhbG0gb2YgdGhlIGFuc3dlciBtZXNzYWdlIGNhcnJ5aW5nIHRoZSBvdmVybG9hZCByZXBvcnQp
Ljxicj4NCjxicj4NClRoZSBhY3Rpb24gQmVuIGFuZCBJIHRvb2sgd2FzIHRvIGNvbWUgYmFjayB3
aXRoIGFuIG9waW5pb24gb24gd2hldGhlciBSUlIgcmVwb3J0cyBzaG91bGQgYWxzbyBiZSBzdXBw
b3J0ZWQuPGJyPg0KPGJyPg0KTXkgc3VtbWFyeSBvZiB0aGUgZGlzY3Vzc2lvbiBpcyB0aGF0IHdl
IHJlY29tbWVuZCB0byBOT1QgaW5jbHVkZSBSUlIgcmVwb3J0cyBpbiB0aGUgY3VycmVudCB2ZXJz
aW9uIG9mIHRoZSBiYXNlIERPSUMgZHJhZnQuJm5ic3A7DQo8YnI+DQo8YnI+DQpXZSBzdGlsbCBo
YXZlIHNvbWUgY29uY2VybnMgd2l0aCB0aGUgZ3JhbnVsYXJpdHkgb2YgY29udHJvbCBlbmFibGVk
IGJ5IGhhdmluZyBqdXN0IHRoZSB0d28gcmVwb3J0IHR5cGVzIGJ1dCB0aGUgYW5hbHlzaXMgb2Yg
d2hldGhlciBSUlIgcmVwb3J0cyBhcmUgc3RpbGwgbmVlZGVkIGNhbiBvY2N1ciBpbmRlcGVuZGVu
dCBvZiB0aGUgYmFzZSBET0lDIGRyYWZ0LiZuYnNwOyBJZiB0aGVyZSBpcyBhIGRldGVybWluYXRp
b24gdGhhdCBSUlJzIGFyZSBuZWVkZWQNCiBpbiB0aW1lIHRvIGluY2x1ZGUgaW4gdGhlIGJhc2Ug
ZHJhZnQgdGhlbiBpdCBjYW4gYmUgY29uc2lkZXJlZCBhdCB0aGF0IHRpbWUuPGJyPg0KPGJyPg0K
QmFzZWQgb24gdGhpcywgSSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgPGJyPg0KPGJyPg0KLSBSZXNv
bHV0aW9uIHRvIGlzc3VlICMyMyBpcyB0byByZW1vdmUgUlJSIHJlcG9ydHMgZnJvbSB0aGUgZG9j
dW1lbnQuPGJyPg0KLSBSZXNvbHV0aW9uIHRvIGlzc3VlICM1NSBpcyB0byBhZGQgUmVhbG0gcmVw
b3J0cyAoYWN0dWFsbHkgdG8gcmVkZWZpbmUgdGhlbSBwZXIgdGhlIGFib3ZlIGRlZmluaXRpb24p
Ljxicj4NCi0gUmVzb2x1dGlvbiB0byBpc3N1ZSAjNTcgaXMgdGhhdCBpdCBubyBsb25nZXIgYXBw
bGllcyAoYXMgaXQgZGVhbHMgd2l0aCBSUlJzKS48YnI+DQo8YnI+DQpUaGVyZSBpcyBhbHNvIG5l
ZWQgZm9yIHRleHQgZGVzY3JpYmluZyB0aGUgaW50ZXJhY3Rpb24gYmV0d2VlbiBob3N0IGFuZCB0
aGUgcmVhbG0gcmVwb3J0cy4mbmJzcDsgSSBkb24ndCBleHBlY3Qgd2Ugd2lsbCBoYXZlIGNvbnNl
bnN1cyBvbiB0aGlzIHdvcmRpbmcgcHJpb3IgdG8gdGhlIC0wMiBkcmFmdCBiZWluZyBzdWJtaXR0
ZWQuJm5ic3A7IFRvIHRoaXMgZW5kLCBJJ2xsIG9wZW4gYSBuZXcgaXNzdWUgdG8gZGVhbCB3aXRo
IHRoZSBuZWVkIGZvciB3b3JkaW5nIG9uDQogdGhlIGludGVyYWN0aW9uLjxicj4NCjxicj4NClJl
Z2FyZHMsPGJyPg0KPGJyPg0KU3RldmUgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxicj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_E8355113905631478EFF04F5AA706E9818AD87AFwtlexchp1sandvi_--


From nobody Sun Mar 23 02:48: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 B2F6D1A0654 for ; Sun, 23 Mar 2014 02:48:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level: 
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 HdL8iP7nKTJz for ; Sun, 23 Mar 2014 02:48:13 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id D829F1A6F58 for ; Sun, 23 Mar 2014 02:48:06 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id c11so2779958lbj.26 for ; Sun, 23 Mar 2014 02:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aQsl6lu+A/Hr5CbQVp2eyu1w8jbjbZH15PAGirgeVLI=; b=Ti09G4PWgXK4iy74rB+ocBDJLzH5df33a6+QfF4DJZib8qrw3x5x095q/RDFfUcl2w 9Vbs0pU7jRdqWGSyIkWm/iczXE/3Fkjd+4HTYVWL6aQ3ntCY3cSY9sTM8ZB2m5PmMj2O gzB1fdxghRmPx7aTLlTPlL/16ElgN6XXlCO4q8HA3BT0hfx0empsUkWR/r+GwHgdKj4D /bACkpw9jBIrP6LQZX50ipDYyFjfqWobBVD7tI7nbaZpNh9fXLRoUORFrdeSziMXh2UE rOGwwPYNTUdb6BejcZyYtmL3j7Crm6L0mWYiQHGUA18PCtstEu7hXkSo1zvBjV4OmGtL sy/Q==
X-Received: by 10.112.128.131 with SMTP id no3mr65197lbb.57.1395568085410; Sun, 23 Mar 2014 02:48:05 -0700 (PDT)
Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id jh4sm7071716lbb.26.2014.03.23.02.48.00 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Mar 2014 02:48:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=us-ascii
From: Jouni 
In-Reply-To: <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com>
Date: Sun, 23 Mar 2014 11:47:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>   <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com>
To: Ben Campbell 
X-Mailer: Apple Mail (2.1283)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/d1W48uuFkcYzJd1GkbRryckB1Ac
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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, 23 Mar 2014 09:48:16 -0000

On Mar 22, 2014, at 7:36 AM, Ben Campbell wrote:

>=20
> On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  =
wrote:
>=20
>>=20
>> Ben,
>>=20
>> On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:
>>=20
>>>=20
>>> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen =
 wrote:
>>>=20
>>>>>=20
>>>>> Consider the case of a Diameter _relay_ that supports DOIC. It is =
not aware of any application-specific rules about m-bits. It receives an =
OC-Supported-Features or an OC-OLR that has a mandatory AVP that it =
doesn't recognize. Logically, it should probably ignore the entire =
OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a =
relay, it's not going to reject the message. Rather it's likely to try =
to apply the OC-Supported-Features or OC-OLR incorrectly.
>>>>=20
>>>> RFC6733 also says that relays perform not do any application level
>>>> processing. If a relay supports DOIC and does something goofy that
>>>> is left for implementation, we should no care nor try to fix the
>>>> situation. The implementation is already bending the rules in that
>>>> case.
>>>=20
>>> Hi Jouni,
>>>=20
>>> I'm not talking about the case of the relay doing something goofy. =
Rather, I mean when a relay tries to perform basic DOIC processing of an =
OLR as described in the base DOIC spec, but ignores some extension AVP =
that changes the meaning of the OLR. It's not bending the rules so much =
as failing to recognize someone else changing the rules.
>>=20
>> Ah, I see your point. But if one adds AVPs to the default algorithm
>> that change he behaviour and does not a) declare it as a new =
algorithm
>> or b) add a new supported feature flag, then that is a proprietary
>> (broken) implementation. We cannot really protect against those..
>=20
> I think that's reasonable. My original point was that extensions =
should not try to use the m-bit for that purpose. If they have something =
that is not backwards compatible, it needs to be negotiated in the =
feature vector.

Agree on that!

- Jouni


>=20
>=20


From nobody Sun Mar 23 20:56:50 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 264F31A00E5 for ; Sun, 23 Mar 2014 20:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level: 
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 3wE61lhcXK9l for ; Sun, 23 Mar 2014 20:56:42 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A852E1A00DD for ; Sun, 23 Mar 2014 20:56:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEW23096; Mon, 24 Mar 2014 03:56:38 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Mar 2014 03:56:11 +0000
Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Mar 2014 03:56:36 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Mon, 24 Mar 2014 11:56:29 +0800
From: "Shishufeng (Susan)" 
To: Maria Cruz Bartolome , Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPQs3Y3mMmL1YBMEOBG3qYkPuXm5rvo5uA
Date: Mon, 24 Mar 2014 03:56:28 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3D7E9@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3D7E9SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/W8zGqH_QqhqRBePUOK4AI7a5eXA
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 03:56:46 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3D7E9SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello all,

I totally agree with MCruz. For some applications or deployments, the OC-Re=
port-Type is not required at all, I don't see the benefit to always have su=
ch an AVP in those cases.

Best Regards,
Susan

From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]
Sent: Wednesday, March 19, 2014 1:16 AM
To: Steve Donovan; dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello,
I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.
This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.
If there is consensus on this, I will go with this.
Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 18 de marzo de 2014 17:47
To: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

All,

Do we have consensus that the OC-Report-Type AVP is required?

If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.

Jouni,

How do we indicate a fixed position for an AVP?

I presonally don't see this as critical but we can add this requirement if =
there is consensus.

Regards,

Steve
On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP

is not present?



If a node does not include it when it should, the implementation

is broken. Wouldn't a broken node be able to put wrong report

type into the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP ;-)



I prefer having the AVP optional but with a default value just like it

is now. We have the same for the reduction percentage and the validity

time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

 report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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




--_000_26C84DFD55BC3040A45BF70926E55F2587C3D7E9SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello all,=



 =
;


I totally =
agree with MCruz. For some applications or deployments, the OC-Report-Type =
is not required at all, I don't see the benefit to always
 have such an AVP in those cases.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 Maria Cruz Bartolom=
e [mailto:maria.cruz.bartolome@ericsson.com]


Sent: Wednesday, March 19, 2014 1:16 AM

To: Steve Donovan; dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hello,


I think th=
e agreement tendency is the contrary: OC-Report-Type is not required, while=
 default value is Host. i.e. it will remain as it is now in
 the draft.


This may b=
e of some advantage for some applications that may only use Host, as long a=
s they may never generate Realm reports.


If there i=
s consensus on this, I will go with this.<=
/o:p>


Best regar=
ds


/MCruz


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?  



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve




On 2/28/14 10:27 AM, Jouni Korh=
onen wrote:






 


Hi,


 


How having the AVP could be less error prone if i=
t has a default


value and the receiver knows exactly how to proce=
ed when the AVP


is not present?


 


If a node does not include it when it should, the=
 implementation


is broken. Wouldn't a broken node be able to put =
wrong report


type into the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 s=
till open, consider


it resolved from my side. I am OK making the OC-R=
eport-Type AVP as


required/mandatory AVP. Should we also consider i=
t having a fixed


position just after the OC-Sequence-Number AVP as=
 well since it is


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolom=
e <maria.cruz.barto=
lome@ericsson.com> wrote:


 




 


Hello all,


 


I understand JJ point of view, but I still tend t=
o prefer to make it mandatory, since I think this is less error-prone, sinc=
e the only node that knows the requested Report-Type is the reporting, if f=
or any reason a reporting is omitting it (since it is optional), it will be=
 always interpreted as HOST, but this type may be wrong.<=
/pre>

 


I think DEFAULT values should never be error-pron=
e, but used in "general cases", as a simplification, like e.g. a =
default for the Validity-Duration. Default Validity-Duration will never be =
an "error", it could be not the best value (compared with another=
 value perfectly tuned to reporting node overload situation) but never the =
use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell<=
/span>


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


I actually prefer making it mandatory. The cost o=
f adding it is trivial--even more so for a reporting node that only support=
s the default. The value of having it is less opportunity for interop error=
s.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro=
te:


 




 


Agree that it is a small optimization, which I pu=
t there because at 


the beginning there seemed to be a lot of worry o=
n every extra AVP ;-)


 


I prefer having the AVP optional but with a defau=
lt value just like it 


is now. We have the same for the reduction percen=
tage and the validity 


time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 




Hi Mcruz


 


The current description indicates that when not p=
resent the OLR is of type Host, which was fine for me and keeps my preferen=
ce. 


We may have  deployments where Realm OLR is =
not used, or where statistically the HOST type is the most frequent, so to =
have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I =
agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lione=
l.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 : <=
o:p>


dime@ietf.org; maria.cruz.bartolom=
e@ericsson.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" i=
nstead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  [ OC-Report-Type ]


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  { OC-Report-Type }


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:=
26 =C0 : 


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0=
 (i.e. the host


 report).


 


This AVP is always required, right? Then, I think=
 it is more precise that  we define this AVP as mandatory.<=
/span>


 


--


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


Reporter:  maria.cruz.bartolome@ericsson.com  | &nbs=
p;    Owner:  MCruz


  Type:  defect    =
            &nb=
sp;            |&nbs=
p; Bartolom=E9


Priority:  major    &nbs=
p;            &=
nbsp;            |&n=
bsp;    Status:  new


Component:  draft-docdt-dime-ovli  =
;            | =
 Milestone:


Severity:  Active WG Document  &nb=
sp;            =
  |    Version:  1.0


        &=
nbsp;           &nbs=
p;            &=
nbsp;          |   K=
eywords:


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket=
/54>


dime &=
lt;http://tools.ietf.org/wg/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 et=
re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me=
ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law; they shoul=
d 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 fo=
r 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

 




 






--_000_26C84DFD55BC3040A45BF70926E55F2587C3D7E9SZXEMA512MBXchi_--


From nobody Sun Mar 23 21:00: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 9F6091A00E8 for ; Sun, 23 Mar 2014 21:00:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 i8MMxzyTRr0J for ; Sun, 23 Mar 2014 21:00:07 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 76AA71A00DD for ; Sun, 23 Mar 2014 21:00:06 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCJ03701; Mon, 24 Mar 2014 04:00:05 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Mar 2014 03:59:46 +0000
Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 24 Mar 2014 04:00:04 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 24 Mar 2014 11:59:52 +0800
From: "Shishufeng (Susan)" 
To: Jouni Korhonen , Steve Donovan 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVg
Date: Mon, 24 Mar 2014 03:59:51 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com> 
In-Reply-To: 
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/eIQVC9Ql_F_lNbW6sxzooMsXtzA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 04:00:09 -0000

Hello Jouni,

I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.=20

Best Regards,
Susan


-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Saturday, March 22, 2014 10:38 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


Lets have it explicit then. Use '<' and '>' to make the position fixed.

- Jouni

On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote=
:

> I'm ok with either direction but generally lean toward being explicit.
>=20
> Do we have other opinions? =20
>=20
> Steve
> On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
>> Hello,
>> I think the agreement tendency is the contrary: OC-Report-Type is not re=
quired, while default value is Host. i.e. it will remain as it is now in th=
e draft.
>> This may be of some advantage for some applications that may only use Ho=
st, as long as they may never generate Realm reports.
>> If there is consensus on this, I will go with this.
>> Best regards
>> /MCruz
>> =20
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>> Sent: martes, 18 de marzo de 2014 17:47
>> To: dime@ietf.org
>> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> All,
>>=20
>> Do we have consensus that the OC-Report-Type AVP is required?
>>=20
>> If so then one change would be as indicated in the syntax definition pro=
posed by Lionel.  We would also remove wording on the default value.
>>=20
>> Jouni,
>>=20
>> How do we indicate a fixed position for an AVP? =20
>>=20
>> I presonally don't see this as critical but we can add this requirement =
if there is consensus.
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>> On 2/28/14 10:27 AM, Jouni Korhonen wrote:
>> =20
>> Hi,
>> =20
>> How having the AVP could be less error prone if it has a default=20
>> value and the receiver knows exactly how to proceed when the AVP is=20
>> not present?
>> =20
>> If a node does not include it when it should, the implementation is=20
>> broken. Wouldn't a broken node be able to put wrong report type into=20
>> the AVP even if the AVP is mandatory?
>> =20
>> Anyway, if it is my statement keeping issue #54 still open, consider=20
>> it resolved from my side. I am OK making the OC-Report-Type AVP as=20
>> required/mandatory AVP. Should we also consider it having a fixed=20
>> position just after the OC-Sequence-Number AVP as well since it is=20
>> going to in every OC-OLR?
>> =20
>> - Jouni
>> =20
>> =20
>> =20
>> On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:
>> =20
>> =20
>> Hello all,
>> =20
>> I understand JJ point of view, but I still tend to prefer to make it man=
datory, since I think this is less error-prone, since the only node that kn=
ows the requested Report-Type is the reporting, if for any reason a reporti=
ng is omitting it (since it is optional), it will be always interpreted as =
HOST, but this type may be wrong.
>> =20
>> I think DEFAULT values should never be error-prone, but used in "general=
 cases", as a simplification, like e.g. a default for the Validity-Duration=
. Default Validity-Duration will never be an "error", it could be not the b=
est value (compared with another value perfectly tuned to reporting node ov=
erload situation) but never the use of a Default value should lead to an er=
roneous behavior.
>> =20
>> Best regards
>> /MCruz
>> =20
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>> Sent: viernes, 14 de febrero de 2014 23:13
>> To: Jouni Korhonen
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> I actually prefer making it mandatory. The cost of adding it is trivial-=
-even more so for a reporting node that only supports the default. The valu=
e of having it is less opportunity for interop errors.
>> =20
>> On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wro=
te:
>> =20
>> =20
>> Agree that it is a small optimization, which I put there because at=20
>> the beginning there seemed to be a lot of worry on every extra AVP=20
>> ;-)
>> =20
>> I prefer having the AVP optional but with a default value just like=20
>> it is now. We have the same for the reduction percentage and the=20
>> validity time as well.
>> =20
>> - Jouni
>> =20
>> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:
>> =20
>> Hi Mcruz
>> =20
>> The current description indicates that when not present the OLR is of ty=
pe Host, which was fine for me and keeps my preference.=20
>> We may have  deployments where Realm OLR is not used, or where statistic=
ally the HOST type is the most frequent, so to have the grouped OLR-AVP con=
taining a minimum of AVPs minimizes parsing. I agree it is a small optimiza=
tion.
>> =20
>> Best regards
>> =20
>> JJacques
>> =20
>> =20
>> =20
>> =20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de=20
>> lionel.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0=
 :
>> dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]=20
>> [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> Hi Maria Cruz,
>> =20
>> I'm assuming that you mean "required" instead of "mandatory", right?
>> =20
>> So instead of:
>> =20
>> OC-OLR ::=3D < AVP Header: TBD2 >
>>            < OC-Sequence-Number >
>>            [ OC-Report-Type ]
>>            [ OC-Reduction-Percentage ]
>>            [ OC-Validity-Duration ]
>>          * [ AVP ]
>> =20
>> You would prefer:
>> =20
>> OC-OLR ::=3D < AVP Header: TBD2 >
>>            < OC-Sequence-Number >
>>            { OC-Report-Type }
>>            [ OC-Reduction-Percentage ]
>>            [ OC-Validity-Duration ]
>>          * [ AVP ]
>> =20
>> And I'm fine with this proposal.
>> =20
>> Cheers,
>> =20
>> Lionel
>> =20
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue=20
>> tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :
>> maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime]=20
>> [dime] #54: OC-Report-Type as mandatory AVP
>> =20
>> #54: OC-Report-Type as mandatory AVP
>> =20
>> Now in chapter 4.6:
>> =20
>>  The default value of the OC-Report-Type AVP is 0 (i.e. the host =20
>> report).
>> =20
>> This AVP is always required, right? Then, I think it is more precise tha=
t  we define this AVP as mandatory.
>> =20
>> --
>> -----------------------------------------------+---------------------
>> -----------------------------------------------+---
>> -----------------------------------------------+---
>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>   Type:  defect                             |  Bartolom=E9
>> Priority:  major                              |     Status:  new
>> Component:  draft-docdt-dime-ovli              |  Milestone:
>> Severity:  Active WG Document                 |    Version:  1.0
>>                                             |   Keywords:
>> -----------------------------------------------+---------------------
>> -----------------------------------------------+---
>> -----------------------------------------------+---
>> =20
>> Ticket URL: 
>> 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 confi=
dentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites =
ou copies sans autorisation. Si vous avez recu ce message par erreur, veuil=
lez 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. Merc=
i.
>> =20
>> This message and its attachments may contain confidential or privileged =
information that may be protected by law; they should not be distributed, u=
sed or copied without authorisation.
>> If you have received this email in error, please notify the sender and d=
elete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have be=
en modified, changed or falsified.
>> Thank you.
>> =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
>> =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
>> =20
>> =20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime



From nobody Mon Mar 24 05:21: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 C079C1A01EC for ; Mon, 24 Mar 2014 05:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ikxcUfjzFKbu for ; Mon, 24 Mar 2014 05:21:38 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 806E11A01E9 for ; Mon, 24 Mar 2014 05:21:38 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54345 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS3sh-0004Mf-5n; Mon, 24 Mar 2014 05:21:35 -0700
Message-ID: <5330234A.5080907@usdonovans.com>
Date: Mon, 24 Mar 2014 07:21:30 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Dave Dolson , "'dime@ietf.org'" 
References: 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000705010703040305040202"
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/QIf3fka8lhxiOHzlAlQqAxCgvxc
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 24 Mar 2014 12:21:41 -0000

This is a multi-part message in MIME format.
--------------000705010703040305040202
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Dave,

You are correct, we need to have wording on the interaction between the
report types, thus the last paragraph in my proposal.

This will likely be shown as an open issue in the -02 version of the
draft, unless we come to consensus on wording between now and Thursday. 

Steve

On 3/22/14 6:43 AM, Dave Dolson wrote:
> It is difficult to judge this issue without knowing how the reported
> values are to be resolved when contradictory.
>
> To send a request with both realm and host name, and having reported
> realm and host percentages, what should be done?
>
> Does the client have to keep track of how much it has sent to each
> host, and also the realm as a whole?
>
> This needs to be part of the spec, not left to vendor-specific
> implementation, because the overloaded realm/node needs a model of how
> the client will react.
>
>
> The approach of having feedback for realm-only messages made it easier
> to understand what the client should do.
>
> -Dave
>
>
>  
> *From*: Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent*: Friday, March 21, 2014 05:05 PM
> *To*: dime@ietf.org 
> *Subject*: Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>  
> Ulrich,
>
> The discussion should be captured in the minutes to the meeting.  I
> wasn't able to find them posted yet.
>
> Jouni, Lionel, what is the status of the minutes for the meeting?
>
> My reading of emails prior to the London meeting is different from
> yours.  I believe we had come to the conclusion that we needed host
> and realm (with the definition of realm as outlined below).  We were
> still discussing the need for Realm-Routed-Request reports.
>
> Regards,
>
> Steve
>
> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>
>> Steve,
>>
>>  
>>
>> I don’t know what happend in London.
>>
>> Can you please summarize the technical reasons that led to the London
>> agreement.
>>
>> E-mail discussions prior to London have clearly directed towards a
>> report type that requests throttling of realm routed request messages
>> (i.e. not containing a destination host) rather than a report type
>> that requests throttling of messages routed towards a realm (no
>> matter whether they contain a destination host or not).   
>>
>>  
>>
>> Ulrich
>>
>>  
>>
>> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
>> Donovan
>> *Sent:* Friday, March 21, 2014 3:33 PM
>> *To:* dime@ietf.org
>> *Subject:* [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>  
>>
>> All,
>>
>> Ben and I took the action item to discuss the need for the
>> Realm-Routed-Reports (RRR) report type.
>>
>> As you may recall, the consensus coming out of the DIME WG meeting in
>> London was to support two report types:
>>
>> - Host -- Impacting requests with a Destination-Host AVP matching the
>> host in the overload report (with the host implicitly determined from
>> the Origin-Host AVP of the answer message carrying the overload report).
>>
>> - Realm -- Impacting 100% of the requests with a Destination-Realm
>> AVP matching the realm in the overload report (with the realm
>> implicitly determine from the Origin-Realm of the answer message
>> carrying the overload report).
>>
>> The action Ben and I took was to come back with an opinion on whether
>> RRR reports should also be supported.
>>
>> My summary of the discussion is that we recommend to NOT include RRR
>> reports in the current version of the base DOIC draft. 
>>
>> We still have some concerns with the granularity of control enabled
>> by having just the two report types but the analysis of whether RRR
>> reports are still needed can occur independent of the base DOIC
>> draft.  If there is a determination that RRRs are needed in time to
>> include in the base draft then it can be considered at that time.
>>
>> Based on this, I propose the following
>>
>> - Resolution to issue #23 is to remove RRR reports from the document.
>> - Resolution to issue #55 is to add Realm reports (actually to
>> redefine them per the above definition).
>> - Resolution to issue #57 is that it no longer applies (as it deals
>> with RRRs).
>>
>> There is also need for text describing the interaction between host
>> and the realm reports.  I don't expect we will have consensus on this
>> wording prior to the -02 draft being submitted.  To this end, I'll
>> open a new issue to deal with the need for wording on the interaction.
>>
>> Regards,
>>
>> Steve
>>
>


--------------000705010703040305040202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Dave,

      

      You are correct, we need to have wording on the interaction
      between the report types, thus the last paragraph in my proposal.

      

      This will likely be shown as an open issue in the -02 version of
      the draft, unless we come to consensus on wording between now and
      Thursday.  

      

      Steve

      

    
    
On 3/22/14 6:43 AM, Dave Dolson wrote:

    

    

      
      It
        is difficult to judge this issue without knowing how the
        reported values are to be resolved when contradictory.
        

        

        To send a request with both realm and host name, and having
        reported realm and host percentages, what should be done?

        

        Does the client have to keep track of how much it has sent to
        each host, and also the realm as a whole?

        

        This needs to be part of the spec, not left to vendor-specific
        implementation, because the overloaded realm/node needs a model
        of how the client will react.
        

        

        

        The approach of having feedback for realm-only messages made it
        easier to understand what the client should do.

        

        -Dave

        

      

       

      

        From:
          Steve Donovan [mailto:srdonovan@usdonovans.com]
          

          Sent: Friday, March 21, 2014 05:05 PM

          To: dime@ietf.org <dime@ietf.org> 

          Subject: Re: [Dime] Resolution on action to discuss the
          need for Realm-Routed-Reports
          

         

      

      Ulrich,

        

        The discussion should be captured in the minutes to the
        meeting.  I wasn't able to find them posted yet.

        

        Jouni, Lionel, what is the status of the minutes for the
        meeting?

        

        My reading of emails prior to the London meeting is different
        from yours.  I believe we had come to the conclusion that we
        needed host and realm (with the definition of realm as outlined
        below).  We were still discussing the need for
        Realm-Routed-Request reports.

        

        Regards,

        

        Steve

        

      
      
On 3/21/14 10:09 AM, Wiehe, Ulrich
        (NSN - DE/Munich) wrote:

      

      

        
        
        

          
Steve,

          
 

          
I don’t know what happend in London.

          
Can you please summarize the technical
              reasons that led to the London agreement.
              

          
E-mail discussions prior to London have
              clearly directed towards a report type that requests
              throttling of realm routed request messages (i.e. not
              containing a destination host) rather than a report type
              that requests throttling of messages routed towards a
              realm (no matter whether they contain a destination host
              or not).   

          
 

          
Ulrich

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Friday, March 21, 2014 3:33 PM

                  To: dime@ietf.org

                  Subject: [Dime] Resolution on action to discuss
                  the need for Realm-Routed-Reports

            

          

          
 

          
All,

            

            Ben and I took the action item to discuss the need for the
            Realm-Routed-Reports (RRR) report type.

            

            As you may recall, the consensus coming out of the DIME WG
            meeting in London was to support two report types:

            

            - Host -- Impacting requests with a Destination-Host AVP
            matching the host in the overload report (with the host
            implicitly determined from the Origin-Host AVP of the answer
            message carrying the overload report).

            

            - Realm -- Impacting 100% of the requests with a
            Destination-Realm AVP matching the realm in the overload
            report (with the realm implicitly determine from the
            Origin-Realm of the answer message carrying the overload
            report).

            

            The action Ben and I took was to come back with an opinion
            on whether RRR reports should also be supported.

            

            My summary of the discussion is that we recommend to NOT
            include RRR reports in the current version of the base DOIC
            draft. 
            

            

            We still have some concerns with the granularity of control
            enabled by having just the two report types but the analysis
            of whether RRR reports are still needed can occur
            independent of the base DOIC draft.  If there is a
            determination that RRRs are needed in time to include in the
            base draft then it can be considered at that time.

            

            Based on this, I propose the following 

            

            - Resolution to issue #23 is to remove RRR reports from the
            document.

            - Resolution to issue #55 is to add Realm reports (actually
            to redefine them per the above definition).

            - Resolution to issue #57 is that it no longer applies (as
            it deals with RRRs).

            

            There is also need for text describing the interaction
            between host and the realm reports.  I don't expect we will
            have consensus on this wording prior to the -02 draft being
            submitted.  To this end, I'll open a new issue to deal with
            the need for wording on the interaction.

            

            Regards,

            

            Steve 

        

      

      

    

    

  


--------------000705010703040305040202--


From nobody Mon Mar 24 05:22: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 0B91C1A01F2 for ; Mon, 24 Mar 2014 05:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 nxwMJ6JjwsL6 for ; Mon, 24 Mar 2014 05:22:53 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6992E1A01F1 for ; Mon, 24 Mar 2014 05:22:53 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54346 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS3tw-0006GJ-1L for dime@ietf.org; Mon, 24 Mar 2014 05:22:52 -0700
Message-ID: <53302397.7020006@usdonovans.com>
Date: Mon, 24 Mar 2014 07:22:47 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>   <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com>
In-Reply-To: <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com>
Content-Type: multipart/alternative; boundary="------------040407070704000705070003"
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/hccqEjyeIvHAySZykyAJX3f3utA
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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, 24 Mar 2014 12:22:55 -0000

This is a multi-part message in MIME format.
--------------040407070704000705070003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Do we have proposed wording to be included in the -02 version of the
draft on this issue?

Steve

On 3/22/14 12:36 AM, Ben Campbell wrote:
> On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  wrote:
>
>> Ben,
>>
>> On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:
>>
>>> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  wrote:
>>>
>>>>> Consider the case of a Diameter _relay_ that supports DOIC. It is not aware of any application-specific rules about m-bits. It receives an OC-Supported-Features or an OC-OLR that has a mandatory AVP that it doesn't recognize. Logically, it should probably ignore the entire OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject the message. Rather it's likely to try to apply the OC-Supported-Features or OC-OLR incorrectly.
>>>> RFC6733 also says that relays perform not do any application level
>>>> processing. If a relay supports DOIC and does something goofy that
>>>> is left for implementation, we should no care nor try to fix the
>>>> situation. The implementation is already bending the rules in that
>>>> case.
>>> Hi Jouni,
>>>
>>> I'm not talking about the case of the relay doing something goofy. Rather, I mean when a relay tries to perform basic DOIC processing of an OLR as described in the base DOIC spec, but ignores some extension AVP that changes the meaning of the OLR. It's not bending the rules so much as failing to recognize someone else changing the rules.
>> Ah, I see your point. But if one adds AVPs to the default algorithm
>> that change he behaviour and does not a) declare it as a new algorithm
>> or b) add a new supported feature flag, then that is a proprietary
>> (broken) implementation. We cannot really protect against those..
> I think that's reasonable. My original point was that extensions should not try to use the m-bit for that purpose. If they have something that is not backwards compatible, it needs to be negotiated in the feature vector.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------040407070704000705070003
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Do we have proposed
      wording to be included in the -02 version of the draft on this
      issue?

      

      Steve

      

    
    
On 3/22/14 12:36 AM, Ben Campbell
      wrote:

    

    

      
On Mar 21, 2014, at 9:33 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:



      

        
Ben,

On Mar 22, 2014, at 2:44 AM, Ben Campbell <ben@nostrum.com> wrote:



        

          
On Mar 21, 2014, at 12:43 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:



          

            

              
Consider the case of a Diameter _relay_ that supports DOIC. It is not aware of any application-specific rules about m-bits. It receives an OC-Supported-Features or an OC-OLR that has a mandatory AVP that it doesn't recognize. Logically, it should probably ignore the entire OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject the message. Rather it's likely to try to apply the OC-Supported-Features or OC-OLR incorrectly.


            

            
RFC6733 also says that relays perform not do any application level
processing. If a relay supports DOIC and does something goofy that
is left for implementation, we should no care nor try to fix the
situation. The implementation is already bending the rules in that
case.


          

          
Hi Jouni,

I'm not talking about the case of the relay doing something goofy. Rather, I mean when a relay tries to perform basic DOIC processing of an OLR as described in the base DOIC spec, but ignores some extension AVP that changes the meaning of the OLR. It's not bending the rules so much as failing to recognize someone else changing the rules.


        

        
Ah, I see your point. But if one adds AVPs to the default algorithm
that change he behaviour and does not a) declare it as a new algorithm
or b) add a new supported feature flag, then that is a proprietary
(broken) implementation. We cannot really protect against those..


      

      
I think that's reasonable. My original point was that extensions should not try to use the m-bit for that purpose. If they have something that is not backwards compatible, it needs to be negotiated in the feature vector.


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



    

    

  


--------------040407070704000705070003--


From nobody Mon Mar 24 05:25:49 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 AD1E01A01ED for ; Mon, 24 Mar 2014 05:25:47 -0700 (PDT)
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 RaIWrXV2kZim for ; Mon, 24 Mar 2014 05:25:45 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 17F271A01EA for ; Mon, 24 Mar 2014 05:25:45 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54361 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS3wk-0001kW-O0; Mon, 24 Mar 2014 05:25:44 -0700
Message-ID: <53302446.9080700@usdonovans.com>
Date: Mon, 24 Mar 2014 07:25:42 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Shishufeng (Susan)" ,  Jouni Korhonen 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------060909090901010404000206"
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/UIOIz-axY_CzPfyJJCVNWjvHHsY
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 12:25:47 -0000

This is a multi-part message in MIME format.
--------------060909090901010404000206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to
make a decision quickly.

Steve

On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:
> Hello Jouni,
>
> I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 
>
> Best Regards,
> Susan
>
>
> -----Original Message-----
> From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: Saturday, March 22, 2014 10:38 AM
> To: Steve Donovan
> Cc: dime@ietf.org
> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>
> Lets have it explicit then. Use '<' and '>' to make the position fixed.
>
> - Jouni
>
> On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:
>
>> I'm ok with either direction but generally lean toward being explicit.
>>
>> Do we have other opinions?  
>>
>> Steve
>> On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
>>> Hello,
>>> I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.
>>> This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.
>>> If there is consensus on this, I will go with this.
>>> Best regards
>>> /MCruz
>>>  
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>>> Sent: martes, 18 de marzo de 2014 17:47
>>> To: dime@ietf.org
>>> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>>  
>>> All,
>>>
>>> Do we have consensus that the OC-Report-Type AVP is required?
>>>
>>> If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.
>>>
>>> Jouni,
>>>
>>> How do we indicate a fixed position for an AVP?  
>>>
>>> I presonally don't see this as critical but we can add this requirement if there is consensus.
>>>
>>> Regards,
>>>
>>> Steve
>>>
>>> On 2/28/14 10:27 AM, Jouni Korhonen wrote:
>>>  
>>> Hi,
>>>  
>>> How having the AVP could be less error prone if it has a default 
>>> value and the receiver knows exactly how to proceed when the AVP is 
>>> not present?
>>>  
>>> If a node does not include it when it should, the implementation is 
>>> broken. Wouldn't a broken node be able to put wrong report type into 
>>> the AVP even if the AVP is mandatory?
>>>  
>>> Anyway, if it is my statement keeping issue #54 still open, consider 
>>> it resolved from my side. I am OK making the OC-Report-Type AVP as 
>>> required/mandatory AVP. Should we also consider it having a fixed 
>>> position just after the OC-Sequence-Number AVP as well since it is 
>>> going to in every OC-OLR?
>>>  
>>> - Jouni
>>>  
>>>  
>>>  
>>> On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:
>>>  
>>>  
>>> Hello all,
>>>  
>>> I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
>>>  
>>> I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
>>>  
>>> Best regards
>>> /MCruz
>>>  
>>> -----Original Message-----
>>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>>> Sent: viernes, 14 de febrero de 2014 23:13
>>> To: Jouni Korhonen
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>>>  
>>> I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
>>>  
>>> On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:
>>>  
>>>  
>>> Agree that it is a small optimization, which I put there because at 
>>> the beginning there seemed to be a lot of worry on every extra AVP 
>>> ;-)
>>>  
>>> I prefer having the AVP optional but with a default value just like 
>>> it is now. We have the same for the reduction percentage and the 
>>> validity time as well.
>>>  
>>> - Jouni
>>>  
>>> On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:
>>>  
>>> Hi Mcruz
>>>  
>>> The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
>>> We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
>>>  
>>> Best regards
>>>  
>>> JJacques
>>>  
>>>  
>>>  
>>>  
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de 
>>> lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À :
>>> dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 
>>> [dime] #54: OC-Report-Type as mandatory AVP
>>>  
>>> Hi Maria Cruz,
>>>  
>>> I'm assuming that you mean "required" instead of "mandatory", right?
>>>  
>>> So instead of:
>>>  
>>> OC-OLR ::= < AVP Header: TBD2 >
>>>            < OC-Sequence-Number >
>>>            [ OC-Report-Type ]
>>>            [ OC-Reduction-Percentage ]
>>>            [ OC-Validity-Duration ]
>>>          * [ AVP ]
>>>  
>>> You would prefer:
>>>  
>>> OC-OLR ::= < AVP Header: TBD2 >
>>>            < OC-Sequence-Number >
>>>            { OC-Report-Type }
>>>            [ OC-Reduction-Percentage ]
>>>            [ OC-Validity-Duration ]
>>>          * [ AVP ]
>>>  
>>> And I'm fine with this proposal.
>>>  
>>> Cheers,
>>>  
>>> Lionel
>>>  
>>> -----Message d'origine-----
>>> De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
>>> tracker Envoyé : mercredi 12 février 2014 15:26 À :
>>> maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 
>>> [dime] #54: OC-Report-Type as mandatory AVP
>>>  
>>> #54: OC-Report-Type as mandatory AVP
>>>  
>>> Now in chapter 4.6:
>>>  
>>>  The default value of the OC-Report-Type AVP is 0 (i.e. the host  
>>> report).
>>>  
>>> This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
>>>  
>>> --
>>> -----------------------------------------------+---------------------
>>> -----------------------------------------------+---
>>> -----------------------------------------------+---
>>> Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
>>>   Type:  defect                             |  Bartolomé
>>> Priority:  major                              |     Status:  new
>>> Component:  draft-docdt-dime-ovli              |  Milestone:
>>> Severity:  Active WG Document                 |    Version:  1.0
>>>                                             |   Keywords:
>>> -----------------------------------------------+---------------------
>>> -----------------------------------------------+---
>>> -----------------------------------------------+---
>>>  
>>> Ticket URL: 
>>> 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
>>>  
>>>  
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>
>


--------------060909090901010404000206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Susan,

      

      We are in the middle of the discussion and have not yet reached
      consensus.

      

      I agree with Jouni on making it explicit.  Either way, we should
      try to make a decision quickly.

      

      Steve

      

    
    
On 3/23/14 10:59 PM, Shishufeng (Susan)
      wrote:

    

    

      
Hello Jouni,

I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 

Best Regards,
Susan


-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Saturday, March 22, 2014 10:38 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


Lets have it explicit then. Use '<' and '>' to make the position fixed.

- Jouni

On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:



      

        
I'm ok with either direction but generally lean toward being explicit.

Do we have other opinions?  

Steve
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:


        

          
Hello,
I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.
This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.
If there is consensus on this, I will go with this.
Best regards
/MCruz
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 18 de marzo de 2014 17:47
To: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
 
All,

Do we have consensus that the OC-Report-Type AVP is required?

If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.

Jouni,

How do we indicate a fixed position for an AVP?  

I presonally don't see this as critical but we can add this requirement if there is consensus.

Regards,

Steve

On 2/28/14 10:27 AM, Jouni Korhonen wrote:
 
Hi,
 
How having the AVP could be less error prone if it has a default 
value and the receiver knows exactly how to proceed when the AVP is 
not present?
 
If a node does not include it when it should, the implementation is 
broken. Wouldn't a broken node be able to put wrong report type into 
the AVP even if the AVP is mandatory?
 
Anyway, if it is my statement keeping issue #54 still open, consider 
it resolved from my side. I am OK making the OC-Report-Type AVP as 
required/mandatory AVP. Should we also consider it having a fixed 
position just after the OC-Sequence-Number AVP as well since it is 
going to in every OC-OLR?
 
- Jouni
 
 
 
On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:
 
 
Hello all,
 
I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
 
I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
 
Best regards
/MCruz
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: viernes, 14 de febrero de 2014 23:13
To: Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
 
I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
 
On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:
 
 
Agree that it is a small optimization, which I put there because at 
the beginning there seemed to be a lot of worry on every extra AVP 
;-)
 
I prefer having the AVP optional but with a default value just like 
it is now. We have the same for the reduction percentage and the 
validity time as well.
 
- Jouni
 
On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:
 
Hi Mcruz
 
The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
 
Best regards
 
JJacques
 
 
 
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de 
lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À :
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 
[dime] #54: OC-Report-Type as mandatory AVP
 
Hi Maria Cruz,
 
I'm assuming that you mean "required" instead of "mandatory", right?
 
So instead of:
 
OC-OLR ::= < AVP Header: TBD2 >
           < OC-Sequence-Number >
           [ OC-Report-Type ]
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]
 
You would prefer:
 
OC-OLR ::= < AVP Header: TBD2 >
           < OC-Sequence-Number >
           { OC-Report-Type }
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]
 
And I'm fine with this proposal.
 
Cheers,
 
Lionel
 
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
tracker Envoyé : mercredi 12 février 2014 15:26 À :
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 
[dime] #54: OC-Report-Type as mandatory AVP
 
#54: OC-Report-Type as mandatory AVP
 
Now in chapter 4.6:
 
 The default value of the OC-Report-Type AVP is 0 (i.e. the host  
report).
 
This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
 
--
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
  Type:  defect                             |  Bartolomé
Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
Severity:  Active WG Document                 |    Version:  1.0
                                            |   Keywords:
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
 
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>
dime <http://tools.ietf.org/wg/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
 
 


        

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


      

      




    

    

  


--------------060909090901010404000206--


From nobody Mon Mar 24 05:49: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 80B8A1A01F5 for ; Mon, 24 Mar 2014 05:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level: 
X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] 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 EP_a7LdjhKRc for ; Mon, 24 Mar 2014 05:49:39 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0551A01F2 for ; Mon, 24 Mar 2014 05:49:39 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id e16so3565469lan.2 for ; Mon, 24 Mar 2014 05:49:38 -0700 (PDT)
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=EWCABbriJWdIjpe5fgItJt3rp+OK14i4QznKMav2MU4=; b=EO1HR2FQHuFJoQtuNisD9nUslTaX20BWun5VpSh/4rf9ICwa3e67gC41xhi5U40y9e fjDlTqnw6N/RyUPP5FJGYK5lTiIKTAR0l+uIIYEst768YeVD9SK7GIA/d215HEWxMv98 UnyyHP5VF5Ij70mveKjDa9Fvxtnbqt4m3cJHHVIlZWDTJZjyqfu+lAMrc83LOWBvW5oB +Nc4c9g69nwPooxLn7vqR1o7qdTLB6pd/i0vP53/gJgBDman0DvrGLvliT75F1Gusp/4 XTVj1NaXWTwdkgLGFz/9FF5WuNYvE8/MhNJ0Ptrb5Br+nNI128C7t+m6kLVFwtz0pJdV sOig==
X-Received: by 10.152.1.8 with SMTP id 8mr45432206lai.1.1395665377898; Mon, 24 Mar 2014 05:49:37 -0700 (PDT)
Received: from [192.168.250.226] ([194.100.71.98]) by mx.google.com with ESMTPSA id z10sm9487884lbu.1.2014.03.24.05.49.35 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Mar 2014 05:49:36 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151C9869@DEMUMBX014.nsn-intra.net>
Date: Mon, 24 Mar 2014 14:49:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4971B712-2F1F-4388-AE76-CB640F8DEB46@gmail.com>
References: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com> <532C3D99.30809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C9869@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VOt5UnbymL4tR_3UxthZROg_R9s
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] DOIC Overview of Operation
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, 24 Mar 2014 12:49:41 -0000

Thanks for the text (and additions to it). Looks about good to me.
One clarification inline:


On Mar 21, 2014, at 4:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)" =
 wrote:

> Steve,
> =20
> please find some minor comments inline.
> =20
> Ulrich
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve =
Donovan
> Sent: Friday, March 21, 2014 2:25 PM
> To: dime@ietf.org
> Subject: Re: [Dime] DOIC Overview of Operation
> =20
> I propose that we close issue 41 with Ben's text into section 3.0.  I =
also propose that we open a new issue to capture the need to make the =
rest of section 3 consistent.
>=20
> I will do so unless I hear an alternative suggestion soon.
>=20
> Regards,
>=20
> Steve
>=20
> On 3/17/14 1:34 PM, Ben Campbell wrote:
> Hi,
> =20
> the dime-ovli currently lacks any sort of high-level overview of =
operation. As written, it jumps into details without giving the reader a =
high-level view of how it works. I think that will create confusion for =
new readers that have not been involved in discussions so far.
> =20
> I propose adding the following text to the beginning of section 3. =
This would be entirely non-normative. I recognize that this would create =
some redundancies with later subsections. I don't address those here, =
but we would need to do so when integrating this text if we agree to add =
it.
> =20
> Thanks!
> =20
> Ben.
> =20
> --------------------------
> =20
>    The Diameter Overload Information Conveyance (DOIC) mechanism =
allows
>    Diameter nodes to request other nodes to perform overload abatement
>    actions, that is, actions to reduce the load offered to the
>    overloaded node.
> =20
>    A Diameter node that supports DOIC is known as a "DOIC endpoint".
>    Any Diameter node can act as a DOIC endpoint, including clients,
>    servers, and agents.  DOIC endpoints are further divided into
>    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
>    overload abatement by sending an Overload Report (OLR) to one or =
more
>    reacting nodes.
> =20
>    A reacting node consumes OLRs, and performs whatever actions are
>    needed to fulfill the requests.  A Reporting node may report =
overload
>    on its own behalf, or on behalf of other (typically upstream) =
nodes.
>    Likewise, a reacting node may perform overload abatement on its own
>    behalf, or on behalf of other (typically downstream) nodes.
> =20
>    A node's role as a DOIC endpoint is independent of its Diameter =
role.
>    For example, Diameter relay and proxy agents may act as DOIC
>    endpoints, even though they are not endpoints in the Diameter =
sense.
>    Since Diameter enables bi-directional applications, where Diameter
>    servers can send requests towards Diameter clients, a given =
Diameter
>    node can simultaneously act as a reporting node and reacting node.
> =20
>    Likewise, an relay or proxy agent may act as a reacting node from =
the
>    perspective of upstream nodes, and a reporting node from the
>    perspective of downstream nodes.
> =20
>    DOIC endpoints do not generate new messages to carry DOIC related
>    information.  Rather, they "piggyback" DOIC information over =
existing
>    Diameter messages by inserting new AVPs into existing Diameter
>    requests and responses.

JiK: This applies to existing applications or new application where
DOIC is just a feature on top of one. Nothing prevents us defining a
DOIC-only application using this spec as the base. This should be
reflected?

> Nodes indicate support for DOIC, and any
>    needed DOIC parameters by inserting an OC_Supported_Features AVP
>    (Section 4.1) into existing requests and responses.  Reporting =
nodes
>    send OLRs by inserting OC-OLR AVPs[Wiehe, Ulrich (NSN - DE/Munich)] =
 into existing responses.  (Section 4.3)
> =20
>    A given OLR applies to the Diameter [Wiehe, Ulrich (NSN - =
DE/Munich)] orig-realm and application of the
>    Diameter [Wiehe, Ulrich (NSN - DE/Munich)] response message that =
carries it.  If a reporting node supports more
>    than one realm and/or application, it reports independently for =
each
>    combination of realm and application.  Similarly, OC-Feature-Vector
>    AVPs apply to the realm and application of the enclosing message.
>    This implies that a node may support DOIC for one application =
and/or
>    realm, but not another, and may indicate different DOIC parameters
>    for each application and realm for which it supports DOIC.
> =20
>    Reacting nodes perform overload abatement according to an =
agreed-upon
>    abatement algorithm.  An abatement algorithm defines the meaning of
>    the parameters of an OLR, and the procedures required for overload
>    abatement.  This document specifies a single must-support =
algorithm,
>    namely the "loss" algorithm [ref?].  Future specifications may
>    introduce new algorithms.
> =20
>    Overload conditions may vary in scope.  For example, a single
>    Diameter node may be overloaded, in which case reacting nodes may
>    reasonably attempt to send throttled requests to other destinations
>    or via other agents
> [Wiehe, Ulrich (NSN - DE/Munich)] sending requests to the same =
destination via other agents does not help and should actually be =
avoided
> .  On the other hand, an entire Diameter realm may
>    be overloaded, in which case such attempts would do harm.  DOIC =
OLRs
>    have a concept of "report type" (Section 4.6), where the type =
defines
>    such behaviors.  Report types are extensible.  This document =
defines
>    report types for overload of a specific server, and for overload of
>    an entire realm.
> =20
>    While a reporting node sends OLRs to "adjacent" reacting nodes, =
nodes
>    that are "adjacent" for DOIC purposes may not be adjacent from a
>    Diameter, or transport, perspective.  For example, one or more
>    Diameter agents that do not support DOIC may exist between a given
>    pair of reporting and reacting nodes, as long as those agents pass
>    unknown AVPs through unmolested.  The report types described in =
this
>    document can safely pass through non-supporting agents.  This may =
not
>    be true for report types defined in future specifications.  =
Documents
>    that introduce new report types MUST describe any limitations on
>    their use across non-supporting agents.
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Mon Mar 24 05:58:56 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 DACB61A01F5 for ; Mon, 24 Mar 2014 05:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7LjWWM0c-9gk for ; Mon, 24 Mar 2014 05:58:52 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A05411A01F2 for ; Mon, 24 Mar 2014 05:58:52 -0700 (PDT)
Received: from localhost ([127.0.0.1]:47138 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WS4Si-0000p0-Ck; Mon, 24 Mar 2014 13:58:44 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Mar 2014 12:58:44 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/45#comment:1
Message-ID: <072.cd3d7ca433f920b14742809a3275e0a0@trac.tools.ietf.org>
References: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>
X-Trac-Ticket-ID: 45
In-Reply-To: <057.2153d3a0ed57933cb4ec7468d82db1d9@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xPlnida9HB_ZGB0MGTT_Idg4-wc
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #45 (draft-docdt-dime-ovli): Why is a validity duration of 0 disallowed?
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, 24 Mar 2014 12:58:55 -0000

#45: Why is a validity duration of 0 disallowed?

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Section 4.5, Paragraph 1:

 First sentence - change "since" to "after". (Editorial change)

 Change:

 Validity duration values 0
    (i.e., 0 seconds) and above 86400 (i.e., 24 hours) MUST NOT be used.
    Invalid validity duration values are treated as if the OC-Validity-
    Duration AVP were not present.


 To:

 Validity duration with values above 86400 (i.e.; 24 hours) MUST NOT be
 used.  Invalid duration values are treated as if the OC-Validity-Duration
 AVP were not present and result in the default value being used.

 Paragraph 3:

 Replace:

 This leaves no need for the
    reacting node to reason or guess the overload condition of the
    reporting node.


 With:

 This is achieved by sending an updated overload report (meaning it must
 contain a new sequence number) with the OC-Validity-Duration AVP value set
 to zero ("0").

 Section 5.5.2, Paragraph 7

 Change:

    value == 0
       Indicates explicitly the end of overload condition and the
       reacting node SHOULD NOT apply the traffic abatement algorithm
       procedures anymore for the given reporting node (or realm).

 To:
     value == 0

           Indicates that no traffic reduction has been requested.   As a
 result the overload state, including the sequence number, MUST NOT be
 removed and future overload reports of the same type from the same
 reporting node must follow the rules for new sequence numbers.

 New paragraphs at end of the section:

 A value of zero ("0") received in the OC-Validity-Duration in an updated
 overload report indicates that the overload condition has ended and that
 the overload state is no longer valid.

 In the case that the validity duration expires or is explicitly signaled
 as being no longer valid the state associated with the overload report
 MUST be removed and any abatement associated with the overload report MUST
 be ended.  After removing the overload state the sequence number MUST NOT
 be used for future comparisons of sequence numbers.

 Section 5.5.3, New paragraph at the end:

 The reporting node SHOULD indicate the end of an overload occurrence by
 sending a new OLR with OC-Validity-Duration set to a value of zero ("0").
 The reporting node SHOULD insure that all reacting nodes receive the
 updated overload report.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Mon Mar 24 06:19:55 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 C77621A01B4 for ; Mon, 24 Mar 2014 06:19:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.18
X-Spam-Level: **
X-Spam-Status: No, score=2.18 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, 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 e0o_6FJv8PyE for ; Mon, 24 Mar 2014 06:19:48 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF801A01AE for ; Mon, 24 Mar 2014 06:19:48 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54828 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS4n2-0005EY-Cn; Mon, 24 Mar 2014 06:19:46 -0700
Message-ID: <533030F0.3060902@usdonovans.com>
Date: Mon, 24 Mar 2014 08:19:44 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Jouni Korhonen ,  "Wiehe, Ulrich (NSN - DE/Munich)" 
References: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com> <532C3D99.30809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C9869@DEMUMBX014.nsn-intra.net> <4971B712-2F1F-4388-AE76-CB640F8DEB46@gmail.com>
In-Reply-To: <4971B712-2F1F-4388-AE76-CB640F8DEB46@gmail.com>
Content-Type: multipart/alternative; boundary="------------070305050101070503000803"
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/B2Cs9FKsb7qoHVANGsOoAM1mGaU
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] DOIC Overview of Operation
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, 24 Mar 2014 13:19:51 -0000

This is a multi-part message in MIME format.
--------------070305050101070503000803
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Jouni,
Ulrich,

Given that this is a non normative section and that we can continue to
update the document after -02 is publiched, I'm updating the document
with Ben's text as is for now.  I propose we address your comments as
part of the -02 draft review. 

Regards,

Steve

On 3/24/14 7:49 AM, Jouni Korhonen wrote:
> Thanks for the text (and additions to it). Looks about good to me.
> One clarification inline:
>
>
> On Mar 21, 2014, at 4:33 PM, "Wiehe, Ulrich (NSN - DE/Munich)"  wrote:
>
>> Steve,
>>  
>> please find some minor comments inline.
>>  
>> Ulrich
>>  
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
>> Sent: Friday, March 21, 2014 2:25 PM
>> To: dime@ietf.org
>> Subject: Re: [Dime] DOIC Overview of Operation
>>  
>> I propose that we close issue 41 with Ben's text into section 3.0.  I also propose that we open a new issue to capture the need to make the rest of section 3 consistent.
>>
>> I will do so unless I hear an alternative suggestion soon.
>>
>> Regards,
>>
>> Steve
>>
>> On 3/17/14 1:34 PM, Ben Campbell wrote:
>> Hi,
>>  
>> the dime-ovli currently lacks any sort of high-level overview of operation. As written, it jumps into details without giving the reader a high-level view of how it works. I think that will create confusion for new readers that have not been involved in discussions so far.
>>  
>> I propose adding the following text to the beginning of section 3. This would be entirely non-normative. I recognize that this would create some redundancies with later subsections. I don't address those here, but we would need to do so when integrating this text if we agree to add it.
>>  
>> Thanks!
>>  
>> Ben.
>>  
>> --------------------------
>>  
>>    The Diameter Overload Information Conveyance (DOIC) mechanism allows
>>    Diameter nodes to request other nodes to perform overload abatement
>>    actions, that is, actions to reduce the load offered to the
>>    overloaded node.
>>  
>>    A Diameter node that supports DOIC is known as a "DOIC endpoint".
>>    Any Diameter node can act as a DOIC endpoint, including clients,
>>    servers, and agents.  DOIC endpoints are further divided into
>>    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
>>    overload abatement by sending an Overload Report (OLR) to one or more
>>    reacting nodes.
>>  
>>    A reacting node consumes OLRs, and performs whatever actions are
>>    needed to fulfill the requests.  A Reporting node may report overload
>>    on its own behalf, or on behalf of other (typically upstream) nodes.
>>    Likewise, a reacting node may perform overload abatement on its own
>>    behalf, or on behalf of other (typically downstream) nodes.
>>  
>>    A node's role as a DOIC endpoint is independent of its Diameter role.
>>    For example, Diameter relay and proxy agents may act as DOIC
>>    endpoints, even though they are not endpoints in the Diameter sense.
>>    Since Diameter enables bi-directional applications, where Diameter
>>    servers can send requests towards Diameter clients, a given Diameter
>>    node can simultaneously act as a reporting node and reacting node.
>>  
>>    Likewise, an relay or proxy agent may act as a reacting node from the
>>    perspective of upstream nodes, and a reporting node from the
>>    perspective of downstream nodes.
>>  
>>    DOIC endpoints do not generate new messages to carry DOIC related
>>    information.  Rather, they "piggyback" DOIC information over existing
>>    Diameter messages by inserting new AVPs into existing Diameter
>>    requests and responses.
> JiK: This applies to existing applications or new application where
> DOIC is just a feature on top of one. Nothing prevents us defining a
> DOIC-only application using this spec as the base. This should be
> reflected?
>
>> Nodes indicate support for DOIC, and any
>>    needed DOIC parameters by inserting an OC_Supported_Features AVP
>>    (Section 4.1) into existing requests and responses.  Reporting nodes
>>    send OLRs by inserting OC-OLR AVPs[Wiehe, Ulrich (NSN - DE/Munich)]  into existing responses.  (Section 4.3)
>>  
>>    A given OLR applies to the Diameter [Wiehe, Ulrich (NSN - DE/Munich)] orig-realm and application of the
>>    Diameter [Wiehe, Ulrich (NSN - DE/Munich)] response message that carries it.  If a reporting node supports more
>>    than one realm and/or application, it reports independently for each
>>    combination of realm and application.  Similarly, OC-Feature-Vector
>>    AVPs apply to the realm and application of the enclosing message.
>>    This implies that a node may support DOIC for one application and/or
>>    realm, but not another, and may indicate different DOIC parameters
>>    for each application and realm for which it supports DOIC.
>>  
>>    Reacting nodes perform overload abatement according to an agreed-upon
>>    abatement algorithm.  An abatement algorithm defines the meaning of
>>    the parameters of an OLR, and the procedures required for overload
>>    abatement.  This document specifies a single must-support algorithm,
>>    namely the "loss" algorithm [ref?].  Future specifications may
>>    introduce new algorithms.
>>  
>>    Overload conditions may vary in scope.  For example, a single
>>    Diameter node may be overloaded, in which case reacting nodes may
>>    reasonably attempt to send throttled requests to other destinations
>>    or via other agents
>> [Wiehe, Ulrich (NSN - DE/Munich)] sending requests to the same destination via other agents does not help and should actually be avoided
>> .  On the other hand, an entire Diameter realm may
>>    be overloaded, in which case such attempts would do harm.  DOIC OLRs
>>    have a concept of "report type" (Section 4.6), where the type defines
>>    such behaviors.  Report types are extensible.  This document defines
>>    report types for overload of a specific server, and for overload of
>>    an entire realm.
>>  
>>    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
>>    that are "adjacent" for DOIC purposes may not be adjacent from a
>>    Diameter, or transport, perspective.  For example, one or more
>>    Diameter agents that do not support DOIC may exist between a given
>>    pair of reporting and reacting nodes, as long as those agents pass
>>    unknown AVPs through unmolested.  The report types described in this
>>    document can safely pass through non-supporting agents.  This may not
>>    be true for report types defined in future specifications.  Documents
>>    that introduce new report types MUST describe any limitations on
>>    their use across non-supporting agents.
>>  
>> _______________________________________________
>> 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
>


--------------070305050101070503000803
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Jouni,

      Ulrich,

      

      Given that this is a non normative section and that we can
      continue to update the document after -02 is publiched, I'm
      updating the document with Ben's text as is for now.  I propose we
      address your comments as part of the -02 draft review.  

      

      Regards,

      

      Steve

      

    
    
On 3/24/14 7:49 AM, Jouni Korhonen
      wrote:

    

    

      
Thanks for the text (and additions to it). Looks about good to me.
One clarification inline:


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



      

        
Steve,
 
please find some minor comments inline.
 
Ulrich
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 2:25 PM
To: dime@ietf.org
Subject: Re: [Dime] DOIC Overview of Operation
 
I propose that we close issue 41 with Ben's text into section 3.0.  I also propose that we open a new issue to capture the need to make the rest of section 3 consistent.

I will do so unless I hear an alternative suggestion soon.

Regards,

Steve

On 3/17/14 1:34 PM, Ben Campbell wrote:
Hi,
 
the dime-ovli currently lacks any sort of high-level overview of operation. As written, it jumps into details without giving the reader a high-level view of how it works. I think that will create confusion for new readers that have not been involved in discussions so far.
 
I propose adding the following text to the beginning of section 3. This would be entirely non-normative. I recognize that this would create some redundancies with later subsections. I don't address those here, but we would need to do so when integrating this text if we agree to add it.
 
Thanks!
 
Ben.
 
--------------------------
 
   The Diameter Overload Information Conveyance (DOIC) mechanism allows
   Diameter nodes to request other nodes to perform overload abatement
   actions, that is, actions to reduce the load offered to the
   overloaded node.
 
   A Diameter node that supports DOIC is known as a "DOIC endpoint".
   Any Diameter node can act as a DOIC endpoint, including clients,
   servers, and agents.  DOIC endpoints are further divided into
   "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
   overload abatement by sending an Overload Report (OLR) to one or more
   reacting nodes.
 
   A reacting node consumes OLRs, and performs whatever actions are
   needed to fulfill the requests.  A Reporting node may report overload
   on its own behalf, or on behalf of other (typically upstream) nodes.
   Likewise, a reacting node may perform overload abatement on its own
   behalf, or on behalf of other (typically downstream) nodes.
 
   A node's role as a DOIC endpoint is independent of its Diameter role.
   For example, Diameter relay and proxy agents may act as DOIC
   endpoints, even though they are not endpoints in the Diameter sense.
   Since Diameter enables bi-directional applications, where Diameter
   servers can send requests towards Diameter clients, a given Diameter
   node can simultaneously act as a reporting node and reacting node.
 
   Likewise, an relay or proxy agent may act as a reacting node from the
   perspective of upstream nodes, and a reporting node from the
   perspective of downstream nodes.
 
   DOIC endpoints do not generate new messages to carry DOIC related
   information.  Rather, they "piggyback" DOIC information over existing
   Diameter messages by inserting new AVPs into existing Diameter
   requests and responses.


      

      
JiK: This applies to existing applications or new application where
DOIC is just a feature on top of one. Nothing prevents us defining a
DOIC-only application using this spec as the base. This should be
reflected?



      

        
Nodes indicate support for DOIC, and any
   needed DOIC parameters by inserting an OC_Supported_Features AVP
   (Section 4.1) into existing requests and responses.  Reporting nodes
   send OLRs by inserting OC-OLR AVPs[Wiehe, Ulrich (NSN - DE/Munich)]  into existing responses.  (Section 4.3)
 
   A given OLR applies to the Diameter [Wiehe, Ulrich (NSN - DE/Munich)] orig-realm and application of the
   Diameter [Wiehe, Ulrich (NSN - DE/Munich)] response message that carries it.  If a reporting node supports more
   than one realm and/or application, it reports independently for each
   combination of realm and application.  Similarly, OC-Feature-Vector
   AVPs apply to the realm and application of the enclosing message.
   This implies that a node may support DOIC for one application and/or
   realm, but not another, and may indicate different DOIC parameters
   for each application and realm for which it supports DOIC.
 
   Reacting nodes perform overload abatement according to an agreed-upon
   abatement algorithm.  An abatement algorithm defines the meaning of
   the parameters of an OLR, and the procedures required for overload
   abatement.  This document specifies a single must-support algorithm,
   namely the "loss" algorithm [ref?].  Future specifications may
   introduce new algorithms.
 
   Overload conditions may vary in scope.  For example, a single
   Diameter node may be overloaded, in which case reacting nodes may
   reasonably attempt to send throttled requests to other destinations
   or via other agents
[Wiehe, Ulrich (NSN - DE/Munich)] sending requests to the same destination via other agents does not help and should actually be avoided
.  On the other hand, an entire Diameter realm may
   be overloaded, in which case such attempts would do harm.  DOIC OLRs
   have a concept of "report type" (Section 4.6), where the type defines
   such behaviors.  Report types are extensible.  This document defines
   report types for overload of a specific server, and for overload of
   an entire realm.
 
   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
   that are "adjacent" for DOIC purposes may not be adjacent from a
   Diameter, or transport, perspective.  For example, one or more
   Diameter agents that do not support DOIC may exist between a given
   pair of reporting and reacting nodes, as long as those agents pass
   unknown AVPs through unmolested.  The report types described in this
   document can safely pass through non-supporting agents.  This may not
   be true for report types defined in future specifications.  Documents
   that introduce new report types MUST describe any limitations on
   their use across non-supporting agents.
 
_______________________________________________
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


      

      



    

    

  


--------------070305050101070503000803--


From nobody Mon Mar 24 06:24:31 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 60C9C1A0206 for ; Mon, 24 Mar 2014 06:24:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0doD2jFW01n5 for ; Mon, 24 Mar 2014 06:24:26 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5837B1A01B4 for ; Mon, 24 Mar 2014 06:24:08 -0700 (PDT)
Received: from localhost ([127.0.0.1]:48526 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WS4rC-000858-8S; Mon, 24 Mar 2014 14:24:02 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Mar 2014 13:24:02 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/41#comment:1
Message-ID: <072.d5e30cfd5cc5ac461bc3774ad9853b2b@trac.tools.ietf.org>
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org>
X-Trac-Ticket-ID: 41
In-Reply-To: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/8UNR6DLK3ZkSRx29uvLxy6P8c1k
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
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, 24 Mar 2014 13:24:28 -0000

#41: Need better overview

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The following wording for section 3.0 was added.  A new issue will be
 opened to reflect that the remainder of section 3 needs to be made
 consistent with the current state of the DIOC solution.

 -----

    The Diameter Overload Information Conveyance (DOIC) mechanism allows
    Diameter nodes to request other nodes to perform overload abatement
    actions, that is, actions to reduce the load offered to the
    overloaded node.

    A Diameter node that supports DOIC is known as a "DOIC endpoint".
    Any Diameter node can act as a DOIC endpoint, including clients,
    servers, and agents.  DOIC endpoints are further divided into
    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
    overload abatement by sending an Overload Report (OLR) to one or more
    reacting nodes.

    A reacting node consumes OLRs, and performs whatever actions are
    needed to fulfill the requests.  A Reporting node may report overload
    on its own behalf, or on behalf of other (typically upstream) nodes.
    Likewise, a reacting node may perform overload abatement on its own
    behalf, or on behalf of other (typically downstream) nodes.

    A node's role as a DOIC endpoint is independent of its Diameter role.
    For example, Diameter relay and proxy agents may act as DOIC
    endpoints, even though they are not endpoints in the Diameter sense.
    Since Diameter enables bi-directional applications, where Diameter
    servers can send requests towards Diameter clients, a given Diameter
    node can simultaneously act as a reporting node and reacting node.

    Likewise, an relay or proxy agent may act as a reacting node from the
    perspective of upstream nodes, and a reporting node from the
    perspective of downstream nodes.

    DOIC endpoints do not generate new messages to carry DOIC related
    information.  Rather, they "piggyback" DOIC information over existing
    Diameter messages by inserting new AVPs into existing Diameter
    requests and responses.  Nodes indicate support for DOIC, and any
    needed DOIC parameters by inserting an OC_Supported_Features AVP
    (Section 4.1) into existing requests and responses.  Reporting nodes
    send OLRs by inserting OC-OLR AVPs.  (Section 4.3)

    A given OLR applies to the Diameter realm and application of the
    Diameter message that carries it.  If a reporting node supports more
    than one realm and/or application, it reports independently for each
    combination of realm and application.  Similarly, OC-Feature-Vector
    AVPs apply to the realm and application of the enclosing message.
    This implies that a node may support DOIC for one application and/or
    realm, but not another, and may indicate different DOIC parameters
    for each application and realm for which it supports DOIC.

    Reacting nodes perform overload abatement according to an agreed-upon
    abatement algorithm.  An abatement algorithm defines the meaning of
    the parameters of an OLR, and the procedures required for overload
    abatement.  This document specifies a single must-support algorithm,
    namely the "loss" algorithm [ref?].  Future specifications may
    introduce new algorithms.

    Overload conditions may vary in scope.  For example, a single
    Diameter node may be overloaded, in which case reacting nodes may
    reasonably attempt to send throttled requests to other destinations
    or via other agents.  On the other hand, an entire Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an entire realm.

    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
    that are "adjacent" for DOIC purposes may not be adjacent from a
    Diameter, or transport, perspective.  For example, one or more
    Diameter agents that do not support DOIC may exist between a given
    pair of reporting and reacting nodes, as long as those agents pass
    unknown AVPs through unmolested.  The report types described in this
    document can safely pass through non-supporting agents.  This may not
    be true for report types defined in future specifications.  Documents
    that introduce new report types MUST describe any limitations on
    their use across non-supporting agents.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Mon Mar 24 06:27:31 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 3B2CB1A01B4 for ; Mon, 24 Mar 2014 06:27:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 QPvbXomhkRO4 for ; Mon, 24 Mar 2014 06:27:28 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A57D71A01BA for ; Mon, 24 Mar 2014 06:27:28 -0700 (PDT)
Received: from localhost ([127.0.0.1]:48671 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WS4uR-0004b2-Ll; Mon, 24 Mar 2014 14:27:23 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Mar 2014 13:27:23 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/62
Message-ID: <066.eba6aa0bd68b42efe99ac62bc852b2b5@trac.tools.ietf.org>
X-Trac-Ticket-ID: 62
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/SAiDVJjWNXt-fxvaiFWo2r0lB7k
Cc: dime@ietf.org
Subject: [Dime] [dime] #62 (draft-docdt-dime-ovli): SEction 3 needs to be made consistent with DIOC solution
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, 24 Mar 2014 13:27:30 -0000

#62: SEction 3 needs to be made consistent with DIOC solution

 There have been a number of updates to the DOIC solution that have made
 aspect of section 3 inconsistent with the solution.  The section needs to
 be reworked to reflect the solution as a whole.

 In addition, all normative statements should be moved out of section 3 and
 into a more appropriate section, keeping section 3 an overview section.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-docdt-dime-
  srdonovan@usdonovans.com           |  ovli@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  draft-docdt-dime-ovli    |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: 
dime 


From nobody Mon Mar 24 06:38:44 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 93D081A0202 for ; Mon, 24 Mar 2014 06:38:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.561
X-Spam-Level: **
X-Spam-Status: No, score=2.561 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, 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 LSXzh9c-jhLz for ; Mon, 24 Mar 2014 06:38:40 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8504E1A01BC for ; Mon, 24 Mar 2014 06:38:40 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54952 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS55K-0004Ui-2s for dime@ietf.org; Mon, 24 Mar 2014 06:38:39 -0700
Message-ID: <5330355D.4080204@usdonovans.com>
Date: Mon, 24 Mar 2014 08:38:37 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090809060005000605070806"
X-OutGoing-Spam-Status: No, score=-1.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/DPYfHZvpG8CvOKjwIFOnxYm0RPY
Subject: [Dime] Updated snapshot of -02 draft
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, 24 Mar 2014 13:38:42 -0000

This is a multi-part message in MIME format.
--------------090809060005000605070806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

I have incorporated the wording for issues 29, 30, 41 and 45 into the
current snapshot of the -02 draft.

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-02.txt

As a reminder, my intent is to submit the -02 version on Thursday, as I
will be traveling on Friday.

Please work to close any open issues that you want to have reflected in
the -02 draft.

Regards,

Steve

--------------090809060005000605070806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      I have incorporated the wording for issues 29, 30, 41 and 45 into
      the current snapshot of the -02 draft.

    

    https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-02.txt

        

      As a reminder, my intent is to submit the -02 version on
      Thursday, as I will be traveling on Friday.

      

      Please work to close any open issues that you want to have
      reflected in the -02 draft.

      

      Regards,

      

      Steve

    
  


--------------090809060005000605070806--


From nobody Mon Mar 24 06:42: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 808011A0206 for ; Mon, 24 Mar 2014 06:42:11 -0700 (PDT)
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 knKv714hdhlh for ; Mon, 24 Mar 2014 06:42:09 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 30B481A0213 for ; Mon, 24 Mar 2014 06:42:09 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:54955 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS58h-0000HB-39 for dime@ietf.org; Mon, 24 Mar 2014 06:42:08 -0700
Message-ID: <5330362E.10005@usdonovans.com>
Date: Mon, 24 Mar 2014 08:42:06 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <081.d67cf98bf010626435cad725cb5095f0@trac.tools.ietf.org> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050908050708030403000905"
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/6uBz_CCrFdXYj9z6Q4km_LvAZPQ
Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages
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, 24 Mar 2014 13:42:11 -0000

This is a multi-part message in MIME format.
--------------050908050708030403000905
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Janet,

Well, in the sense that the current overload condition caused the
current abatement request, the wording is mostly correct.  I agree it
can be made more clear.  It might be better if we changed the word
condition to report.

Steve

On 3/21/14 4:10 PM, Janet P Gunn wrote:
> Just a question.
>
> In the phrase "it
>    applies the traffic abatement based on the commonly supported/selected
>    algorithm with the reporting node and the current overload condition."
>
> Is it really the "current overload CONDITION", or the "current
> abatement REQUESTED"?
>
> If the message is asking for a 10% reduction in traffic, that does not
> actually identify the "current overload condition".
>
>
> Janet
>
>
>
>
> From:        "dime issue tracker" 
> To:        srdonovan@usdonovans.com
> Cc:        dime@ietf.org
> Date:        03/21/2014 09:33 AM
> Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli):
> OC-Supported-Features AVP in answer messages
> Sent by:        "DiME" 
> ------------------------------------------------------------------------
>
>
>
> #30: OC-Supported-Features AVP in answer messages
>
> Changes (by srdonovan@usdonovans.com):
>
> * status:  new => closed
> * resolution:   => fixed
>
>
> Comment:
>
> We reached the tentative agreement in the DIME meeting on the following:
>
> OC-Supported-Features handling:
>
> Agreed: OC-Supported-Features AVP MUST be included in all answer messages
> (we had already agreed that it must be included in all request messages).
> Agreed: Reacting node advertises all supported algorithms;
> Agreed: Reporting node responds with the single algorithm it will be
> using;
> Agreed: Handling of other feature bits is defined in the extension drafts
>
> Based on this I believe we need the text changes outlined below.
>
> Let me know if I have missed any.
>
> If we agree on the text changes then we can close the issue and I'll
> update the document accordingly.
>
> Regards,
>
> Steve
>
> -----
>
> Section 5.3.2, paragraph 1:
>
> Change:
>
> The answer message
>    initiating endpoint MAY announce as many supported capabilities as it
>    has (the announced set is a subject to local policy and
>    configuration). However, at least one of the announced capabilities
>    MUST be the same as received in the request message.
>
>
> To:
>
> The reporting node MUST include the OC-Supported-Features AVP in all
> response messages for transactions where the request message included the
> OC-Supported-Features AVP.  The reporting node MUST announce support of
> the single algorithm that the reporting node will request the reacting
> node to use to mitigate overload instances.  The reporting node MUST NOT
> change the selected algorithm during a period of time that it is in an
> overload state and, as a result, is sending OC-OLR AVPs in answer
> messages.
>
>     Note: There will always be at least one algorithm supported by both
> the reacting and reporting nodes as all nodes that support DOIC must
> support the loss algorithm defined in this document.
>
> The handling of feature bits in the OC-Feature-Vector AVP that are not
> associated with overload abatement algorithms MUST be specified by the
> extension that defines the feature.
>
> Paragraph 2:
>
> Change:
>
> The answer message initiating endpoint MUST NOT include any overload
>    control solution defined AVPs into its answer messages if the request
>    message initiating endpoint has not indicated support at the
>    beginning of the created session (or transaction in a case of non-
>    session state maintaining applications). The same also applies if
>    none of the announced capabilities match between the two endpoints.
>
> To:
>
> The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR
> AVP or any other overload control AVPs defined in extension drafts in
> response messages for transaction where the request message does not
> include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features
> AVP in the request message indicates that the sender of the request
> message does not support DOIC.
>
> Section 5.5.2, Paragraph 1:
>
> Change:
>
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP or indirectly remembering the previously
>    used traffic abatement algorithm with the given reporting node.
>
> To: (removing the last portion of the last sentence)
>
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP.
>
> -----
>
> +1, with a minor suggested edit:
>
> On Mar 17, 2014, at 2:03 PM, Steve Donovan 
> wrote:
>
> > Change:
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
> >    applies the traffic abatement based on the commonly supported
> >    algorithm with the reporting node and the current overload condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP or indirectly remembering the previously
> >    used traffic abatement algorithm with the given reporting node.
>
> > To: (removing the last portion of the last sentence)
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
> >    applies the traffic abatement based on the commonly supported
>
> s/"commonly supported"/selected
>
> "Commonly supported" is no longer descriptive. There may be several
> commonly supported algorithm, but the reporting node selects just one.
>
> >    algorithm with the reporting node and the current overload condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP.
> >
>
> -- 
> --------------------------------------+---------------------------
> Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
>     Type:  defect                    |      Status:  closed
> Priority:  major                     |   Milestone:
> Component:  draft-docdt-dime-ovli     |     Version:
> Severity:  Active WG Document        |  Resolution:  fixed
> Keywords:                            |
> --------------------------------------+---------------------------
>
> Ticket URL: 
> 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


--------------050908050708030403000905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Janet,

      

      Well, in the sense that the current overload condition caused the
      current abatement request, the wording is mostly correct.  I agree
      it can be made more clear.  It might be better if we changed the
      word condition to report.

      

      Steve

      

    
    
On 3/21/14 4:10 PM, Janet P Gunn wrote:

    

    
Just a question.
      

      

      In the phrase "
          it

             applies the traffic abatement based on the commonly
          supported/selected

             algorithm with the reporting node and the current overload
          condition."
      

      

      Is it really the "current overload CONDITION",
          or the "current abatement REQUESTED"?
      

      

      If the message is asking for a 10% reduction in
          traffic,
          that does not actually identify the "current overload
          condition".
      

      

      

      Janet
      

      

      

      

      

      From:      
         "dime issue tracker"
        <trac+dime@grenache.tools.ietf.org>
      

      To:      
         srdonovan@usdonovans.com
      

      Cc:      
         dime@ietf.org
      

      Date:      
         03/21/2014 09:33 AM
      

      Subject:    
           Re: [Dime] [dime]
        #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer
        messages
      

      Sent by:    
           "DiME"
        <dime-bounces@ietf.org>
      

      

      

      

      

      #30: OC-Supported-Features AVP in answer
          messages

          

          Changes (by srdonovan@usdonovans.com):

          

          * status:  new => closed

          * resolution:   => fixed

          

          

          Comment:

          

          We reached the tentative agreement in the DIME meeting on the
          following:

          

          OC-Supported-Features handling:

          

          Agreed: OC-Supported-Features AVP MUST be included in all
          answer messages

          (we had already agreed that it must be included in all request
          messages).

          Agreed: Reacting node advertises all supported algorithms;

          Agreed: Reporting node responds with the single algorithm it
          will be

          using;

          Agreed: Handling of other feature bits is defined in the
          extension drafts

          

          Based on this I believe we need the text changes outlined
          below.

          

          Let me know if I have missed any.

          

          If we agree on the text changes then we can close the issue
          and I'll

          update the document accordingly.

          

          Regards,

          

          Steve

          

          -----

          

          Section 5.3.2, paragraph 1:

          

          Change:

          

          The answer message

             initiating endpoint MAY announce as many supported
          capabilities
          as it

             has (the announced set is a subject to local policy and

             configuration). However, at least one of the announced
          capabilities

             MUST be the same as received in the request message.

          

          

          To:

          

          The reporting node MUST include the OC-Supported-Features AVP
          in all

          response messages for transactions where the request message
          included
          the

          OC-Supported-Features AVP.  The reporting node MUST announce
          support
          of

          the single algorithm that the reporting node will request the
          reacting

          node to use to mitigate overload instances.  The reporting
          node MUST
          NOT

          change the selected algorithm during a period of time that it
          is in an

          overload state and, as a result, is sending OC-OLR AVPs in
          answer

          messages.

          

              Note: There will always be at least one algorithm
          supported
          by both

          the reacting and reporting nodes as all nodes that support
          DOIC must

          support the loss algorithm defined in this document.

          

          The handling of feature bits in the OC-Feature-Vector AVP that
          are not

          associated with overload abatement algorithms MUST be
          specified by the

          extension that defines the feature.

          

          Paragraph 2:

          

          Change:

          

          The answer message initiating endpoint MUST NOT include any
          overload

             control solution defined AVPs into its answer messages if
          the request

             message initiating endpoint has not indicated support at
          the

             beginning of the created session (or transaction in a case
          of non-

             session state maintaining applications). The same also
          applies
          if

             none of the announced capabilities match between the two
          endpoints.

          

          To:

          

          The reporting node MUST NOT include the OC-Supported-Features
          AVP, OC-OLR

          AVP or any other overload control AVPs defined in extension
          drafts in

          response messages for transaction where the request message
          does not

          include the OC-Supported-Features AVP.  Lack of the
          OC-Supported-Features

          AVP in the request message indicates that the sender of the
          request

          message does not support DOIC.

          

          Section 5.5.2, Paragraph 1:

          

          Change:

          

             Once a reacting node receives an OC-OLR AVP from a
          reporting
          node, it

             applies the traffic abatement based on the commonly
          supported

             algorithm with the reporting node and the current overload
          condition.

             The reacting node learns the reporting node supported
          abatement

             algorithms directly from the received answer message
          containing
          the

             OC-Supported-Features AVP or indirectly remembering the
          previously

             used traffic abatement algorithm with the given reporting
          node.

          

          To: (removing the last portion of the last sentence)

          

             Once a reacting node receives an OC-OLR AVP from a
          reporting
          node, it

             applies the traffic abatement based on the commonly
          supported

             algorithm with the reporting node and the current overload
          condition.

             The reacting node learns the reporting node supported
          abatement

             algorithms directly from the received answer message
          containing
          the

             OC-Supported-Features AVP.

          

          -----

          

          +1, with a minor suggested edit:

          

          On Mar 17, 2014, at 2:03 PM, Steve Donovan
          <srdonovan@usdonovans.com>

          wrote:

          

          > Change:

          >    Once a reacting node receives an OC-OLR AVP from a
          reporting
          node, it

          >    applies the traffic abatement based on the commonly
          supported

          >    algorithm with the reporting node and the current
          overload
          condition.

          >    The reacting node learns the reporting node supported
          abatement

          >    algorithms directly from the received answer message
          containing the

          >    OC-Supported-Features AVP or indirectly remembering
          the previously

          >    used traffic abatement algorithm with the given
          reporting
          node.

          

          > To: (removing the last portion of the last sentence)

          >    Once a reacting node receives an OC-OLR AVP from a
          reporting
          node, it

          >    applies the traffic abatement based on the commonly
          supported

          

          s/"commonly supported"/selected

          

          "Commonly supported" is no longer descriptive. There may be
          several

          commonly supported algorithm, but the reporting node selects
          just one.

          

          >    algorithm with the reporting node and the current
          overload
          condition.

          >    The reacting node learns the reporting node supported
          abatement

          >    algorithms directly from the received answer message
          containing the

          >    OC-Supported-Features AVP.

          >

          

          -- 

--------------------------------------+---------------------------

          Reporter:  lionel.morand@orange.com  |      
          Owner:  Ulrich Wiehe

              Type:  defect            
                 |      Status:  closed

          Priority:  major              
                |   Milestone:

          Component:  draft-docdt-dime-ovli     |     Version:

          Severity:  Active WG Document        |  Resolution:
           fixed

          Keywords:                  
                   |

--------------------------------------+---------------------------

          

          Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/30#comment:1>

          dime <http://tools.ietf.org/wg/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


    

    

  


--------------050908050708030403000905--


From nobody Mon Mar 24 06:46: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 7BB7D1A01F8 for ; Mon, 24 Mar 2014 06:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.011
X-Spam-Level: 
X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 F5toWGEM4ZAC for ; Mon, 24 Mar 2014 06:46:18 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id E312A1A01FC for ; Mon, 24 Mar 2014 06:46:18 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2ODkFH0019434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Mar 2014 08:46:17 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <066.eba6aa0bd68b42efe99ac62bc852b2b5@trac.tools.ietf.org>
Date: Mon, 24 Mar 2014 08:46:15 -0500
X-Mao-Original-Outgoing-Id: 417361575.031844-9bb18ab21d44c0ab75313bbf8dfaca14
Content-Transfer-Encoding: quoted-printable
Message-Id: <092B6AED-F6C5-4B26-9673-6C6636FC6E80@nostrum.com>
References: <066.eba6aa0bd68b42efe99ac62bc852b2b5@trac.tools.ietf.org>
To: dime@ietf.org
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jq5SLYGRt4LyD0O_n7ySn3jJJ3M
Cc: draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #62 (draft-docdt-dime-ovli): SEction 3 needs to be made consistent with DIOC solution
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, 24 Mar 2014 13:46:21 -0000

On Mar 24, 2014, at 8:27 AM, dime issue tracker =
 wrote:

> In addition, all normative statements should be moved out of section 3 =
and
> into a more appropriate section, keeping section 3 an overview =
section.

I note the new text ends with a normative statement. OTOH, that's a =
statement concerning other specifications, rather than the protocol =
itself, so it may be okay.

Ben.=


From nobody Mon Mar 24 06: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 E74861A01BC for ; Mon, 24 Mar 2014 06:52:04 -0700 (PDT)
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 kwZUAIXp-lMs for ; Mon, 24 Mar 2014 06:51:59 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5BED41A01C1 for ; Mon, 24 Mar 2014 06:51:58 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2ODpX3g000061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Mar 2014 08:51:35 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2ODpWs9020903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 14:51:32 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 24 Mar 2014 14:51:32 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Steve Donovan , "Shishufeng (Susan)" , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPQsn+hW8mxnR4ZUW/UfMU7zBoKJrnBT+AgAADsgCABVBJgIADO3GAgACNVQCAACghAg==
Date: Mon, 24 Mar 2014 13:51:31 +0000
Message-ID: 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>, <53302446.9080700@usdonovans.com>
In-Reply-To: <53302446.9080700@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.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202672882FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/P1ZKgM9tss-ovULYH2RIPDNyyNs
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 13:52:05 -0000

--_000_E194C2E18676714DACA9C3A2516265D202672882FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all

I am also in line with the agreement tendency as that OC-Report-Type is not=
 required (so to keep the text as it is in the draft); I expressed this  pr=
eference a while ago.


Best regards

JJacques



________________________________
De : DiME [dime-bounces@ietf.org] de la part de Steve Donovan [srdonovan@us=
donovans.com]
Date d'envoi : lundi 24 mars 2014 13:25
=C0 : Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve

On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,

I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.

Best Regards,
Susan


-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]
Sent: Saturday, March 22, 2014 10:38 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


Lets have it explicit then. Use '<' and '>' to make the position fixed.

- Jouni

On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.

Do we have other opinions?

Steve
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:


Hello,
I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.
This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.
If there is consensus on this, I will go with this.
Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 18 de marzo de 2014 17:47
To: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

All,

Do we have consensus that the OC-Report-Type AVP is required?

If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.

Jouni,

How do we indicate a fixed position for an AVP?

I presonally don't see this as critical but we can add this requirement if =
there is consensus.

Regards,

Steve

On 2/28/14 10:27 AM, Jouni Korhonen wrote:

Hi,

How having the AVP could be less error prone if it has a default
value and the receiver knows exactly how to proceed when the AVP is
not present?

If a node does not include it when it should, the implementation is
broken. Wouldn't a broken node be able to put wrong report type into
the AVP even if the AVP is mandatory?

Anyway, if it is my statement keeping issue #54 still open, consider
it resolved from my side. I am OK making the OC-Report-Type AVP as
required/mandatory AVP. Should we also consider it having a fixed
position just after the OC-Sequence-Number AVP as well since it is
going to in every OC-OLR?

- Jouni



On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:


Hello all,

I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.

I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: viernes, 14 de febrero de 2014 23:13
To: Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.

On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:


Agree that it is a small optimization, which I put there because at
the beginning there seemed to be a lot of worry on every extra AVP
;-)

I prefer having the AVP optional but with a default value just like
it is now. We have the same for the reduction percentage and the
validity time as well.

- Jouni

On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:

Hi Mcruz

The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.
We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.

Best regards

JJacques




-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de
lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]
[dime] #54: OC-Report-Type as mandatory AVP

Hi Maria Cruz,

I'm assuming that you mean "required" instead of "mandatory", right?

So instead of:

OC-OLR ::=3D < AVP Header: TBD2 >
           < OC-Sequence-Number >
           [ OC-Report-Type ]
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]

You would prefer:

OC-OLR ::=3D < AVP Header: TBD2 >
           < OC-Sequence-Number >
           { OC-Report-Type }
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]

And I'm fine with this proposal.

Cheers,

Lionel

-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue
tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :
maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]
[dime] #54: OC-Report-Type as mandatory AVP

#54: OC-Report-Type as mandatory AVP

Now in chapter 4.6:

 The default value of the OC-Report-Type AVP is 0 (i.e. the host
report).

This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.

--
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz
  Type:  defect                             |  Bartolom=E9
Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
Severity:  Active WG Document                 |    Version:  1.0
                                            |   Keywords:
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---

Ticket URL: 
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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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

_______________________________________________
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



--_000_E194C2E18676714DACA9C3A2516265D202672882FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable










Hi all

 


 <=
/o:p>


I am also in=
 line with the agreement tendency as that OC-Report-Type is not required (s=
o to keep the text as it is in the draft);
 I expressed this  preference a while ago.


<=
/span> 


 <=
/o:p>


Best regards=



 <=
/o:p>


JJacques



 




De : DiME [dime-bounces@ietf.org] de la pa=
rt de Steve Donovan [srdonovan@usdonovans.com]

Date d'envoi : lundi 24 mars 2014 13:25

=C0 : Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP








Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve





On 3/23/14 10:59 PM, Shishufeng (Susan) wrot=
e:






Hello Jouni,

I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.=20

Best Regards,
Susan


-----Original Message-----
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Sent: Saturday, March 22, 2014 10:38 AM
To: Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


Lets have it explicit then. Use '<' and '>' to make the position fixe=
d.

- Jouni

On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan=
@usdonovans.com> wrote:






I'm ok with either direction but generally lean toward being explicit.

Do we have other opinions? =20

Steve
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:





Hello,
I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.
This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.
If there is consensus on this, I will go with this.
Best regards
/MCruz
=20
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of =
Steve Donovan
Sent: martes, 18 de marzo de 2014 17:47
To: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
=20
All,

Do we have consensus that the OC-Report-Type AVP is required?

If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.

Jouni,

How do we indicate a fixed position for an AVP? =20

I presonally don't see this as critical but we can add this requirement if =
there is consensus.

Regards,

Steve

On 2/28/14 10:27 AM, Jouni Korhonen wrote:
=20
Hi,
=20
How having the AVP could be less error prone if it has a default=20
value and the receiver knows exactly how to proceed when the AVP is=20
not present?
=20
If a node does not include it when it should, the implementation is=20
broken. Wouldn't a broken node be able to put wrong report type into=20
the AVP even if the AVP is mandatory?
=20
Anyway, if it is my statement keeping issue #54 still open, consider=20
it resolved from my side. I am OK making the OC-Report-Type AVP as=20
required/mandatory AVP. Should we also consider it having a fixed=20
position just after the OC-Sequence-Number AVP as well since it is=20
going to in every OC-OLR?
=20
- Jouni
=20
=20
=20
On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:
=20
=20
Hello all,
=20
I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.
=20
I think DEFAULT values should never be error-prone, but used in "gener=
al cases", as a simplification, like e.g. a default for the Validity-D=
uration. Default Validity-Duration will never be an "error", it c=
ould be not the best value (compared with another value perfectly tuned to =
reporting node overload situation) but never the use of a Default value sho=
uld lead to an erroneous behavior.
=20
Best regards
/MCruz
=20
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of =
Ben Campbell
Sent: viernes, 14 de febrero de 2014 23:13
To: Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
=20
I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.
=20
On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nosp=
am@gmail.com> wrote:
=20
=20
Agree that it is a small optimization, which I put there because at=20
the beginning there seemed to be a lot of worry on every extra AVP=20
;-)
=20
I prefer having the AVP optional but with a default value just like=20
it is now. We have the same for the reduction percentage and the=20
validity time as well.
=20
- Jouni
=20
On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)&qu=
ot; <jean-jacques.trottin@alcatel-luce=
nt.com> wrote:
=20
Hi Mcruz
=20
The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.=20
We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.
=20
Best regards
=20
JJacques
=20
=20
=20
=20
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de=
=20
lionel.morand@orange.com Envoy=E9 : mercredi 12 f=
=E9vrier 2014 15:46 =C0 :
dime@ietf.org; maria.cruz.=
bartolome@ericsson.com Objet : Re: [Dime]=20
[dime] #54: OC-Report-Type as mandatory AVP
=20
Hi Maria Cruz,
=20
I'm assuming that you mean "required" instead of "mandatory&=
quot;, right?
=20
So instead of:
=20
OC-OLR ::=3D < AVP Header: TBD2 >
           < OC-Sequence-Number >
           [ OC-Report-Type ]
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]
=20
You would prefer:
=20
OC-OLR ::=3D < AVP Header: TBD2 >
           < OC-Sequence-Number >
           { OC-Report-Type }
           [ OC-Reduction-Percentage ]
           [ OC-Validity-Duration ]
         * [ AVP ]
=20
And I'm fine with this proposal.
=20
Cheers,
=20
Lionel
=20
-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de =
dime issue=20
tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :
maria.cruz.bartolome@ericsson.com Cc : <=
a class=3D"moz-txt-link-abbreviated" href=3D"mailto:dime@ietf.org" target=
=3D"_blank">dime@ietf.org Objet : [Dime]=20
[dime] #54: OC-Report-Type as mandatory AVP
=20
#54: OC-Report-Type as mandatory AVP
=20
Now in chapter 4.6:
=20
 The default value of the OC-Report-Type AVP is 0 (i.e. the host =20
report).
=20
This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.
=20
--
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
Reporter:  maria.cruz.bartolome@ericsson.com=
  |      Owner:  MCruz
  Type:  defect                             |  Bartolom=E9
Priority:  major                              |     Status:  new
Component:  draft-docdt-dime-ovli              |  Milestone:
Severity:  Active WG Document                 |    Version:  1.0
                                            |   Keywords:
-----------------------------------------------+---------------------
-----------------------------------------------+---
-----------------------------------------------+---
=20
Ticket URL: <http://trac.tools.ietf=
.org/wg/dime/trac/ticket/54>
dime <http://tools.ietf.org/wg/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 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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
=20
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.
=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
=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
=20
=20





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



















--_000_E194C2E18676714DACA9C3A2516265D202672882FR712WXCHMBA12z_--


From nobody Mon Mar 24 06:56:46 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 DABED1A0218 for ; Mon, 24 Mar 2014 06:56:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 FYwxNHIGyCes for ; Mon, 24 Mar 2014 06:56:41 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 40F371A0211 for ; Mon, 24 Mar 2014 06:56:41 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55041 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS5Mg-0002vY-3n for dime@ietf.org; Mon, 24 Mar 2014 06:56:38 -0700
Message-ID: <53303991.6060307@usdonovans.com>
Date: Mon, 24 Mar 2014 08:56:33 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com>
In-Reply-To: <532CA99F.4070409@usdonovans.com>
Content-Type: multipart/alternative; boundary="------------040504030907000805060801"
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/ojlIrSJUFVvYnoY823jx4HozOE8
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 24 Mar 2014 13:56:44 -0000

This is a multi-part message in MIME format.
--------------040504030907000805060801
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was
the proposal that came out of the meeting in London.  RRR reports can be
added back in if and when we are convinced of the need. 

If there are strong objections to this then I will update the -02 draft
to reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the
interaction between the report types when a reacting node has multiple
report types, all of which apply to individual requests.  This will need
to be addressed in the -03 draft.

Regards,

Steve

On 3/21/14 4:05 PM, Steve Donovan wrote:
> Ulrich,
>
> The discussion should be captured in the minutes to the meeting.  I
> wasn't able to find them posted yet.
>
> Jouni, Lionel, what is the status of the minutes for the meeting?
>
> My reading of emails prior to the London meeting is different from
> yours.  I believe we had come to the conclusion that we needed host
> and realm (with the definition of realm as outlined below).  We were
> still discussing the need for Realm-Routed-Request reports.
>
> Regards,
>
> Steve
>
> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>
>> Steve,
>>
>>  
>>
>> I don't know what happend in London.
>>
>> Can you please summarize the technical reasons that led to the London
>> agreement.
>>
>> E-mail discussions prior to London have clearly directed towards a
>> report type that requests throttling of realm routed request messages
>> (i.e. not containing a destination host) rather than a report type
>> that requests throttling of messages routed towards a realm (no
>> matter whether they contain a destination host or not).   
>>
>>  
>>
>> Ulrich
>>
>>  
>>
>> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
>> Donovan
>> *Sent:* Friday, March 21, 2014 3:33 PM
>> *To:* dime@ietf.org
>> *Subject:* [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>  
>>
>> All,
>>
>> Ben and I took the action item to discuss the need for the
>> Realm-Routed-Reports (RRR) report type.
>>
>> As you may recall, the consensus coming out of the DIME WG meeting in
>> London was to support two report types:
>>
>> - Host -- Impacting requests with a Destination-Host AVP matching the
>> host in the overload report (with the host implicitly determined from
>> the Origin-Host AVP of the answer message carrying the overload report).
>>
>> - Realm -- Impacting 100% of the requests with a Destination-Realm
>> AVP matching the realm in the overload report (with the realm
>> implicitly determine from the Origin-Realm of the answer message
>> carrying the overload report).
>>
>> The action Ben and I took was to come back with an opinion on whether
>> RRR reports should also be supported.
>>
>> My summary of the discussion is that we recommend to NOT include RRR
>> reports in the current version of the base DOIC draft. 
>>
>> We still have some concerns with the granularity of control enabled
>> by having just the two report types but the analysis of whether RRR
>> reports are still needed can occur independent of the base DOIC
>> draft.  If there is a determination that RRRs are needed in time to
>> include in the base draft then it can be considered at that time.
>>
>> Based on this, I propose the following
>>
>> - Resolution to issue #23 is to remove RRR reports from the document.
>> - Resolution to issue #55 is to add Realm reports (actually to
>> redefine them per the above definition).
>> - Resolution to issue #57 is that it no longer applies (as it deals
>> with RRRs).
>>
>> There is also need for text describing the interaction between host
>> and the realm reports.  I don't expect we will have consensus on this
>> wording prior to the -02 draft being submitted.  To this end, I'll
>> open a new issue to deal with the need for wording on the interaction.
>>
>> Regards,
>>
>> Steve
>>
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------040504030907000805060801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      All,

      

      We have two options for the -02 draft.

      

      1) Support Host and Realm as proposed below, removing RRR reports.

      2) Support Host, Realm and RRR reports.

      

      The default plan is to go with option 1 in the -02 draft, as that
      was the proposal that came out of the meeting in London.  RRR
      reports can be added back in if and when we are convinced of the
      need.  

      

      If there are strong objections to this then I will update the -02
      draft to reflect all three report types.

      

      I plan to make these updates Wednesday morning, Dallas, Texas
      time.

      

      Either way I do not expect we will have agreed to wording on the
      interaction between the report types when a reacting node has
      multiple report types, all of which apply to individual requests. 
      This will need to be addressed in the -03 draft.

      

      Regards,

      

      Steve

      

    
    
On 3/21/14 4:05 PM, Steve Donovan
      wrote:

    

    

      
      Ulrich,

        

        The discussion should be captured in the minutes to the
        meeting.  I wasn't able to find them posted yet.

        

        Jouni, Lionel, what is the status of the minutes for the
        meeting?

        

        My reading of emails prior to the London meeting is different
        from yours.  I believe we had come to the conclusion that we
        needed host and realm (with the definition of realm as outlined
        below).  We were still discussing the need for
        Realm-Routed-Request reports.

        

        Regards,

        

        Steve

        

      
      
On 3/21/14 10:09 AM, Wiehe, Ulrich
        (NSN - DE/Munich) wrote:

      

      

        
        
        
        

          
Steve,

          
 

          
I don’t know what happend in London.

          
Can you please summarize the technical
              reasons that led to the London agreement. 

          
E-mail discussions prior to London have
              clearly directed towards a report type that requests
              throttling of realm routed request messages (i.e. not
              containing a destination host) rather than a report type
              that requests throttling of messages routed towards a
              realm (no matter whether they contain a destination host
              or not).   

          
 

          
Ulrich

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Friday, March 21, 2014 3:33 PM

                  To: dime@ietf.org

                  Subject: [Dime] Resolution on action to discuss
                  the need for Realm-Routed-Reports

            

          

          
 

          
All,

            

            Ben and I took the action item to discuss the need for the
            Realm-Routed-Reports (RRR) report type.

            

            As you may recall, the consensus coming out of the DIME WG
            meeting in London was to support two report types:

            

            - Host -- Impacting requests with a Destination-Host AVP
            matching the host in the overload report (with the host
            implicitly determined from the Origin-Host AVP of the answer
            message carrying the overload report).

            

            - Realm -- Impacting 100% of the requests with a
            Destination-Realm AVP matching the realm in the overload
            report (with the realm implicitly determine from the
            Origin-Realm of the answer message carrying the overload
            report).

            

            The action Ben and I took was to come back with an opinion
            on whether RRR reports should also be supported.

            

            My summary of the discussion is that we recommend to NOT
            include RRR reports in the current version of the base DOIC
            draft.  

            

            We still have some concerns with the granularity of control
            enabled by having just the two report types but the analysis
            of whether RRR reports are still needed can occur
            independent of the base DOIC draft.  If there is a
            determination that RRRs are needed in time to include in the
            base draft then it can be considered at that time.

            

            Based on this, I propose the following 

            

            - Resolution to issue #23 is to remove RRR reports from the
            document.

            - Resolution to issue #55 is to add Realm reports (actually
            to redefine them per the above definition).

            - Resolution to issue #57 is that it no longer applies (as
            it deals with RRRs).

            

            There is also need for text describing the interaction
            between host and the realm reports.  I don't expect we will
            have consensus on this wording prior to the -02 draft being
            submitted.  To this end, I'll open a new issue to deal with
            the need for wording on the interaction.

            

            Regards,

            

            Steve 

        

      

      

      

      

      

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


    

    

  


--------------040504030907000805060801--


From nobody Mon Mar 24 07:12:09 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 C8AFA1A0229; Mon, 24 Mar 2014 07:12:05 -0700 (PDT)
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 I0weMmxk4hHS; Mon, 24 Mar 2014 07:12:01 -0700 (PDT)
Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id 109971A023B; Mon, 24 Mar 2014 07:12:00 -0700 (PDT)
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-16.tower-171.messagelabs.com!1395670317!14297914!1
X-Originating-IP: [20.137.2.88]
X-StarScan-Received: 
X-StarScan-Version: 6.11.1; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 6258 invoked from network); 24 Mar 2014 14:11:58 -0000
Received: from amer-mta102.csc.com (HELO amer-mta112.csc.com) (20.137.2.88) by server-16.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP;  24 Mar 2014 14:11:58 -0000
Received: from amer-gw15.amer.csc.com (amer-gw15.amer.csc.com [20.137.2.189]) by amer-mta112.csc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id s2OEBss3009344; Mon, 24 Mar 2014 10:11:56 -0400
In-Reply-To: <5330362E.10005@usdonovans.com>
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <081.d67cf98bf010626435cad725cb5095f0@trac.tools.ietf.org>  <5330362E.10005@usdonovans.com>
To: Steve Donovan 
MIME-Version: 1.0
X-KeepSent: F95964B0:24E9214B-85257CA5:004DF770; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012
From: Janet P Gunn 
Message-ID: 
Date: Mon, 24 Mar 2014 10:11:55 -0400
X-MIMETrack: Serialize by Router on AMER-GW15/SRV/CSC(Release 8.5.2FP3 HF666|December 11, 2012) at 03/24/2014 10:11:57 AM, Serialize complete at 03/24/2014 10:11:57 AM
Content-Type: multipart/alternative; boundary="=_alternative 004DFF8485257CA5_="
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lYcCAOn02g89vnJnvAo70iCOgHo
Cc: DiME , dime@ietf.org
Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages
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, 24 Mar 2014 14:12:06 -0000

This is a multipart message in MIME format.
--=_alternative 004DFF8485257CA5_=
Content-Type: text/plain; charset="US-ASCII"

Fine with me

Janet

"DiME"  wrote on 03/24/2014 09:42:06 AM:

> From: Steve Donovan 
> To: dime@ietf.org
> Date: 03/24/2014 09:42 AM
> Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages
> Sent by: "DiME" 
> 
> Janet,
> 
> Well, in the sense that the current overload condition caused the 
> current abatement request, the wording is mostly correct.  I agree 
> it can be made more clear.  It might be better if we changed the 
> word condition to report.
> 
> Steve

> On 3/21/14 4:10 PM, Janet P Gunn wrote:
> Just a question. 
> 
> In the phrase " it
>    applies the traffic abatement based on the commonly 
supported/selected
>    algorithm with the reporting node and the current overload 
condition." 
> 
> Is it really the "current overload CONDITION", or the "current 
> abatement REQUESTED"? 
> 
> If the message is asking for a 10% reduction in traffic, that does 
> not actually identify the "current overload condition". 
> 
> 
> Janet 
> 
> 
> 
> 
> From:        "dime issue tracker"  
> To:        srdonovan@usdonovans.com 
> Cc:        dime@ietf.org 
> Date:        03/21/2014 09:33 AM 
> Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages 
> Sent by:        "DiME"  
> 
> 
> 
> #30: OC-Supported-Features AVP in answer messages
> 
> Changes (by srdonovan@usdonovans.com):
> 
> * status:  new => closed
> * resolution:   => fixed
> 
> 
> Comment:
> 
> We reached the tentative agreement in the DIME meeting on the following:
> 
> OC-Supported-Features handling:
> 
> Agreed: OC-Supported-Features AVP MUST be included in all answer 
messages
> (we had already agreed that it must be included in all request 
messages).
> Agreed: Reacting node advertises all supported algorithms;
> Agreed: Reporting node responds with the single algorithm it will be
> using;
> Agreed: Handling of other feature bits is defined in the extension 
drafts
> 
> Based on this I believe we need the text changes outlined below.
> 
> Let me know if I have missed any.
> 
> If we agree on the text changes then we can close the issue and I'll
> update the document accordingly.
> 
> Regards,
> 
> Steve
> 
> -----
> 
> Section 5.3.2, paragraph 1:
> 
> Change:
> 
> The answer message
>    initiating endpoint MAY announce as many supported capabilities as it
>    has (the announced set is a subject to local policy and
>    configuration). However, at least one of the announced capabilities
>    MUST be the same as received in the request message.
> 
> 
> To:
> 
> The reporting node MUST include the OC-Supported-Features AVP in all
> response messages for transactions where the request message included 
the
> OC-Supported-Features AVP.  The reporting node MUST announce support of
> the single algorithm that the reporting node will request the reacting
> node to use to mitigate overload instances.  The reporting node MUST NOT
> change the selected algorithm during a period of time that it is in an
> overload state and, as a result, is sending OC-OLR AVPs in answer
> messages.
> 
>     Note: There will always be at least one algorithm supported by both
> the reacting and reporting nodes as all nodes that support DOIC must
> support the loss algorithm defined in this document.
> 
> The handling of feature bits in the OC-Feature-Vector AVP that are not
> associated with overload abatement algorithms MUST be specified by the
> extension that defines the feature.
> 
> Paragraph 2:
> 
> Change:
> 
> The answer message initiating endpoint MUST NOT include any overload
>    control solution defined AVPs into its answer messages if the request
>    message initiating endpoint has not indicated support at the
>    beginning of the created session (or transaction in a case of non-
>    session state maintaining applications). The same also applies if
>    none of the announced capabilities match between the two endpoints.
> 
> To:
> 
> The reporting node MUST NOT include the OC-Supported-Features AVP, 
OC-OLR
> AVP or any other overload control AVPs defined in extension drafts in
> response messages for transaction where the request message does not
> include the OC-Supported-Features AVP.  Lack of the 
OC-Supported-Features
> AVP in the request message indicates that the sender of the request
> message does not support DOIC.
> 
> Section 5.5.2, Paragraph 1:
> 
> Change:
> 
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP or indirectly remembering the previously
>    used traffic abatement algorithm with the given reporting node.
> 
> To: (removing the last portion of the last sentence)
> 
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP.
> 
> -----
> 
> +1, with a minor suggested edit:
> 
> On Mar 17, 2014, at 2:03 PM, Steve Donovan 
> wrote:
> 
> > Change:
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, 
it
> >    applies the traffic abatement based on the commonly supported
> >    algorithm with the reporting node and the current overload 
condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP or indirectly remembering the previously
> >    used traffic abatement algorithm with the given reporting node.
> 
> > To: (removing the last portion of the last sentence)
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, 
it
> >    applies the traffic abatement based on the commonly supported
> 
> s/"commonly supported"/selected
> 
> "Commonly supported" is no longer descriptive. There may be several
> commonly supported algorithm, but the reporting node selects just one.
> 
> >    algorithm with the reporting node and the current overload 
condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP.
> >
> 
> -- 
> --------------------------------------+---------------------------
> Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
>     Type:  defect                    |      Status:  closed
> Priority:  major                     |   Milestone:
> Component:  draft-docdt-dime-ovli     |     Version:
> Severity:  Active WG Document        |  Resolution:  fixed
> Keywords:                            |
> --------------------------------------+---------------------------
> 
> Ticket URL: 
> 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

--=_alternative 004DFF8485257CA5_=
Content-Type: text/html; charset="US-ASCII"

Fine with me



Janet



"DiME" <dime-bounces@ietf.org> wrote
on 03/24/2014 09:42:06 AM:



> From: Steve Donovan <srdonovan@usdonovans.com>

> To: dime@ietf.org

> Date: 03/24/2014 09:42 AM

> Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli):
OC-

> Supported-Features AVP in answer messages

> Sent by: "DiME" <dime-bounces@ietf.org>

> 

> Janet,

> 

> Well, in the sense that the current overload condition caused the


> current abatement request, the wording is mostly correct.  I
agree 

> it can be made more clear.  It might be better if we changed
the 

> word condition to report.

> 

> Steve



> On 3/21/14 4:10 PM, Janet P Gunn wrote:

> Just a question. 

> 

> In the phrase " it

>    applies the traffic abatement based on the commonly supported/selected

>    algorithm with the reporting node and the current overload
condition." 

> 

> Is it really the "current overload CONDITION", or the "current


> abatement REQUESTED"? 

> 

> If the message is asking for a 10% reduction in traffic, that does


> not actually identify the "current overload condition".


> 

> 

> Janet 

> 

> 

> 

> 

> From:        "dime issue tracker" <trac+dime@grenache.tools.ietf.org>


> To:        srdonovan@usdonovans.com 

> Cc:        dime@ietf.org 

> Date:        03/21/2014 09:33 AM 

> Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli):
OC-

> Supported-Features AVP in answer messages 

> Sent by:        "DiME" <dime-bounces@ietf.org>


> 

> 

> 

> #30: OC-Supported-Features AVP in answer messages

> 

> Changes (by srdonovan@usdonovans.com):

> 

> * status:  new => closed

> * resolution:   => fixed

> 

> 

> Comment:

> 

> We reached the tentative agreement in the DIME meeting on the following:

> 

> OC-Supported-Features handling:

> 

> Agreed: OC-Supported-Features AVP MUST be included in all answer messages

> (we had already agreed that it must be included in all request messages).

> Agreed: Reacting node advertises all supported algorithms;

> Agreed: Reporting node responds with the single algorithm it will
be

> using;

> Agreed: Handling of other feature bits is defined in the extension
drafts

> 

> Based on this I believe we need the text changes outlined below.

> 

> Let me know if I have missed any.

> 

> If we agree on the text changes then we can close the issue and I'll

> update the document accordingly.

> 

> Regards,

> 

> Steve

> 

> -----

> 

> Section 5.3.2, paragraph 1:

> 

> Change:

> 

> The answer message

>    initiating endpoint MAY announce as many supported capabilities
as it

>    has (the announced set is a subject to local policy and

>    configuration). However, at least one of the announced
capabilities

>    MUST be the same as received in the request message.

> 

> 

> To:

> 

> The reporting node MUST include the OC-Supported-Features AVP in all

> response messages for transactions where the request message included
the

> OC-Supported-Features AVP.  The reporting node MUST announce
support of

> the single algorithm that the reporting node will request the reacting

> node to use to mitigate overload instances.  The reporting node
MUST NOT

> change the selected algorithm during a period of time that it is in
an

> overload state and, as a result, is sending OC-OLR AVPs in answer

> messages.

> 

>     Note: There will always be at least one algorithm supported
by both

> the reacting and reporting nodes as all nodes that support DOIC must

> support the loss algorithm defined in this document.

> 

> The handling of feature bits in the OC-Feature-Vector AVP that are
not

> associated with overload abatement algorithms MUST be specified by
the

> extension that defines the feature.

> 

> Paragraph 2:

> 

> Change:

> 

> The answer message initiating endpoint MUST NOT include any overload

>    control solution defined AVPs into its answer messages
if the request

>    message initiating endpoint has not indicated support
at the

>    beginning of the created session (or transaction in a
case of non-

>    session state maintaining applications). The same also
applies if

>    none of the announced capabilities match between the
two endpoints.

> 

> To:

> 

> The reporting node MUST NOT include the OC-Supported-Features AVP,
OC-OLR

> AVP or any other overload control AVPs defined in extension drafts
in

> response messages for transaction where the request message does not

> include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features

> AVP in the request message indicates that the sender of the request

> message does not support DOIC.

> 

> Section 5.5.2, Paragraph 1:

> 

> Change:

> 

>    Once a reacting node receives an OC-OLR AVP from a reporting
node, it

>    applies the traffic abatement based on the commonly supported

>    algorithm with the reporting node and the current overload
condition.

>    The reacting node learns the reporting node supported
abatement

>    algorithms directly from the received answer message
containing the

>    OC-Supported-Features AVP or indirectly remembering the
previously

>    used traffic abatement algorithm with the given reporting
node.

> 

> To: (removing the last portion of the last sentence)

> 

>    Once a reacting node receives an OC-OLR AVP from a reporting
node, it

>    applies the traffic abatement based on the commonly supported

>    algorithm with the reporting node and the current overload
condition.

>    The reacting node learns the reporting node supported
abatement

>    algorithms directly from the received answer message
containing the

>    OC-Supported-Features AVP.

> 

> -----

> 

> +1, with a minor suggested edit:

> 

> On Mar 17, 2014, at 2:03 PM, Steve Donovan <srdonovan@usdonovans.com>

> wrote:

> 

> > Change:

> >    Once a reacting node receives an OC-OLR AVP from
a reporting node, it

> >    applies the traffic abatement based on the commonly
supported

> >    algorithm with the reporting node and the current
overload condition.

> >    The reacting node learns the reporting node supported
abatement

> >    algorithms directly from the received answer message
containing the

> >    OC-Supported-Features AVP or indirectly remembering
the previously

> >    used traffic abatement algorithm with the given
reporting node.

> 

> > To: (removing the last portion of the last sentence)

> >    Once a reacting node receives an OC-OLR AVP from
a reporting node, it

> >    applies the traffic abatement based on the commonly
supported

> 

> s/"commonly supported"/selected

> 

> "Commonly supported" is no longer descriptive. There may
be several

> commonly supported algorithm, but the reporting node selects just
one.

> 

> >    algorithm with the reporting node and the current
overload condition.

> >    The reacting node learns the reporting node supported
abatement

> >    algorithms directly from the received answer message
containing the

> >    OC-Supported-Features AVP.

> >

> 

> -- 

> --------------------------------------+---------------------------

> Reporter:  lionel.morand@orange.com  |      
Owner:  Ulrich Wiehe

>     Type:  defect          
         |      Status:  closed

> Priority:  major              
      |   Milestone:

> Component:  draft-docdt-dime-ovli     |    
Version:

> Severity:  Active WG Document        |  Resolution:
 fixed

> Keywords:                
           |

> --------------------------------------+---------------------------

> 

> Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/30#comment:1>

> dime <http://tools.ietf.org/wg/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


--=_alternative 004DFF8485257CA5_=--


From nobody Mon Mar 24 07:25:55 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 C2AA41A0221 for ; Mon, 24 Mar 2014 07:25:53 -0700 (PDT)
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 fEWtJ1Q3FnW1 for ; Mon, 24 Mar 2014 07:25:46 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACDA1A0202 for ; Mon, 24 Mar 2014 07:25:45 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2OEPggk011624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Mar 2014 09:25:44 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2OEPeg1018055 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 15:25:42 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 24 Mar 2014 15:25:40 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRRfXQhWaUi5Qi0CrluviFm2KiJrr96eAgAQ/IICAABQAoA==
Date: Mon, 24 Mar 2014 14:25:40 +0000
Message-ID: 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com>
In-Reply-To: <53303991.6060307@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_E194C2E18676714DACA9C3A2516265D2026728B5FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/mN0PS7SD2e6ga6Zx0if6cEctUmA
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 24 Mar 2014 14:25:54 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026728B5FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi all

This topic is not an easy one, and for me we have  not taken  conclusion in=
 London


-          One question is how to deal with requests for which we do not kn=
ow the destination host but only the realm, which is an important point (so=
 with the  RRR OLRs)

-          Another question is what is a realm overload . On this one, not =
yet straight forward for me; we can consider a realm overload when a lot of=
 servers overloaded (but this overload is handled by host OLRs, so there wo=
uld be overlap with a realm OLR ),  and DA overload (which is to be studied=
, and   probably not  using a realm OLR) ). What are the other sources of o=
verload  at realm level for which I have not had clear explanations or use =
cases on this ?

-          As Dave mentioned , what happens when for the same request, we c=
an apply the host OLR and the realm OLR, we ahev to be careful there. Wuth =
the so called RRR OLRs are not overlapping with the Hosts OLR.

-          The objective we retained in London is to try to avoid two types=
 of realm OLRs.

So here we are, and I would not like to too quckly drop the RRR OLRS  which=
   we recognize useful as we  introduced  them in the version 01 of the dra=
ft.

Best regards

JJacques

.



De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 mars 2014 14:57
=C0 : dime@ietf.org
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve





_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_E194C2E18676714DACA9C3A2516265D2026728B5FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi all<=
/p>

 <=
/p>

This topic is not an easy=
 one, and for me we have  not taken  conclusion in London


 <=
/p>

- =
;        
One question is h=
ow to deal with requests for which we do not know the destination host but =
only the realm, which is an important point (so with the
  RRR OLRs) 


- =
;        
Another question =
is what is a realm overload . On this one, not yet straight forward for me;=
 we can consider a realm overload when a lot of servers
 overloaded (but this overload is handled by host OLRs, so there would be o=
verlap with a realm OLR ),  and DA overload (which is to be studied, a=
nd   probably not  using a realm OLR) ). What are the other =
sources of overload  at realm level for which I have
 not had clear explanations or use cases on this ? 


- =
;        
As Dave mentioned=
 , what happens when for the same request, we can apply the host OLR and th=
e realm OLR, we ahev to be careful there. Wuth the so
 called RRR OLRs are not overlapping with the Hosts OLR.<=
/p>

- =
;        
The objective we =
retained in London is to try to avoid two types of realm OLRs.


 <=
/p>

So here we are, and I wou=
ld not like to too quckly drop the RRR OLRS  which   we reco=
gnize useful as we  introduced  them in the version 01 of the dra=
ft.




 <=
/p>

Best regards


 <=
/p>

JJacques   


    &=
nbsp;           &nbs=
p;            &=
nbsp;           &nbs=
p; 



.


 <=
/p>

 <=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 mars 2014 14:57

=C0 : dime@ietf=
.org

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


Ulrich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan wrote:<=
/p>





Ulrich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I don’t know what h=
append in London.


Can you please summarize =
the technical reasons that led to the London agreement.



E-mail discussions prior =
to London have clearly directed towards a report type that requests throttl=
ing of realm routed request messages (i.e. not containing
 a destination host) rather than a report type that requests throttling of =
messages routed towards a realm (no matter whether they contain a destinati=
on host or not).   


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_E194C2E18676714DACA9C3A2516265D2026728B5FR712WXCHMBA12z_--


From nobody Mon Mar 24 07:37:14 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 C39281A0227 for ; Mon, 24 Mar 2014 07:37:00 -0700 (PDT)
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 vwTMY78LMfLy for ; Mon, 24 Mar 2014 07:36:55 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id AFDF01A01D5 for ; Mon, 24 Mar 2014 07:36:55 -0700 (PDT)
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 s2OEaqOX001506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Mar 2014 09:36:53 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2OEapSY024810 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 15:36:52 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 24 Mar 2014 15:36:51 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages
Thread-Index: AQHPRQoiWUmF1XwIIEWeujWCv6Z67prr+Q8AgAQ5ygCAAAhUgIAAFtSw
Date: Mon, 24 Mar 2014 14:36:51 +0000
Message-ID: 
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <081.d67cf98bf010626435cad725cb5095f0@trac.tools.ietf.org>  <5330362E.10005@usdonovans.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: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D2026728D7FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/tO5uX9XWcXpndys9qCtEiltwDEc
Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages
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, 24 Mar 2014 14:37:01 -0000

--_000_E194C2E18676714DACA9C3A2516265D2026728D7FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve

I am ok with the changes you proposed including  your modification  coming =
from  the Janet's remark.

Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Janet P Gunn
Envoy=E9 : lundi 24 mars 2014 15:12
=C0 : Steve Donovan
Cc : DiME; dime@ietf.org
Objet : Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Feature=
s AVP in answer messages

Fine with me

Janet

"DiME" > wrote on 03/24=
/2014 09:42:06 AM:

> From: Steve Donovan >
> To: dime@ietf.org
> Date: 03/24/2014 09:42 AM
> Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages
> Sent by: "DiME" >
>
> Janet,
>
> Well, in the sense that the current overload condition caused the
> current abatement request, the wording is mostly correct.  I agree
> it can be made more clear.  It might be better if we changed the
> word condition to report.
>
> Steve

> On 3/21/14 4:10 PM, Janet P Gunn wrote:
> Just a question.
>
> In the phrase " it
>    applies the traffic abatement based on the commonly supported/selected
>    algorithm with the reporting node and the current overload condition."
>
> Is it really the "current overload CONDITION", or the "current
> abatement REQUESTED"?
>
> If the message is asking for a 10% reduction in traffic, that does
> not actually identify the "current overload condition".
>
>
> Janet
>
>
>
>
> From:        "dime issue tracker" >
> To:        srdonovan@usdonovans.com
> Cc:        dime@ietf.org
> Date:        03/21/2014 09:33 AM
> Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> Supported-Features AVP in answer messages
> Sent by:        "DiME" >
>
>
>
> #30: OC-Supported-Features AVP in answer messages
>
> Changes (by srdonovan@usdonovans.com):
>
> * status:  new =3D> closed
> * resolution:   =3D> fixed
>
>
> Comment:
>
> We reached the tentative agreement in the DIME meeting on the following:
>
> OC-Supported-Features handling:
>
> Agreed: OC-Supported-Features AVP MUST be included in all answer messages
> (we had already agreed that it must be included in all request messages).
> Agreed: Reacting node advertises all supported algorithms;
> Agreed: Reporting node responds with the single algorithm it will be
> using;
> Agreed: Handling of other feature bits is defined in the extension drafts
>
> Based on this I believe we need the text changes outlined below.
>
> Let me know if I have missed any.
>
> If we agree on the text changes then we can close the issue and I'll
> update the document accordingly.
>
> Regards,
>
> Steve
>
> -----
>
> Section 5.3.2, paragraph 1:
>
> Change:
>
> The answer message
>    initiating endpoint MAY announce as many supported capabilities as it
>    has (the announced set is a subject to local policy and
>    configuration). However, at least one of the announced capabilities
>    MUST be the same as received in the request message.
>
>
> To:
>
> The reporting node MUST include the OC-Supported-Features AVP in all
> response messages for transactions where the request message included the
> OC-Supported-Features AVP.  The reporting node MUST announce support of
> the single algorithm that the reporting node will request the reacting
> node to use to mitigate overload instances.  The reporting node MUST NOT
> change the selected algorithm during a period of time that it is in an
> overload state and, as a result, is sending OC-OLR AVPs in answer
> messages.
>
>     Note: There will always be at least one algorithm supported by both
> the reacting and reporting nodes as all nodes that support DOIC must
> support the loss algorithm defined in this document.
>
> The handling of feature bits in the OC-Feature-Vector AVP that are not
> associated with overload abatement algorithms MUST be specified by the
> extension that defines the feature.
>
> Paragraph 2:
>
> Change:
>
> The answer message initiating endpoint MUST NOT include any overload
>    control solution defined AVPs into its answer messages if the request
>    message initiating endpoint has not indicated support at the
>    beginning of the created session (or transaction in a case of non-
>    session state maintaining applications). The same also applies if
>    none of the announced capabilities match between the two endpoints.
>
> To:
>
> The reporting node MUST NOT include the OC-Supported-Features AVP, OC-OLR
> AVP or any other overload control AVPs defined in extension drafts in
> response messages for transaction where the request message does not
> include the OC-Supported-Features AVP.  Lack of the OC-Supported-Features
> AVP in the request message indicates that the sender of the request
> message does not support DOIC.
>
> Section 5.5.2, Paragraph 1:
>
> Change:
>
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP or indirectly remembering the previously
>    used traffic abatement algorithm with the given reporting node.
>
> To: (removing the last portion of the last sentence)
>
>    Once a reacting node receives an OC-OLR AVP from a reporting node, it
>    applies the traffic abatement based on the commonly supported
>    algorithm with the reporting node and the current overload condition.
>    The reacting node learns the reporting node supported abatement
>    algorithms directly from the received answer message containing the
>    OC-Supported-Features AVP.
>
> -----
>
> +1, with a minor suggested edit:
>
> On Mar 17, 2014, at 2:03 PM, Steve Donovan >
> wrote:
>
> > Change:
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, i=
t
> >    applies the traffic abatement based on the commonly supported
> >    algorithm with the reporting node and the current overload condition=
.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP or indirectly remembering the previously
> >    used traffic abatement algorithm with the given reporting node.
>
> > To: (removing the last portion of the last sentence)
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, i=
t
> >    applies the traffic abatement based on the commonly supported
>
> s/"commonly supported"/selected
>
> "Commonly supported" is no longer descriptive. There may be several
> commonly supported algorithm, but the reporting node selects just one.
>
> >    algorithm with the reporting node and the current overload condition=
.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP.
> >
>
> --
> --------------------------------------+---------------------------
> Reporter:  lionel.morand@orange.com  |  =
     Owner:  Ulrich Wiehe
>     Type:  defect                    |      Status:  closed
> Priority:  major                     |   Milestone:
> Component:  draft-docdt-dime-ovli     |     Version:
> Severity:  Active WG Document        |  Resolution:  fixed
> Keywords:                            |
> --------------------------------------+---------------------------
>
> Ticket URL: 
> 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

--_000_E194C2E18676714DACA9C3A2516265D2026728D7FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve


 <=
/p>

I am ok with the changes =
you proposed including  your modification  coming from  the =
Janet’s remark.


 <=
/p>

Best regards


 <=
/p>

JJacques  


 <=
/p>



De : DiME [mailto:dime-bounces@ietf.org]
De la part de Janet P Gunn

Envoy=E9 : lundi 24 mars 2014 15:12

=C0 : Steve Donovan

Cc : DiME; dime@ietf.org

Objet : Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Suppo=
rted-Features AVP in answer messages




 


Fine with me




Janet 



"DiME" <dime-bounces@ietf.org> wrote on 03/24/2014 0=
9:42:06 AM:



> From: Steve Donovan <srdonovan@usdonovans.com>


> To: dime@ietf.org


> Date: 03/24/2014 09:42 AM<=
/tt> 

> Subject: Re: [Dime] [dime] #30 (d=
raft-docdt-dime-ovli): OC-

> Supported-Features AVP in answer messages 

> Sent by: "DiME" <dime-bounces@ietf.org><=
/tt>


> 

> Janet,

> 

> Well, in the sense that the current overload condition caused the =


> current abatement request, the wording is mostly correct.  I =
agree 

> it can be made more clear.  It might be better if we changed =
the 

> word condition to report.

> 

> Steve



> On 3/21/14 4:10 PM, Janet P Gunn =
wrote:


> Just a question. 

> 

> In the phrase " it

>    applies the traffic abatement based on the commonly s=
upported/selected

>    algorithm with the reporting node and the current ove=
rload condition." 


> 

> Is it really the "current overload CONDITION", or the &q=
uot;current 

> abatement REQUESTED"? 

> 

> If the message is asking for a 10% reduction in traffic, that does=
 

> not actually identify the "current overload condition". =


> 

> 

> Janet 

> 

> 

> 

> 

> From:        "dime issue tracker" &l=
t;trac+dime@gr=
enache.tools.ietf.org>


> To:        srdonovan@usdonovans.com


> Cc:        di=
me@ietf.org 

> Date:        03/21/2014 09:33 AM 

> Subject:        Re: [Dime] [dime] #30 (draft-d=
ocdt-dime-ovli): OC-

> Supported-Features AVP in answer messages 

> Sent by:        "DiME" <dime-bounces@ietf.org>


> 

> 

> 

> #30: OC-Supported-Features AVP in answer messages

> 

> Changes (by srdonovan@=
usdonovans.com):

> 

> * status:  new =3D> closed

> * resolution:   =3D> fixed

> 

> 

> Comment:

> 

> We reached the tentative agreement in the DIME meeting on the foll=
owing:

> 

> OC-Supported-Features handling:

> 

> Agreed: OC-Supported-Features AVP MUST be included in all answer m=
essages

> (we had already agreed that it must be included in all request mes=
sages).

> Agreed: Reacting node advertises all supported algorithms;
> Agreed: Reporting node responds with the single algorithm it will =
be

> using;

> Agreed: Handling of other feature bits is defined in the extension=
 drafts

> 

> Based on this I believe we need the text changes outlined below.

> 

> Let me know if I have missed any.

> 

> If we agree on the text changes then we can close the issue and I'=
ll

> update the document accordingly.

> 

> Regards,

> 

> Steve

> 

> -----

> 

> Section 5.3.2, paragraph 1:

> 

> Change:

> 

> The answer message

>    initiating endpoint MAY announce as many supported ca=
pabilities as it

>    has (the announced set is a subject to local policy a=
nd

>    configuration). However, at least one of the announce=
d capabilities

>    MUST be the same as received in the request message.<=
/tt>

> 

> 

> To:

> 

> The reporting node MUST include the OC-Supported-Features AVP in a=
ll

> response messages for transactions where the request message inclu=
ded the

> OC-Supported-Features AVP.  The reporting node MUST announce =
support of

> the single algorithm that the reporting node will request the reac=
ting

> node to use to mitigate overload instances.  The reporting no=
de MUST NOT

> change the selected algorithm during a period of time that it is i=
n an

> overload state and, as a result, is sending OC-OLR AVPs in answer<=
/tt>

> messages.

> 

>     Note: There will always be at least one algorithm su=
pported by both

> the reacting and reporting nodes as all nodes that support DOIC mu=
st

> support the loss algorithm defined in this document.

> 

> The handling of feature bits in the OC-Feature-Vector AVP that are=
 not

> associated with overload abatement algorithms MUST be specified by=
 the

> extension that defines the feature.

> 

> Paragraph 2:

> 

> Change:

> 

> The answer message initiating endpoint MUST NOT include any overlo=
ad

>    control solution defined AVPs into its answer message=
s if the request

>    message initiating endpoint has not indicated support=
 at the

>    beginning of the created session (or transaction in a=
 case of non-

>    session state maintaining applications). The same als=
o applies if

>    none of the announced capabilities match between the =
two endpoints.

> 

> To:

> 

> The reporting node MUST NOT include the OC-Supported-Features AVP,=
 OC-OLR

> AVP or any other overload control AVPs defined in extension drafts=
 in

> response messages for transaction where the request message does n=
ot

> include the OC-Supported-Features AVP.  Lack of the OC-Suppor=
ted-Features

> AVP in the request message indicates that the sender of the reques=
t

> message does not support DOIC.

> 

> Section 5.5.2, Paragraph 1:

> 

> Change:

> 

>    Once a reacting node receives an OC-OLR AVP from a re=
porting node, it

>    applies the traffic abatement based on the commonly s=
upported

>    algorithm with the reporting node and the current ove=
rload condition.

>    The reacting node learns the reporting node supported=
 abatement

>    algorithms directly from the received answer message =
containing the

>    OC-Supported-Features AVP or indirectly remembering t=
he previously

>    used traffic abatement algorithm with the given repor=
ting node.

> 

> To: (removing the last portion of the last sentence)

> 

>    Once a reacting node receives an OC-OLR AVP from a re=
porting node, it

>    applies the traffic abatement based on the commonly s=
upported

>    algorithm with the reporting node and the current ove=
rload condition.

>    The reacting node learns the reporting node supported=
 abatement

>    algorithms directly from the received answer message =
containing the

>    OC-Supported-Features AVP.

> 

> -----

> 

> +1, with a minor suggested edit:

> 

> On Mar 17, 2014, at 2:03 PM, Steve Donovan <srdonovan@usdonovans.com>

> wrote:

> 

> > Change:

> >    Once a reacting node receives an OC-OLR AVP from=
 a reporting node, it

> >    applies the traffic abatement based on the commo=
nly supported

> >    algorithm with the reporting node and the curren=
t overload condition.

> >    The reacting node learns the reporting node supp=
orted abatement

> >    algorithms directly from the received answer mes=
sage containing the

> >    OC-Supported-Features AVP or indirectly remember=
ing the previously

> >    used traffic abatement algorithm with the given =
reporting node.

> 

> > To: (removing the last portion of the last sentence)

> >    Once a reacting node receives an OC-OLR AVP from=
 a reporting node, it

> >    applies the traffic abatement based on the commo=
nly supported

> 

> s/"commonly supported"/selected

> 

> "Commonly supported" is no longer descriptive. There may=
 be several

> commonly supported algorithm, but the reporting node selects just =
one.

> 

> >    algorithm with the reporting node and the curren=
t overload condition.

> >    The reacting node learns the reporting node supp=
orted abatement

> >    algorithms directly from the received answer mes=
sage containing the

> >    OC-Supported-Features AVP.

> >

> 

> -- 

> --------------------------------------+-----------------------=
----

> Reporter:  lionel=
.morand@orange.com  |       Owner:  Ulrich Wie=
he

>     Type:  defect          =
;          |      Status:  clo=
sed

> Priority:  major             &n=
bsp;       |   Milestone:

> Component:  draft-docdt-dime-ovli     |   &nbs=
p; Version:

> Severity:  Active WG Document        | &n=
bsp;Resolution:  fixed

> Keywords:                 =
           |

> --------------------------------------+-----------------------=
----

> 

> Ticket URL: <http://to=
ols.ietf.org/wg/dime/trac/ticket/30#comment:1>

> dime <http://tools.ietf.org/wg/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






--_000_E194C2E18676714DACA9C3A2516265D2026728D7FR712WXCHMBA12z_--


From nobody Mon Mar 24 07:37: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 7B2711A01FE for ; Mon, 24 Mar 2014 07:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 MpmswkYjO5wF for ; Mon, 24 Mar 2014 07:37:45 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id EF55C1A0226 for ; Mon, 24 Mar 2014 07:37:44 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55127 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS60V-0007uU-6k for dime@ietf.org; Mon, 24 Mar 2014 07:37:43 -0700
Message-ID: <53304336.20006@usdonovans.com>
Date: Mon, 24 Mar 2014 09:37:42 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------090202030507080405000201"
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/OEsxi8u4gNBx6YP5JTPeZEHOD3g
Subject: [Dime] Issue #27 - Result code sent when agent throttles message
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, 24 Mar 2014 14:37:47 -0000

This is a multi-part message in MIME format.
--------------090202030507080405000201
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

We don't have a clean solution for this as existing error result codes
do not get the desired behavior of the reacting node not retrying the
request on another path, if available.

The proposal has been made that we propose an extension to 6733 to
introduce a new result code.  This would be something like:

   DIAMETER_REQUEST_THROTTLED  3011

    A request was received by an agent and the agent determined that the
request needed to be throttled due to an existing overload
    condition.  The client SHOULD NOT attempt to retry the request and
the client SHOULD NOT attempt to sent the request to an
    an alternate peer.

My assumption is that this extension would be included in the the
CER/CEA exchange so an agent would know if it is supported.  A client
that supports this extension is referred to as a 6733+ client below.  A
client that doesn't is referred to as a 6733 client.

With this extension we have two options for wording to be put into the
DOIC specification.

1) Indicate that a DOIC agent that throttles a request MUST send a 3011
error response for all clients, 6733 and 6733+.  This would depend on
default processing in clients for result codes that the client does not
understand.  This default processing is not defined in 6733 (at least I
didn't find it).  The closest I could find was the following.  If an
unrecognized result code was interpreted as the answer message
containing an error then throttling a request would result in the
session being terminated. 

In the case where the answer message itself contains errors, any
   related session SHOULD be terminated by sending an STR or ASR
   message.  The Termination-Cause AVP in the STR MAY be filled with the
   appropriate value to indicate the cause of the error.  An application
   MAY also send an application-specific request instead of an STR or
   ASR message to signal the error in the case where no state is
   maintained or to allow for some form of error recovery with the
   corresponding Diameter entity.

RFC 6733 - Diameter Base Protocol 2) Indicate that a DOIC agent that
throttles a request MUST send a 3011 response to 6733+ clients.  For
6733 clients the agent MUST send DIAMETER_TOO_BUSY 3002.  This is not
perfect as 3002 says the client should try to send to an alternative
peer, but it is as close as we can get.

Neither of these solutions are perfect and would come with the strong
recommendation that Diameter nodes that support DOIC should also support
the above extension.

I propose number 1 as it at least does result in reduction of traffic
sent toward the overloaded server.

Regards,

Steve






--------------090202030507080405000201
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      We don't have a clean solution for this as existing error result
      codes do not get the desired behavior of the reacting node not
      retrying the request on another path, if available.

      

      The proposal has been made that we propose an extension to 6733 to
      introduce a new result code.  This would be something like:

      

         DIAMETER_REQUEST_THROTTLED  3011

      

          A request was received by an agent and the agent determined
      that the request needed to be throttled due to an existing
      overload 

          condition.  The client SHOULD NOT attempt to retry the request
      and the client SHOULD NOT attempt to sent the request to an

          an alternate peer.

      

      My assumption is that this extension would be included in the the
      CER/CEA exchange so an agent would know if it is supported.  A
      client that supports this extension is referred to as a 6733+
      client below.  A client that doesn't is referred to as a 6733
      client.

      

      With this extension we have two options for wording to be put into
      the DOIC specification.

      

      1) Indicate that a DOIC agent that throttles a request MUST send a
      3011 error response for all clients, 6733 and 6733+.  This would
      depend on default processing in clients for result codes that the
      client does not understand.  This default processing is not
      defined in 6733 (at least I didn't find it).  The closest I could
      find was the following.  If an unrecognized result code was
      interpreted as the answer message containing an error then
      throttling a request would result in the session being
      terminated.  

    
      
    
    

      

        

          

            
In the case where the answer message itself contains errors, any
   related session SHOULD be terminated by sending an STR or ASR
   message.  The Termination-Cause AVP in the STR MAY be filled with the
   appropriate value to indicate the cause of the error.  An application
   MAY also send an application-specific request instead of an STR or
   ASR message to signal the error in the case where no state is
   maintained or to allow for some form of error recovery with the
   corresponding Diameter entity.


          

        

      

    

    
      RFC 6733 - Diameter Base Protocol
      2) Indicate that a DOIC agent that throttles a request MUST send a
      3011 response to 6733+ clients.  For 6733 clients the agent MUST
      send DIAMETER_TOO_BUSY 3002.  This is not perfect as 3002 says the
      client should try to send to an alternative peer, but it is as
      close as we can get.

      

      Neither of these solutions are perfect and would come with the
      strong recommendation that Diameter nodes that support DOIC should
      also support the above extension.

      

      I propose number 1 as it at least does result in reduction of
      traffic sent toward the overloaded server.

      

      Regards,

      

      Steve

      

      

      

      

      

    
  


--------------090202030507080405000201--


From nobody Mon Mar 24 08:41: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 71A161A0255 for ; Mon, 24 Mar 2014 08:41:35 -0700 (PDT)
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 1ynGYYrqwSR5 for ; Mon, 24 Mar 2014 08:41:32 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id AD3351A0257 for ; Mon, 24 Mar 2014 08:41:32 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2OFfUAX014902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Mar 2014 10:41:31 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2OFfT77014269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 16:41:29 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 24 Mar 2014 16:41:29 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
Thread-Index: AQHPR2R/UJRKPJ1EBkG4tvNtsb1kxZrwXHQw
Date: Mon, 24 Mar 2014 15:41:29 +0000
Message-ID: 
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> <072.d5e30cfd5cc5ac461bc3774ad9853b2b@trac.tools.ietf.org>
In-Reply-To: <072.d5e30cfd5cc5ac461bc3774ad9853b2b@trac.tools.ietf.org>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1SeLVD3XhkEjii473nHLo6NtX78
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
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, 24 Mar 2014 15:41:35 -0000

Hi Steve

I am oK on your text apart a few sentences on the realm overload for which =
for me we have not yet concluded (cf my to day mail in the thread  [Dime] R=
esolution on action to discuss the need for Realm-Routed-Reports.

This is about this paragraph and especially the word "entire":=20
=20
	On the other hand, an "entire" Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an "entire" realm.

So I think a bit premature to insert this part of text as it is.

Best regards

JJacques=20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoy=E9=A0: lundi 24 mars 2014 14:24
=C0=A0: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overvi=
ew

#41: Need better overview

Changes (by srdonovan@usdonovans.com):

 * status:  new =3D> closed
 * resolution:   =3D> fixed


Comment:

 The following wording for section 3.0 was added.  A new issue will be  ope=
ned to reflect that the remainder of section 3 needs to be made  consistent=
 with the current state of the DIOC solution.

 -----

    The Diameter Overload Information Conveyance (DOIC) mechanism allows
    Diameter nodes to request other nodes to perform overload abatement
    actions, that is, actions to reduce the load offered to the
    overloaded node.

    A Diameter node that supports DOIC is known as a "DOIC endpoint".
    Any Diameter node can act as a DOIC endpoint, including clients,
    servers, and agents.  DOIC endpoints are further divided into
    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
    overload abatement by sending an Overload Report (OLR) to one or more
    reacting nodes.

    A reacting node consumes OLRs, and performs whatever actions are
    needed to fulfill the requests.  A Reporting node may report overload
    on its own behalf, or on behalf of other (typically upstream) nodes.
    Likewise, a reacting node may perform overload abatement on its own
    behalf, or on behalf of other (typically downstream) nodes.

    A node's role as a DOIC endpoint is independent of its Diameter role.
    For example, Diameter relay and proxy agents may act as DOIC
    endpoints, even though they are not endpoints in the Diameter sense.
    Since Diameter enables bi-directional applications, where Diameter
    servers can send requests towards Diameter clients, a given Diameter
    node can simultaneously act as a reporting node and reacting node.

    Likewise, an relay or proxy agent may act as a reacting node from the
    perspective of upstream nodes, and a reporting node from the
    perspective of downstream nodes.

    DOIC endpoints do not generate new messages to carry DOIC related
    information.  Rather, they "piggyback" DOIC information over existing
    Diameter messages by inserting new AVPs into existing Diameter
    requests and responses.  Nodes indicate support for DOIC, and any
    needed DOIC parameters by inserting an OC_Supported_Features AVP
    (Section 4.1) into existing requests and responses.  Reporting nodes
    send OLRs by inserting OC-OLR AVPs.  (Section 4.3)

    A given OLR applies to the Diameter realm and application of the
    Diameter message that carries it.  If a reporting node supports more
    than one realm and/or application, it reports independently for each
    combination of realm and application.  Similarly, OC-Feature-Vector
    AVPs apply to the realm and application of the enclosing message.
    This implies that a node may support DOIC for one application and/or
    realm, but not another, and may indicate different DOIC parameters
    for each application and realm for which it supports DOIC.

    Reacting nodes perform overload abatement according to an agreed-upon
    abatement algorithm.  An abatement algorithm defines the meaning of
    the parameters of an OLR, and the procedures required for overload
    abatement.  This document specifies a single must-support algorithm,
    namely the "loss" algorithm [ref?].  Future specifications may
    introduce new algorithms.

    Overload conditions may vary in scope.  For example, a single
    Diameter node may be overloaded, in which case reacting nodes may
    reasonably attempt to send throttled requests to other destinations
    or via other agents.  On the other hand, an entire Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an entire realm.

    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
    that are "adjacent" for DOIC purposes may not be adjacent from a
    Diameter, or transport, perspective.  For example, one or more
    Diameter agents that do not support DOIC may exist between a given
    pair of reporting and reacting nodes, as long as those agents pass
    unknown AVPs through unmolested.  The report types described in this
    document can safely pass through non-supporting agents.  This may not
    be true for report types defined in future specifications.  Documents
    that introduce new report types MUST describe any limitations on
    their use across non-supporting agents.

--=20
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: 
dime 

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


From nobody Mon Mar 24 09:13: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 557261A024E for ; Mon, 24 Mar 2014 09:13:47 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 RlTO6wzc6jVP for ; Mon, 24 Mar 2014 09:13:40 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 971D81A01CD for ; Mon, 24 Mar 2014 09:13:40 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2OGDdNP003127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Mar 2014 16:13:39 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2OGDc4V008785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 17:13:39 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 24 Mar 2014 17:13:38 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 17:13:38 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRUlVL8WBONWpVkShCkGbZ2B6UJrwNmSAgAAvmYA=
Date: Mon, 24 Mar 2014 16:13:37 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com>
In-Reply-To: <53303991.6060307@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.119]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E15DEMUMBX014nsnin_"
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: 19498
X-purgate-ID: 151667::1395677619-0000128C-53354294/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/_1AsYQbud4wPWkclEfSbfufsTIc
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 24 Mar 2014 16:13:48 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E15DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve





_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E15DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

I do not agree.


 <=
/p>

We should =
still have the option



3) support=
 report type 0 (this is called host report) and support of report type 1 (t=
his has been called relam report but people argued it should
 better be called realm routed request report).


 =
;


Whether or=
 not we need in addition to type 0 and type 1 (or as a replacement of type =
1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There are =
a lot of open questions  with regard to #55 and I have not seen a conc=
lusion.


Where I ha=
ve seen a conclusion is issue #34 and that is inline with option 3).


 =
;


Unless we =
conclude on #55, or decide to re-open #34, option 3) is what should go in t=
he -02 draft.


 =
;


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulrich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan wrote:<=
/p>





Ulrich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I don̵=
7;t know what happend in London.


Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E15DEMUMBX014nsnin_--


From nobody Mon Mar 24 09:31: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 1736D1A0254 for ; Mon, 24 Mar 2014 09:31:22 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 JZzPrEyvy9by for ; Mon, 24 Mar 2014 09:31:17 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8278B1A0236 for ; Mon, 24 Mar 2014 09:31:16 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2OGUIxb031628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Mar 2014 16:30:18 GMT
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 s2OGUItq028397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 17:30:18 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 17:30:18 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Steve Donovan , "Shishufeng (Susan)" , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPR1wzx3BqsKNZM0OHMhP4dMvWQ5rwMNaAgAA8/gA=
Date: Mon, 24 Mar 2014 16:30:17 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D1E62@DEMUMBX014.nsn-intra.net>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>, <53302446.9080700@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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E62DEMUMBX014nsnin_"
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: 45858
X-purgate-ID: 151667::1395678618-0000128C-A8540FE9/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/otXjhM9Dg2fw4IhfRHtq2PsyLWw
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 16:31:22 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E62DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

+1

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 2:52 PM
To: Steve Donovan; Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi all

I am also in line with the agreement tendency as that OC-Report-Type is not=
 required (so to keep the text as it is in the draft); I expressed this  pr=
eference a while ago.


Best regards

JJacques



________________________________
De : DiME [dime-bounces@ietf.org] de la part de Steve Donovan [srdonovan@us=
donovans.com]
Date d'envoi : lundi 24 mars 2014 13:25
=C0 : Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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


--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E62DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











+1<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Monday, March 24, 2014 2:52 PM

To: Steve Donovan; Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 




Hi all



 <=
/p>

I am also in line with th=
e agreement tendency as that OC-Report-Type is not required (so to keep the=
 text as it is in the draft); I expressed this  preference
 a while ago.


 


 <=
/p>

Best regards


 <=
/p>

JJacques



 












De : DiME [dime-bounces@ietf.org] =
de la
 part de Steve Donovan [srdonovan@usdonovans.com]

Date d'envoi : lundi 24 mars 2014 13:25

=C0 : Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shi=
shufeng (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on thi=
s and reached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] =



Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #54: OC-Report-=
Type as mandatory AVP


 


 


Lets have it explicit then. Use '<' and=
 '>' to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan=
 <srdonova=
n@usdonovans.com> wrote:


 




I'm ok with either direction but generally=
 lean toward being explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome =
wrote:




Hello,


I think the agreement tendency is the cont=
rary: OC-Report-Type is not required, while default value is Host. i.e. it =
will remain as it is now in the draft.


This may be of some advantage for some app=
lications that may only use Host, as long as they may never generate Realm =
reports.


If there is consensus on this, I will go w=
ith this.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=
 Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.org


Subject: Re: [Dime] [dime] #54: OC-Report-=
Type as mandatory AVP


 


All,


 


Do we have consensus that the OC-Report-Ty=
pe AVP is required?


 


If so then one change would be as indicate=
d in the syntax definition proposed by Lionel.  We would also remove w=
ording on the default value.


 


Jouni,


 


How do we indicate a fixed position for an=
 AVP?  


 


I presonally don't see this as critical bu=
t we can add this requirement if there is consensus.

 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:=



 


Hi,


 


How having the AVP could be less error pro=
ne if it has a default 


value and the receiver knows exactly how t=
o proceed when the AVP is 


not present?


 


If a node does not include it when it shou=
ld, the implementation is 


broken. Wouldn't a broken node be able to =
put wrong report type into 


the AVP even if the AVP is mandatory?=



 


Anyway, if it is my statement keeping issu=
e #54 still open, consider 


it resolved from my side. I am OK making t=
he OC-Report-Type AVP as 


required/mandatory AVP. Should we also con=
sider it having a fixed 


position just after the OC-Sequence-Number=
 AVP as well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz B=
artolome <maria.cruz.bartolome@ericsson.com> wrote:=



 


 


Hello all,


 


I understand JJ point of view, but I still=
 tend to prefer to make it mandatory, since I think this is less error-pron=
e, since the only node that knows the requested Report-Type is the reportin=
g, if for any reason a reporting is omitting it (since it is optional), it =
will be always interpreted as HOST, but this type may be wrong.<=
/span>


 


I think DEFAULT values should never be err=
or-prone, but used in "general cases", as a simplification, like =
e.g. a default for the Validity-Duration. Default Validity-Duration will ne=
ver be an "error", it could be not the best value (compared with =
another value perfectly tuned to reporting node overload situation) but nev=
er the use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of=
 Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13=



To: Jouni Korhonen


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #54: OC-Report-=
Type as mandatory AVP


 


I actually prefer making it mandatory. The=
 cost of adding it is trivial--even more so for a reporting node that only =
supports the default. The value of having it is less opportunity for intero=
p errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhone=
n <jouni.nos=
pam@gmail.com> wrote:


 


 


Agree that it is a small optimization, whi=
ch I put there because at 


the beginning there seemed to be a lot of =
worry on every extra AVP 


;-)


 


I prefer having the AVP optional but with =
a default value just like 


it is now. We have the same for the reduct=
ion percentage and the 


validity time as well.

 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTI=
N, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-luc=
ent.com> wrote:


 


Hi Mcruz


 


The current description indicates that whe=
n not present the OLR is of type Host, which was fine for me and keeps my p=
reference. 


We may have  deployments where Realm =
OLR is not used, or where statistically the HOST type is the most frequent,=
 so to have the grouped OLR-AVP containing a minimum of AVPs minimizes pars=
ing. I agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de=
 


lionel.morand@orange.com Envoy=E9 : mercredi 12 f=
=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [=
Dime] 


[dime] #54: OC-Report-Type as mandatory AV=
P


 


Hi Maria Cruz,


 


I'm assuming that you mean "required&=
quot; instead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


       =
    < OC-Sequence-Number >


       =
    [ OC-Report-Type ]


       =
    [ OC-Reduction-Percentage ]


       =
    [ OC-Validity-Duration ]


       =
  * [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


       =
    < OC-Sequence-Number >


       =
    { OC-Report-Type }


       =
    [ OC-Reduction-Percentage ]


       =
    [ OC-Validity-Duration ]


       =
  * [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de=
 dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2=
014 15:26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [=
Dime] 


[dime] #54: OC-Report-Type as mandatory AV=
P


 


#54: OC-Report-Type as mandatory AVP<=
/o:p>


 


Now in chapter 4.6:

 


 The default value of the OC-Report-T=
ype AVP is 0 (i.e. the host  


report).


 


This AVP is always required, right? Then, =
I think it is more precise that  we define this AVP as mandatory.=



 


--


------------------------------------------=
-----+---------------------


------------------------------------------=
-----+---


------------------------------------------=
-----+---


Reporter:  maria.cruz.bartolome@ericsson.=
com  |      Owner:  MCruz=



  Type:  defect   =
;            &n=
bsp;            =
; |  Bartolom=E9


Priority:  major   &nb=
sp;            =
            &nb=
sp; |     Status:  new


Component:  draft-docdt-dime-ovli&nbs=
p;             =
|  Milestone:


Severity:  Active WG Document &n=
bsp;            =
;   |    Version:  1.0

       =
            &nb=
sp;            =
            | &=
nbsp; Keywords:


------------------------------------------=
-----+---------------------


------------------------------------------=
-----+---


------------------------------------------=
-----+---


 


Ticket URL: <http://trac.tools.iet=
f.org/wg/dime/trac/ticket/54>


dime <http://tools.ietf.org/wg/dime/>


 


__________________________________________=
_____


DiME mailing list


DiME@ietf.org


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


 


__________________________________________=
___________________________


__________________________________________=
__________


 


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


 


This message and its attachments may conta=
in confidential or privileged information that may be protected by law; the=
y 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.<=
/o:p>


As emails may be altered, Orange is not li=
able 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


 


 




__________________________________________=
_____


DiME mailing list


DiME@ietf.org


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






 =













--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1E62DEMUMBX014nsnin_--


From nobody Mon Mar 24 09:49: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 BF3541A027E for ; Mon, 24 Mar 2014 09:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ePpUXeYlXIg6 for ; Mon, 24 Mar 2014 09:49:51 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDFA1A0244 for ; Mon, 24 Mar 2014 09:49:51 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2OGn6Ig028720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 24 Mar 2014 16:49:06 GMT
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 s2OGn6Lb010519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Mar 2014 17:49:06 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 17:49:06 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
Thread-Index: AQHPR2Rm11G5f/1f9UuRb0p2qg5A/5rwT3+AgAAjovA=
Date: Mon, 24 Mar 2014 16:49:05 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D1EC2@DEMUMBX014.nsn-intra.net>
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> <072.d5e30cfd5cc5ac461bc3774ad9853b2b@trac.tools.ietf.org> 
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="iso-8859-1"
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: 7053
X-purgate-ID: 151667::1395679746-0000128C-751889A8/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/cWACTkOUIcZ7fNNfQmr3GK4LSuM
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
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, 24 Mar 2014 16:49:55 -0000

+1

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 4:41 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overvie=
w

Hi Steve

I am oK on your text apart a few sentences on the realm overload for which =
for me we have not yet concluded (cf my to day mail in the thread  [Dime] R=
esolution on action to discuss the need for Realm-Routed-Reports.

This is about this paragraph and especially the word "entire":=20
=20
	On the other hand, an "entire" Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an "entire" realm.

So I think a bit premature to insert this part of text as it is.

Best regards

JJacques=20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker
Envoy=E9=A0: lundi 24 mars 2014 14:24
=C0=A0: draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overvi=
ew

#41: Need better overview

Changes (by srdonovan@usdonovans.com):

 * status:  new =3D> closed
 * resolution:   =3D> fixed


Comment:

 The following wording for section 3.0 was added.  A new issue will be  ope=
ned to reflect that the remainder of section 3 needs to be made  consistent=
 with the current state of the DIOC solution.

 -----

    The Diameter Overload Information Conveyance (DOIC) mechanism allows
    Diameter nodes to request other nodes to perform overload abatement
    actions, that is, actions to reduce the load offered to the
    overloaded node.

    A Diameter node that supports DOIC is known as a "DOIC endpoint".
    Any Diameter node can act as a DOIC endpoint, including clients,
    servers, and agents.  DOIC endpoints are further divided into
    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
    overload abatement by sending an Overload Report (OLR) to one or more
    reacting nodes.

    A reacting node consumes OLRs, and performs whatever actions are
    needed to fulfill the requests.  A Reporting node may report overload
    on its own behalf, or on behalf of other (typically upstream) nodes.
    Likewise, a reacting node may perform overload abatement on its own
    behalf, or on behalf of other (typically downstream) nodes.

    A node's role as a DOIC endpoint is independent of its Diameter role.
    For example, Diameter relay and proxy agents may act as DOIC
    endpoints, even though they are not endpoints in the Diameter sense.
    Since Diameter enables bi-directional applications, where Diameter
    servers can send requests towards Diameter clients, a given Diameter
    node can simultaneously act as a reporting node and reacting node.

    Likewise, an relay or proxy agent may act as a reacting node from the
    perspective of upstream nodes, and a reporting node from the
    perspective of downstream nodes.

    DOIC endpoints do not generate new messages to carry DOIC related
    information.  Rather, they "piggyback" DOIC information over existing
    Diameter messages by inserting new AVPs into existing Diameter
    requests and responses.  Nodes indicate support for DOIC, and any
    needed DOIC parameters by inserting an OC_Supported_Features AVP
    (Section 4.1) into existing requests and responses.  Reporting nodes
    send OLRs by inserting OC-OLR AVPs.  (Section 4.3)

    A given OLR applies to the Diameter realm and application of the
    Diameter message that carries it.  If a reporting node supports more
    than one realm and/or application, it reports independently for each
    combination of realm and application.  Similarly, OC-Feature-Vector
    AVPs apply to the realm and application of the enclosing message.
    This implies that a node may support DOIC for one application and/or
    realm, but not another, and may indicate different DOIC parameters
    for each application and realm for which it supports DOIC.

    Reacting nodes perform overload abatement according to an agreed-upon
    abatement algorithm.  An abatement algorithm defines the meaning of
    the parameters of an OLR, and the procedures required for overload
    abatement.  This document specifies a single must-support algorithm,
    namely the "loss" algorithm [ref?].  Future specifications may
    introduce new algorithms.

    Overload conditions may vary in scope.  For example, a single
    Diameter node may be overloaded, in which case reacting nodes may
    reasonably attempt to send throttled requests to other destinations
    or via other agents.  On the other hand, an entire Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an entire realm.

    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
    that are "adjacent" for DOIC purposes may not be adjacent from a
    Diameter, or transport, perspective.  For example, one or more
    Diameter agents that do not support DOIC may exist between a given
    pair of reporting and reacting nodes, as long as those agents pass
    unknown AVPs through unmolested.  The report types described in this
    document can safely pass through non-supporting agents.  This may not
    be true for report types defined in future specifications.  Documents
    that introduce new report types MUST describe any limitations on
    their use across non-supporting agents.

--=20
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: 
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 24 09:51: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 CE0321A01DF for ; Mon, 24 Mar 2014 09:51:11 -0700 (PDT)
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 UEAR9dcbsaUR for ; Mon, 24 Mar 2014 09:51:05 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 236991A026D for ; Mon, 24 Mar 2014 09:51:04 -0700 (PDT)
Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 7EF6D2AC709; Mon, 24 Mar 2014 17:51:03 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6142338406C; Mon, 24 Mar 2014 17:51:03 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Mon, 24 Mar 2014 17:51:03 +0100
From: 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "Steve Donovan" , "Shishufeng (Susan)" , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRXfTKav1Yd2xqUyLNClmxsrsL5rvj0+AgACNVgCAABf6gIAALFyAgAASFiA=
Date: Mon, 24 Mar 2014 16:51:02 +0000
Message-ID: <8734_1395679863_53306277_8734_13050_1_6B7134B31289DC4FAF731D844122B36E518BC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>, <53302446.9080700@usdonovans.com>  <5BCBA1FC2B7F0B4C9D935572D9000668151D1E62@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1E62@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.6]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E518BC8PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.24.134215
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XKAb1P6H3m_PzpDhXd2-WFpkCw0
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 16:51:12 -0000

--_000_6B7134B31289DC4FAF731D844122B36E518BC8PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

IMHO it is a lot of fuse for something not so critical!
Session-id is for no use at all in a lot of Diameter applications and no on=
e complains :)

Here it is even simpler: there is a clear use of this AVP. This info (the e=
xplicit AVP or the default value) needs to be taken into account in the pro=
cess of the received OLR and any compliant implementation needs to be able =
to understand the OLR-Report-Type.
So except "optimization", what is the rational not to make it required in t=
he OLR?

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : lundi 24 mars 2014 17:30
=C0 : ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Steve Donovan; Shishufeng (=
Susan); Jouni Korhonen
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

+1

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 2:52 PM
To: Steve Donovan; Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi all

I am also in line with the agreement tendency as that OC-Report-Type is not=
 required (so to keep the text as it is in the draft); I expressed this  pr=
eference a while ago.


Best regards

JJacques



________________________________
De : DiME [dime-bounces@ietf.org] de la part de Steve Donovan [srdonovan@us=
donovans.com]
Date d'envoi : lundi 24 mars 2014 13:25
=C0 : Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.


--_000_6B7134B31289DC4FAF731D844122B36E518BC8PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











IMHO it is=
 a lot of fuse for something not so critical!


Session-id=
 is for no use at all in a lot of Diameter applications and no one complains
J


 =
;


Here it is=
 even simpler: there is a clear use of this AVP. This info (the explicit AV=
P or the default value) needs to be taken into account in
 the process of the received OLR and any compliant implementation needs to =
be able to understand the OLR-Report-Type.


So except =
"optimization", what is the rational not to make it required in t=
he OLR?



 =
;


Lionel


 =
;






De : DiME=
 [mailto:dime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : lundi 24 mars 2014 17:30

=C0 : ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Steve Donovan; =
Shishufeng (Susan); Jouni Korhonen

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


+1=



 =







From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Monday, March 24, 2014 2:52 PM

To: Steve Donovan; Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 




Hi all



 =



I am also in =
line with the agreement tendency as that OC-Report-Type is not required (so=
 to keep the text as it is in the draft); I expressed this
  preference a while ago.

 


 =



Best regards<=
/span>


 =



JJacques



 =














Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 1=
0:59 PM, Shishufeng (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discu=
ssion on this and reached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan=



 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gm=
ail.com] 


Sent: Saturday, March 22, 2014=
 10:38 AM


To: Steve Donovan


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #54=
: OC-Report-Type as mandatory AVP


 


 


Lets have it explicit then. Us=
e '<' and '>' to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, S=
teve Donovan =
<srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction b=
ut generally lean toward being explicit.


 


Do we have other opinions?&nbs=
p; 


 


Steve=



On 3/18/14 12:16 PM, Maria Cru=
z Bartolome wrote:




Hello,


I think the agreement tendency=
 is the contrary: OC-Report-Type is not required, while default value is Ho=
st. i.e. it will remain as it is now in the draft.=



This may be of some advantage =
for some applications that may only use Host, as long as they may never gen=
erate Realm reports.


If there is consensus on this,=
 I will go with this.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] =
On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2=
014 17:47


To: dime@ietf.org


Subject: Re: [Dime] [dime] #54=
: OC-Report-Type as mandatory AVP


 


All,<=
o:p>


 


Do we have consensus that the =
OC-Report-Type AVP is required?<=
/pre>

 


If so then one change would be=
 as indicated in the syntax definition proposed by Lionel.  We would a=
lso remove wording on the default value.


 


Jouni,


 


How do we indicate a fixed pos=
ition for an AVP?  


 


I presonally don't see this as=
 critical but we can add this requirement if there is consensus.


 


Regards,


 


Steve=



 


On 2/28/14 10:27 AM, Jouni Kor=
honen wrote:


 


Hi,


 


How having the AVP could be le=
ss error prone if it has a default 


value and the receiver knows e=
xactly how to proceed when the AVP is <=
/span>


not present?


 


If a node does not include it =
when it should, the implementation is <=
/span>


broken. Wouldn't a broken node=
 be able to put wrong report type into =



the AVP even if the AVP is man=
datory?


 


Anyway, if it is my statement =
keeping issue #54 still open, consider =



it resolved from my side. I am=
 OK making the OC-Report-Type AVP as 


required/mandatory AVP. Should=
 we also consider it having a fixed 


position just after the OC-Seq=
uence-Number AVP as well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, =
Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view,=
 but I still tend to prefer to make it mandatory, since I think this is les=
s error-prone, since the only node that knows the requested Report-Type is =
the reporting, if for any reason a reporting is omitting it (since it is op=
tional), it will be always interpreted as HOST, but this type may be wrong.=



 


I think DEFAULT values should =
never be error-prone, but used in "general cases", as a simplific=
ation, like e.g. a default for the Validity-Duration. Default Validity-Dura=
tion will never be an "error", it could be not the best value (co=
mpared with another value perfectly tuned to reporting node overload situat=
ion) but never the use of a Default value should lead to an erroneous behav=
ior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] =
On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero d=
e 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #54=
: OC-Report-Type as mandatory AVP


 


I actually prefer making it ma=
ndatory. The cost of adding it is trivial--even more so for a reporting nod=
e that only supports the default. The value of having it is less opportunit=
y for interop errors.


 


On Feb 13, 2014, at 6:05 AM, J=
ouni Korhonen &=
lt;jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optim=
ization, which I put there because at <=
/span>


the beginning there seemed to =
be a lot of worry on every extra AVP 


;-)


 


I prefer having the AVP option=
al but with a default value just like <=
/span>


it is now. We have the same fo=
r the reduction percentage and the 


validity time as well.<=
span lang=3D"DE">


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, =
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin=
@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indica=
tes that when not present the OLR is of type Host, which was fine for me an=
d keeps my preference. 


We may have  deployments =
where Realm OLR is not used, or where statistically the HOST type is the mo=
st frequent, so to have the grouped OLR-AVP containing a minimum of AVPs mi=
nimizes parsing. I agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] D=
e la part de 


lionel.morand@orange.com Envoy=E9 : mer=
credi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson.com O=
bjet : Re: [Dime] 


[dime] #54: OC-Report-Type as =
mandatory AVP


 


Hi Maria Cruz,


 


I'm assuming that you mean &qu=
ot;required" instead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: =
TBD2 >


     =
      < OC-Sequence-Number >


     =
      [ OC-Report-Type ]<=
o:p>


     =
      [ OC-Reduction-Percentage ]


     =
      [ OC-Validity-Duration ]


     =
    * [ AVP ]

 


You would prefer:


 


OC-OLR ::=3D < AVP Header: =
TBD2 >


     =
      < OC-Sequence-Number >


     =
      { OC-Report-Type }<=
o:p>


     =
      [ OC-Reduction-Percentage ]


     =
      [ OC-Validity-Duration ]


     =
    * [ AVP ]

 


And I'm fine with this proposa=
l.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] D=
e la part de dime issue 


tracker Envoy=E9 : mercredi 12=
 f=E9vrier 2014 15:26 =C0 :


maria.cruz.bartolome@ericsson.com<=
/a> Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as =
mandatory AVP


 


#54: OC-Report-Type as mandato=
ry AVP


 


Now in chapter 4.6:


 


 The default value of the=
 OC-Report-Type AVP is 0 (i.e. the host  


report).


 


This AVP is always required, r=
ight? Then, I think it is more precise that  we define this AVP as man=
datory.


 


--


------------------------------=
-----------------+---------------------


------------------------------=
-----------------+---


------------------------------=
-----------------+---


Reporter:  maria.cruz.bartolo=
me@ericsson.com  |      Owner:  MCru=
z


  Type:  defect =
;            &n=
bsp;            =
;   |  Bartolom=E9


Priority:  major &nb=
sp;            =
            &nb=
sp;   |     Status:  new


Component:  draft-docdt-d=
ime-ovli           &=
nbsp;  |  Milestone:

Severity:  Active WG Docu=
ment            =
;     |    Version:  1.0


     =
            &nb=
sp;            =
            &nb=
sp; |   Keywords:


------------------------------=
-----------------+---------------------


------------------------------=
-----------------+---


------------------------------=
-----------------+---


 


Ticket URL: <http://tr=
ac.tools.ietf.org/wg/dime/trac/ticket/54>


dime <http://tools.ietf.org/wg/dime/><=
/a>


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_______________________________________=



______________________________=
______________________


 


Ce message et ses pieces joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si v=
ous 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 messa=
ge a ete altere, deforme ou falsifie. Merci.<=
/o:p>


 


This message and its attachmen=
ts may contain confidential or privileged information that may be protected=
 by law; they should not be distributed, used or copied without authorisati=
on.


If you have received this emai=
l in error, please notify the sender and delete this message and its attach=
ments.


As emails may be altered, Oran=
ge is not liable for messages that have been modified, changed or falsified=
.


Thank you.


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


 




______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/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_6B7134B31289DC4FAF731D844122B36E518BC8PEXCVZYM13corpora_--


From nobody Mon Mar 24 10:23: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 D4EDC1A024C for ; Mon, 24 Mar 2014 10:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 AhrDX5YvyeCu for ; Mon, 24 Mar 2014 10:23:34 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C4F571A023F for ; Mon, 24 Mar 2014 10:23:33 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2OHNVIQ011036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Mar 2014 17:23:32 GMT
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2OHNV2J007126 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 18:23:31 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Mon, 24 Mar 2014 18:23:31 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtA
Date: Mon, 24 Mar 2014 17:23:30 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>
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: 4394
X-purgate-ID: 151667::1395681812-0000137C-36A49F1F/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/MBAFuWG_hQqEONT_BZsmVuwBfFA
Subject: Re: [Dime] issue #56 proposed 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, 24 Mar 2014 17:23:37 -0000

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)=20
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

Ulrich



From nobody Mon Mar 24 11:07: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 4E2F61A0268 for ; Mon, 24 Mar 2014 11:07:50 -0700 (PDT)
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 I89C2ZSoY0HY for ; Mon, 24 Mar 2014 11:07:48 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id E69C91A0128 for ; Mon, 24 Mar 2014 11:07:47 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2OI7j5c016873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Mar 2014 13:07:46 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2OI7ipg010347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 19:07:44 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 24 Mar 2014 19:07:44 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKA=
Date: Mon, 24 Mar 2014 18:07:44 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Zwtj1hDXCw7bNeWFCa4hbEC6dN0
Subject: Re: [Dime] issue #56 proposed 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, 24 Mar 2014 18:07:50 -0000

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: lundi 24 mars 2014 18:24
=C0=A0: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Objet=A0: Re: [Dime] issue #56 proposed conclusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)=20
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

Ulrich


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


From nobody Mon Mar 24 11:38: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 93C931A029C for ; Mon, 24 Mar 2014 11:37:54 -0700 (PDT)
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 TTGQoyPS0gkb for ; Mon, 24 Mar 2014 11:37:51 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 92C901A0299 for ; Mon, 24 Mar 2014 11:37:51 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55566 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS9kq-0006Jy-QZ; Mon, 24 Mar 2014 11:37:50 -0700
Message-ID: <53307B7C.4000200@usdonovans.com>
Date: Mon, 24 Mar 2014 13:37:48 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------040306070705090502000809"
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/AnVp9C6X-8R0I-o9IkLYvcoqNvc
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 24 Mar 2014 18:37:54 -0000

This is a multi-part message in MIME format.
--------------040306070705090502000809
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in
our discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm
report and the only remaining issue was whether we also included the RRR
report type.

At this point, the only option is to leave all of the issues related to
the report types open and attempt to resolve them in the -03 draft.

Steve

On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> I do not agree.
>
>  
>
> We should still have the option
>
> 3) support report type 0 (this is called host report) and support of
> report type 1 (this has been called relam report but people argued it
> should better be called realm routed request report).
>
>  
>
> Whether or not we need in addition to type 0 and type 1 (or as a
> replacement of type 1) a realm-no-matter-whether-destination-host-is
> present-or-not report   is an open issue (see #55).
>
> There are a lot of open questions  with regard to #55 and I have not
> seen a conclusion.
>
> Where I have seen a conclusion is issue #34 and that is inline with
> option 3).
>
>  
>
> Unless we conclude on #55, or decide to re-open #34, option 3) is what
> should go in the -02 draft.
>
>  
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, March 24, 2014 2:57 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Ulrich,
> All,
>
> We have two options for the -02 draft.
>
> 1) Support Host and Realm as proposed below, removing RRR reports.
> 2) Support Host, Realm and RRR reports.
>
> The default plan is to go with option 1 in the -02 draft, as that was
> the proposal that came out of the meeting in London.  RRR reports can
> be added back in if and when we are convinced of the need. 
>
> If there are strong objections to this then I will update the -02
> draft to reflect all three report types.
>
> I plan to make these updates Wednesday morning, Dallas, Texas time.
>
> Either way I do not expect we will have agreed to wording on the
> interaction between the report types when a reacting node has multiple
> report types, all of which apply to individual requests.  This will
> need to be addressed in the -03 draft.
>
> Regards,
>
> Steve
>
> On 3/21/14 4:05 PM, Steve Donovan wrote:
>
>     Ulrich,
>
>     The discussion should be captured in the minutes to the meeting. 
>     I wasn't able to find them posted yet.
>
>     Jouni, Lionel, what is the status of the minutes for the meeting?
>
>     My reading of emails prior to the London meeting is different from
>     yours.  I believe we had come to the conclusion that we needed
>     host and realm (with the definition of realm as outlined below). 
>     We were still discussing the need for Realm-Routed-Request reports.
>
>     Regards,
>
>     Steve
>
>     On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Steve,
>
>          
>
>         I don't know what happend in London.
>
>         Can you please summarize the technical reasons that led to the
>         London agreement.
>
>         E-mail discussions prior to London have clearly directed
>         towards a report type that requests throttling of realm routed
>         request messages (i.e. not containing a destination host)
>         rather than a report type that requests throttling of messages
>         routed towards a realm (no matter whether they contain a
>         destination host or not).   
>
>          
>
>         Ulrich
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>         Steve Donovan
>         *Sent:* Friday, March 21, 2014 3:33 PM
>         *To:* dime@ietf.org 
>         *Subject:* [Dime] Resolution on action to discuss the need for
>         Realm-Routed-Reports
>
>          
>
>         All,
>
>         Ben and I took the action item to discuss the need for the
>         Realm-Routed-Reports (RRR) report type.
>
>         As you may recall, the consensus coming out of the DIME WG
>         meeting in London was to support two report types:
>
>         - Host -- Impacting requests with a Destination-Host AVP
>         matching the host in the overload report (with the host
>         implicitly determined from the Origin-Host AVP of the answer
>         message carrying the overload report).
>
>         - Realm -- Impacting 100% of the requests with a
>         Destination-Realm AVP matching the realm in the overload
>         report (with the realm implicitly determine from the
>         Origin-Realm of the answer message carrying the overload report).
>
>         The action Ben and I took was to come back with an opinion on
>         whether RRR reports should also be supported.
>
>         My summary of the discussion is that we recommend to NOT
>         include RRR reports in the current version of the base DOIC
>         draft. 
>
>         We still have some concerns with the granularity of control
>         enabled by having just the two report types but the analysis
>         of whether RRR reports are still needed can occur independent
>         of the base DOIC draft.  If there is a determination that RRRs
>         are needed in time to include in the base draft then it can be
>         considered at that time.
>
>         Based on this, I propose the following
>
>         - Resolution to issue #23 is to remove RRR reports from the
>         document.
>         - Resolution to issue #55 is to add Realm reports (actually to
>         redefine them per the above definition).
>         - Resolution to issue #57 is that it no longer applies (as it
>         deals with RRRs).
>
>         There is also need for text describing the interaction between
>         host and the realm reports.  I don't expect we will have
>         consensus on this wording prior to the -02 draft being
>         submitted.  To this end, I'll open a new issue to deal with
>         the need for wording on the interaction.
>
>         Regards,
>
>         Steve
>
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>  
>


--------------040306070705090502000809
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ok, we are going
      backwards on this one.

      

      I did not include option three because we had moved past that
      option in our discussions, both on the list (I thought), and in
      the meeting. 

      

      I believe that we had come to rough consensus on the need for a
      realm report and the only remaining issue was whether we also
      included the RRR report type.

      

      At this point, the only option is to leave all of the issues
      related to the report types open and attempt to resolve them in
      the -03 draft.

      

      Steve

      

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

    

    

      
      
      
      

        
Steve,

        
 

        
I
            do not agree.

        
 

        
We should still have the option
            

        
3) support report type 0 (this is called host
            report) and support of report type 1 (this has been called
            relam report but people argued it should better be called
            realm routed request report).

        
 

        
Whether or not we need in addition to type 0
            and type 1 (or as a replacement of type 1) a
            realm-no-matter-whether-destination-host-is present-or-not
            report   is an open issue (see #55).

        
There are a lot of open questions  with regard
            to #55 and I have not seen a conclusion.

        
Where I have seen a conclusion is issue #34 and
            that is inline with option 3).

        
 

        
Unless we conclude on #55, or decide to re-open
            #34, option 3) is what should go in the -02 draft.

        
 

        
 

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Monday, March 24, 2014 2:57 PM

                To: dime@ietf.org

                Subject: Re: [Dime] Resolution on action to
                discuss the need for Realm-Routed-Reports

          

        

        
 

        
Ulrich,

          All,

          

          We have two options for the -02 draft.

          

          1) Support Host and Realm as proposed below, removing RRR
          reports.

          2) Support Host, Realm and RRR reports.

          

          The default plan is to go with option 1 in the -02 draft, as
          that was the proposal that came out of the meeting in London. 
          RRR reports can be added back in if and when we are convinced
          of the need. 
          

          

          If there are strong objections to this then I will update the
          -02 draft to reflect all three report types.

          

          I plan to make these updates Wednesday morning, Dallas, Texas
          time.

          

          Either way I do not expect we will have agreed to wording on
          the interaction between the report types when a reacting node
          has multiple report types, all of which apply to individual
          requests.  This will need to be addressed in the -03 draft.

          

          Regards,

          

          Steve

        

          
On 3/21/14 4:05 PM, Steve Donovan wrote:

        

        

          
Ulrich,

            

            The discussion should be captured in the minutes to the
            meeting.  I wasn't able to find them posted yet.

            

            Jouni, Lionel, what is the status of the minutes for the
            meeting?

            

            My reading of emails prior to the London meeting is
            different from yours.  I believe we had come to the
            conclusion that we needed host and realm (with the
            definition of realm as outlined below).  We were still
            discussing the need for Realm-Routed-Request reports.

            

            Regards,

            

            Steve

          

            
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN
              - DE/Munich) wrote:

          

          

            
Steve,

            
 

            
I don’t know what happend in London.

            
Can you please summarize the technical
                reasons that led to the London agreement.
              

            
E-mail discussions prior to London have
                clearly directed towards a report type that requests
                throttling of realm routed request messages (i.e. not
                containing a destination host) rather than a report type
                that requests throttling of messages routed towards a
                realm (no matter whether they contain a destination host
                or not).   

            
 

            
Ulrich

            
 

            

              

                
From: DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of ext Steve Donovan

                    Sent: Friday, March 21, 2014 3:33 PM

                    To: dime@ietf.org

                    Subject: [Dime] Resolution on action to
                    discuss the need for Realm-Routed-Reports

              

            

            
 

            
All,

              

              Ben and I took the action item to discuss the need for the
              Realm-Routed-Reports (RRR) report type.

              

              As you may recall, the consensus coming out of the DIME WG
              meeting in London was to support two report types:

              

              - Host -- Impacting requests with a Destination-Host AVP
              matching the host in the overload report (with the host
              implicitly determined from the Origin-Host AVP of the
              answer message carrying the overload report).

              

              - Realm -- Impacting 100% of the requests with a
              Destination-Realm AVP matching the realm in the overload
              report (with the realm implicitly determine from the
              Origin-Realm of the answer message carrying the overload
              report).

              

              The action Ben and I took was to come back with an opinion
              on whether RRR reports should also be supported.

              

              My summary of the discussion is that we recommend to NOT
              include RRR reports in the current version of the base
              DOIC draft. 
              

              

              We still have some concerns with the granularity of
              control enabled by having just the two report types but
              the analysis of whether RRR reports are still needed can
              occur independent of the base DOIC draft.  If there is a
              determination that RRRs are needed in time to include in
              the base draft then it can be considered at that time.

              

              Based on this, I propose the following 

              

              - Resolution to issue #23 is to remove RRR reports from
              the document.

              - Resolution to issue #55 is to add Realm reports
              (actually to redefine them per the above definition).

              - Resolution to issue #57 is that it no longer applies (as
              it deals with RRRs).

              

              There is also need for text describing the interaction
              between host and the realm reports.  I don't expect we
              will have consensus on this wording prior to the -02 draft
              being submitted.  To this end, I'll open a new issue to
              deal with the need for wording on the interaction.

              

              Regards,

              

              Steve 

          

          


            

            

            

            

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

        

        
 

      

    

    

  


--------------040306070705090502000809--


From nobody Mon Mar 24 11:42: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 7C2811A02A0 for ; Mon, 24 Mar 2014 11:42:48 -0700 (PDT)
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 gA9pdmJiYKbM for ; Mon, 24 Mar 2014 11:42:43 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id B69661A027A for ; Mon, 24 Mar 2014 11:42:43 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55576 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WS9pX-0005P3-6F; Mon, 24 Mar 2014 11:42:41 -0700
Message-ID: <53307C9E.7060203@usdonovans.com>
Date: Mon, 24 Mar 2014 13:42:38 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: lionel.morand@orange.com,  "Wiehe, Ulrich (NSN - DE/Munich)" , "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" ,  "Shishufeng (Susan)" ,  Jouni Korhonen 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>, <53302446.9080700@usdonovans.com>  <5BCBA1FC2B7F0B4C9D935572D9000668151D1E62@DEMUMBX014.nsn-intra.net> <8734_1395679863_53306277_8734_13050_1_6B7134B31289DC4FAF731D844122B36E518BC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <8734_1395679863_53306277_8734_13050_1_6B7134B31289DC4FAF731D844122B36E518BC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------020805070209010706000401"
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/bh309pJvx_gucFRZPFHAPZ_Ck4E
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 24 Mar 2014 18:42:48 -0000

This is a multi-part message in MIME format.
--------------020805070209010706000401
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I agree.  We need to find a way to stop circling around many of these
issues or we will never get the document finished.

In my opinion, focusing on trivial optimizations is not where we should
be spending our time.  However, if people think it is that important to
be able to not include the report-type AVP in some of the messages then
by all means, let's make it optional, with a default of host, and let's
move on to issues that matter.

Steve

On 3/24/14 11:51 AM, lionel.morand@orange.com wrote:
>
> IMHO it is a lot of fuse for something not so critical!
>
> Session-id is for no use at all in a lot of Diameter applications and
> no one complains J
>
>  
>
> Here it is even simpler: there is a clear use of this AVP. This info
> (the explicit AVP or the default value) needs to be taken into account
> in the process of the received OLR and any compliant implementation
> needs to be able to understand the OLR-Report-Type.
>
> So except "optimization", what is the rational not to make it required
> in the OLR?
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Wiehe,
> Ulrich (NSN - DE/Munich)
> *Envoyé :* lundi 24 mars 2014 17:30
> *À :* ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Steve Donovan;
> Shishufeng (Susan); Jouni Korhonen
> *Cc :* dime@ietf.org
> *Objet :* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> +1
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext TROTTIN,
> JEAN-JACQUES (JEAN-JACQUES)
> *Sent:* Monday, March 24, 2014 2:52 PM
> *To:* Steve Donovan; Shishufeng (Susan); Jouni Korhonen
> *Cc:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> Hi all
>
>  
>
> I am also in line with the agreement tendency as that OC-Report-Type
> is not required (so to keep the text as it is in the draft); I
> expressed this  preference a while ago.
>
>  
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
> ------------------------------------------------------------------------
>
> *De :*DiME [dime-bounces@ietf.org] de la part de Steve Donovan
> [srdonovan@usdonovans.com]
> *Date d'envoi :* lundi 24 mars 2014 13:25
> *À :* Shishufeng (Susan); Jouni Korhonen
> *Cc:* dime@ietf.org 
> *Objet :* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
> Susan,
>
> We are in the middle of the discussion and have not yet reached consensus.
>
> I agree with Jouni on making it explicit.  Either way, we should try
> to make a decision quickly.
>
> Steve
>
> On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:
>
>     Hello Jouni,
>
>      
>
>     I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 
>
>      
>
>     Best Regards,
>
>     Susan
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>     Sent: Saturday, March 22, 2014 10:38 AM
>
>     To: Steve Donovan
>
>     Cc: dime@ietf.org 
>
>     Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>      
>
>      
>
>     Lets have it explicit then. Use '<' and '>' to make the position fixed.
>
>      
>
>     - Jouni
>
>      
>
>     On Mar 19, 2014, at 1:29 AM, Steve Donovan   wrote:
>
>      
>
>         I'm ok with either direction but generally lean toward being explicit.
>
>          
>
>         Do we have other opinions?  
>
>          
>
>         Steve
>
>         On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
>
>             Hello,
>
>             I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.
>
>             This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.
>
>             If there is consensus on this, I will go with this.
>
>             Best regards
>
>             /MCruz
>
>              
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>
>             Sent: martes, 18 de marzo de 2014 17:47
>
>             To: dime@ietf.org 
>
>             Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>              
>
>             All,
>
>              
>
>             Do we have consensus that the OC-Report-Type AVP is required?
>
>              
>
>             If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.
>
>              
>
>             Jouni,
>
>              
>
>             How do we indicate a fixed position for an AVP?  
>
>              
>
>             I presonally don't see this as critical but we can add this requirement if there is consensus.
>
>              
>
>             Regards,
>
>              
>
>             Steve
>
>              
>
>             On 2/28/14 10:27 AM, Jouni Korhonen wrote:
>
>              
>
>             Hi,
>
>              
>
>             How having the AVP could be less error prone if it has a default 
>
>             value and the receiver knows exactly how to proceed when the AVP is 
>
>             not present?
>
>              
>
>             If a node does not include it when it should, the implementation is 
>
>             broken. Wouldn't a broken node be able to put wrong report type into 
>
>             the AVP even if the AVP is mandatory?
>
>              
>
>             Anyway, if it is my statement keeping issue #54 still open, consider 
>
>             it resolved from my side. I am OK making the OC-Report-Type AVP as 
>
>             required/mandatory AVP. Should we also consider it having a fixed 
>
>             position just after the OC-Sequence-Number AVP as well since it is 
>
>             going to in every OC-OLR?
>
>              
>
>             - Jouni
>
>              
>
>              
>
>              
>
>             On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome   wrote:
>
>              
>
>              
>
>             Hello all,
>
>              
>
>             I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
>
>              
>
>             I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
>
>              
>
>             Best regards
>
>             /MCruz
>
>              
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>
>             Sent: viernes, 14 de febrero de 2014 23:13
>
>             To: Jouni Korhonen
>
>             Cc: dime@ietf.org 
>
>             Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>              
>
>             I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
>
>              
>
>             On Feb 13, 2014, at 6:05 AM, Jouni Korhonen   wrote:
>
>              
>
>              
>
>             Agree that it is a small optimization, which I put there because at 
>
>             the beginning there seemed to be a lot of worry on every extra AVP 
>
>             ;-)
>
>              
>
>             I prefer having the AVP optional but with a default value just like 
>
>             it is now. We have the same for the reduction percentage and the 
>
>             validity time as well.
>
>              
>
>             - Jouni
>
>              
>
>             On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"   wrote:
>
>              
>
>             Hi Mcruz
>
>              
>
>             The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
>
>             We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
>
>              
>
>             Best regards
>
>              
>
>             JJacques
>
>              
>
>              
>
>              
>
>              
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de 
>
>             lionel.morand@orange.com  Envoyé : mercredi 12 février 2014 15:46 À :
>
>             dime@ietf.org ; maria.cruz.bartolome@ericsson.com  Objet : Re: [Dime] 
>
>             [dime] #54: OC-Report-Type as mandatory AVP
>
>              
>
>             Hi Maria Cruz,
>
>              
>
>             I'm assuming that you mean "required" instead of "mandatory", right?
>
>              
>
>             So instead of:
>
>              
>
>             OC-OLR ::= < AVP Header: TBD2 >
>
>                        < OC-Sequence-Number >
>
>                        [ OC-Report-Type ]
>
>                        [ OC-Reduction-Percentage ]
>
>                        [ OC-Validity-Duration ]
>
>                      * [ AVP ]
>
>              
>
>             You would prefer:
>
>              
>
>             OC-OLR ::= < AVP Header: TBD2 >
>
>                        < OC-Sequence-Number >
>
>                        { OC-Report-Type }
>
>                        [ OC-Reduction-Percentage ]
>
>                        [ OC-Validity-Duration ]
>
>                      * [ AVP ]
>
>              
>
>             And I'm fine with this proposal.
>
>              
>
>             Cheers,
>
>              
>
>             Lionel
>
>              
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
>
>             tracker Envoyé : mercredi 12 février 2014 15:26 À :
>
>             maria.cruz.bartolome@ericsson.com  Cc : dime@ietf.org  Objet : [Dime] 
>
>             [dime] #54: OC-Report-Type as mandatory AVP
>
>              
>
>             #54: OC-Report-Type as mandatory AVP
>
>              
>
>             Now in chapter 4.6:
>
>              
>
>              The default value of the OC-Report-Type AVP is 0 (i.e. the host  
>
>             report).
>
>              
>
>             This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
>
>              
>
>             --
>
>             -----------------------------------------------+---------------------
>
>             -----------------------------------------------+---
>
>             -----------------------------------------------+---
>
>             Reporter:  maria.cruz.bartolome@ericsson.com   |      Owner:  MCruz
>
>               Type:  defect                             |  Bartolomé
>
>             Priority:  major                              |     Status:  new
>
>             Component:  draft-docdt-dime-ovli              |  Milestone:
>
>             Severity:  Active WG Document                 |    Version:  1.0
>
>                                                         |   Keywords:
>
>             -----------------------------------------------+---------------------
>
>             -----------------------------------------------+---
>
>             -----------------------------------------------+---
>
>              
>
>             Ticket URL:  
>
>             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
>
>              
>
>              
>
>         _______________________________________________
>
>         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.


--------------020805070209010706000401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I agree.  We need to find
      a way to stop circling around many of these issues or we will
      never get the document finished.

      

      In my opinion, focusing on trivial optimizations is not where we
      should be spending our time.  However, if people think it is that
      important to be able to not include the report-type AVP in some of
      the messages then by all means, let's make it optional, with a
      default of host, and let's move on to issues that matter.

      

      Steve

      

    
    
On 3/24/14 11:51 AM,
      lionel.morand@orange.com wrote:

    

    

      
      
      
      
      

        
IMHO it is a lot of fuse for something not so
            critical!

        
Session-id is for no use at all in a lot of
            Diameter applications and no one complains
          J

        
 

        
Here it is even simpler: there is a clear use
            of this AVP. This info (the explicit AVP or the default
            value) needs to be taken into account in the process of the
            received OLR and any compliant implementation needs to be
            able to understand the OLR-Report-Type.

        
So except "optimization", what is the rational
            not to make it required in the OLR?
            

        
 

        
Lionel

        
 

        

          

            
De :
                DiME [mailto:dime-bounces@ietf.org]
                De la part de Wiehe, Ulrich (NSN - DE/Munich)

                Envoyé : lundi 24 mars 2014 17:30

                À : ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES);
                Steve Donovan; Shishufeng (Susan); Jouni Korhonen

                Cc : dime@ietf.org

                Objet : Re: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        
+1

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext TROTTIN, JEAN-JACQUES
                (JEAN-JACQUES)

                Sent: Monday, March 24, 2014 2:52 PM

                To: Steve Donovan; Shishufeng (Susan); Jouni
                Korhonen

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        

          
Hi all
            

          
 

          
I am also in line with the agreement tendency as
              that OC-Report-Type is not required (so to keep the text
              as it is in the draft); I expressed this  preference a
              while ago.

          
 

          
 

          
Best regards

          
 

          
JJacques
            

          
 

          

            

                

              

            

              
De : DiME [dime-bounces@ietf.org] de la part de
                  Steve Donovan [srdonovan@usdonovans.com]

                  Date d'envoi : lundi 24 mars 2014 13:25

                  À : Shishufeng (Susan); Jouni Korhonen

                  Cc: dime@ietf.org

                  Objet : Re: [Dime] [dime] #54: OC-Report-Type
                  as mandatory AVP

            

            

              
Susan,

                  

                  We are in the middle of the discussion and have not
                  yet reached consensus.

                  

                  I agree with Jouni on making it explicit.  Either way,
                  we should try to make a decision quickly.

                  

                  Steve

              

                
On
                    3/23/14 10:59 PM, Shishufeng (Susan) wrote:

              

              

                
Hello Jouni,

                
 

                
I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 

                
 

                
Best Regards,

                
Susan

                
 

                
 

                
-----Original Message-----

                
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                
Sent: Saturday, March 22, 2014 10:38 AM

                
To: Steve Donovan

                
Cc: dime@ietf.org

                
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

                
 

                
 

                
Lets have it explicit then. Use '<' and '>' to make the position fixed.

                
 

                
- Jouni

                
 

                
On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

                
 

                

                  
I'm ok with either direction but generally lean toward being explicit.

                  
 

                  
Do we have other opinions?  

                  
 

                  
Steve

                  
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

                  

                    
Hello,

                    
I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.

                    
This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.

                    
If there is consensus on this, I will go with this.

                    
Best regards

                    
/MCruz

                    
 

                    
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

                    
Sent: martes, 18 de marzo de 2014 17:47

                    
To: dime@ietf.org

                    
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
All,

                    
 

                    
Do we have consensus that the OC-Report-Type AVP is required?

                    
 

                    
If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.

                    
 

                    
Jouni,

                    
 

                    
How do we indicate a fixed position for an AVP?  

                    
 

                    
I presonally don't see this as critical but we can add this requirement if there is consensus.

                    
 

                    
Regards,

                    
 

                    
Steve

                    
 

                    
On 2/28/14 10:27 AM, Jouni Korhonen wrote:

                    
 

                    
Hi,

                    
 

                    
How having the AVP could be less error prone if it has a default 

                    
value and the receiver knows exactly how to proceed when the AVP is 

                    
not present?

                    
 

                    
If a node does not include it when it should, the implementation is 

                    
broken. Wouldn't a broken node be able to put wrong report type into 

                    
the AVP even if the AVP is mandatory?

                    
 

                    
Anyway, if it is my statement keeping issue #54 still open, consider 

                    
it resolved from my side. I am OK making the OC-Report-Type AVP as 

                    
required/mandatory AVP. Should we also consider it having a fixed 

                    
position just after the OC-Sequence-Number AVP as well since it is 

                    
going to in every OC-OLR?

                    
 

                    
- Jouni

                    
 

                    
 

                    
 

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

                    
 

                    
 

                    
Hello all,

                    
 

                    
I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.

                    
 

                    
I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.

                    
 

                    
Best regards

                    
/MCruz

                    
 

                    
-----Original Message-----

                    
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

                    
Sent: viernes, 14 de febrero de 2014 23:13

                    
To: Jouni Korhonen

                    
Cc: dime@ietf.org

                    
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.

                    
 

                    
On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

                    
 

                    
 

                    
Agree that it is a small optimization, which I put there because at 

                    
the beginning there seemed to be a lot of worry on every extra AVP 

                    
;-)

                    
 

                    
I prefer having the AVP optional but with a default value just like 

                    
it is now. We have the same for the reduction percentage and the 

                    
validity time as well.

                    
 

                    
- Jouni

                    
 

                    
On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:

                    
 

                    
Hi Mcruz

                    
 

                    
The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 

                    
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.

                    
 

                    
Best regards

                    
 

                    
JJacques

                    
 

                    
 

                    
 

                    
 

                    
-----Message d'origine-----

                    
De : DiME [mailto:dime-bounces@ietf.org] De la part de 

                    
lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À :

                    
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 

                    
[dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
Hi Maria Cruz,

                    
 

                    
I'm assuming that you mean "required" instead of "mandatory", right?

                    
 

                    
So instead of:

                    
 

                    
OC-OLR ::= < AVP Header: TBD2 >

                    
           < OC-Sequence-Number >

                    
           [ OC-Report-Type ]

                    
           [ OC-Reduction-Percentage ]

                    
           [ OC-Validity-Duration ]

                    
         * [ AVP ]

                    
 

                    
You would prefer:

                    
 

                    
OC-OLR ::= < AVP Header: TBD2 >

                    
           < OC-Sequence-Number >

                    
           { OC-Report-Type }

                    
           [ OC-Reduction-Percentage ]

                    
           [ OC-Validity-Duration ]

                    
         * [ AVP ]

                    
 

                    
And I'm fine with this proposal.

                    
 

                    
Cheers,

                    
 

                    
Lionel

                    
 

                    
-----Message d'origine-----

                    
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 

                    
tracker Envoyé : mercredi 12 février 2014 15:26 À :

                    
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 

                    
[dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
#54: OC-Report-Type as mandatory AVP

                    
 

                    
Now in chapter 4.6:

                    
 

                    
 The default value of the OC-Report-Type AVP is 0 (i.e. the host  

                    
report).

                    
 

                    
This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.

                    
 

                    
--

                    
-----------------------------------------------+---------------------

                    
-----------------------------------------------+---

                    
-----------------------------------------------+---

                    
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

                    
  Type:  defect                             |  Bartolomé

                    
Priority:  major                              |     Status:  new

                    
Component:  draft-docdt-dime-ovli              |  Milestone:

                    
Severity:  Active WG Document                 |    Version:  1.0

                    
                                            |   Keywords:

                    
-----------------------------------------------+---------------------

                    
-----------------------------------------------+---

                    
-----------------------------------------------+---

                    
 

                    
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>

                    
dime <http://tools.ietf.org/wg/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

                    
 

                    
 

                  

                  
_______________________________________________

                  
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.


    

    

  


--------------020805070209010706000401--


From nobody Mon Mar 24 11:43:32 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 1879C1A028E for ; Mon, 24 Mar 2014 11:43:30 -0700 (PDT)
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 XACYAPaohoCg for ; Mon, 24 Mar 2014 11:43:27 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 288F91A029C for ; Mon, 24 Mar 2014 11:43:27 -0700 (PDT)
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 s2OIhONY005858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 24 Mar 2014 13:43:25 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2OIhOZ2026014 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Mar 2014 19:43:24 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 24 Mar 2014 19:43:24 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAAWgNwA==
Date: Mon, 24 Mar 2014 18:43:23 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/z8O7ZVdaOabpMvd5o6n03NK9aW8
Subject: Re: [Dime] issue #56 proposed 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, 24 Mar 2014 18:43:30 -0000

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given =
client=20

Your description of state is defined per Application and Abatement, so not =
including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There =
is the rate control algorithm that we will study, and here I am questioning=
 if we will not be driven to have a state per client, as the requested rate=
 will be rather specific to a client, some clients may have a small traffic=
  and others a large traffic, meaning to define a requested rate per client=
 somewhere.=20

So I may again repeat myself that the normal state would be per client in g=
eneral, which does not exclude to group all clients and consider a state co=
mmon to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but=
 it also concern other tickets.

Best regards=20

JJacques  =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
Envoy=E9=A0: lundi 24 mars 2014 19:08
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: lundi 24 mars 2014 18:24 =C0=A0: Wiehe, Ulrich (=
NSN - DE/Munich); dime@ietf.org Objet=A0: Re: [Dime] issue #56 proposed con=
clusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

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


From nobody Mon Mar 24 12:04: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 7C3C41A02BC for ; Mon, 24 Mar 2014 12:04:42 -0700 (PDT)
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 5qnMqarfP3hg for ; Mon, 24 Mar 2014 12:04:40 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id B335F1A02BD for ; Mon, 24 Mar 2014 12:04:40 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55739 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSAAo-0005K2-EN for dime@ietf.org; Mon, 24 Mar 2014 12:04:39 -0700
Message-ID: <533081C6.9080103@usdonovans.com>
Date: Mon, 24 Mar 2014 14:04:38 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------040903050204080807090205"
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/ySO4Z767ypgP20IuJoiTIuH1vBI
Subject: Re: [Dime] issue #56 proposed 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, 24 Mar 2014 19:04:42 -0000

This is a multi-part message in MIME format.
--------------040903050204080807090205
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

I have a few comments inline (towards the end of your proposal).

Steve

On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Dear all,
>
> I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
> I'm fine with not abbreviating "Overload Control State".
>
> I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
> Ulrich
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) 
> Sent: Thursday, March 20, 2014 2:08 PM
> To: dime@ietf.org
> Subject: issue #56 proposed conclusion
>
> #56: Bad Description of Overload Control State
>
>
> Dear all,
>
> I have received comments from Steve, MCruz and Jouni.
>
> I believe all comments are covered by the following proposed text:
>
>
>
>     5.5.1.  Overload Control State (OCS)
>
>     5.5.1.1   Overload Control States for reacting nodes
>
>     A reacting node 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 towards
>       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 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
>     following information:
>     - Sequence number (as reveived in OC-OLR)
>     - Time of expiry  (deviated from validity duration as received in OC-OLR
>       and time of reception)
>     - Selected Abatement Algorithm (as received in OC-Supported-Features)
>     - Algorithm specific input data (as received within OC-OLR, e.g.
>       Reduction Percentage for Loss)
>
>    
>     5.5.1.2   Overload Control States for reporting nodes
>
>     A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State. 
>
>     An Overload Control State may be identified by the pair of Application-Id
>     and supported Abatement Algorithm.
>
>     The Overload Control State for a given pair of Application and Abatement
>     Algorithm could include the information:
>     - Sequence number
>     - Validity Duration and Expiry Time
>     - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>     
>     5.5.1.3  Maintaining Overload Control States
>
>     Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>     an answer message of application app-id containing an Orig-Host of host-id and a
>     host-type OC-OLR AVP unless such host-type OCS already exists.
>
>     Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>     an answer message of application app-id containing an Orig-Realm of realm-id and a
>     realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>     Reacting nodes delete an OCS when it expires (i.e. when current time
>     minus reception time is greater than validity duration).
>
>     Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>     receiving an answer message of application app-id containing an Orig-Host of
>     host-id and a host-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>     receiving an answer message of application app-id containing an Orig-Realm of
>     realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>     request of application app-id containing an OC-Supported-Features AVP
>     indicating support of the Abatement Algorithm Alg (which the reporting
>     node selects) while being overloaded, unless such OCS already exists.
SRD> I would think the reporting node would create the OCS when it
determines it needs a reduction, independent when it receives requests
from various reacting nodes. 
>
>     Reporting nodes delete an OCS when it expires.
SRD> Or when it explicitly sends an OLR with validity duration of zero.
>
>     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>     need to modify the requested amount of application app-id traffic reduction.
>
> Ulrich
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------040903050204080807090205
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I have a few comments inline (towards the end of your proposal).

      

      Steve

      

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

    

    

      
Dear all,

I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) 
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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 towards
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OLR
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

   
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State. 

    An Overload Control State may be identified by the pair of Application-Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatement
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

    
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of realm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
    receiving an answer message of application app-id containing an Orig-Host of
    host-id and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Realm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    

    SRD> I would think the reporting node would create the OCS when
    it determines it needs a reduction, independent when it receives
    requests from various reacting nodes.  

    

      

    Reporting nodes delete an OCS when it expires.

    

    SRD> Or when it explicitly sends an OLR with validity duration of
    zero.

    

      

    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
    need to modify the requested amount of application app-id traffic reduction.

Ulrich


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



    

    

  


--------------040903050204080807090205--


From nobody Mon Mar 24 12:06: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 A78C91A02C1 for ; Mon, 24 Mar 2014 12:06:49 -0700 (PDT)
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 ous_maz7fK_J for ; Mon, 24 Mar 2014 12:06:47 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8B31A02C4 for ; Mon, 24 Mar 2014 12:06:47 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55743 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSACq-0000MO-MF for dime@ietf.org; Mon, 24 Mar 2014 12:06:45 -0700
Message-ID: <53308244.5010305@usdonovans.com>
Date: Mon, 24 Mar 2014 14:06:44 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------080803060406060203040009"
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/qo6NFv7brJ4IB8ua3llVenc_82I
Subject: Re: [Dime] issue #56 proposed 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, 24 Mar 2014 19:06:49 -0000

This is a multi-part message in MIME format.
--------------080803060406060203040009
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Acronym overlap is unavoidable.  If we add OCS in the abbreviations
section then we should be ok.

Steve

On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> Dear all,
>
> I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
> I'm fine with not abbreviating "Overload Control State".
>
> I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
> Ulrich
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich) 
> Sent: Thursday, March 20, 2014 2:08 PM
> To: dime@ietf.org
> Subject: issue #56 proposed conclusion
>
> #56: Bad Description of Overload Control State
>
>
> Dear all,
>
> I have received comments from Steve, MCruz and Jouni.
>
> I believe all comments are covered by the following proposed text:
>
>
>
>     5.5.1.  Overload Control State (OCS)
>
>     5.5.1.1   Overload Control States for reacting nodes
>
>     A reacting node 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 towards
>       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 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
>     following information:
>     - Sequence number (as reveived in OC-OLR)
>     - Time of expiry  (deviated from validity duration as received in OC-OLR
>       and time of reception)
>     - Selected Abatement Algorithm (as received in OC-Supported-Features)
>     - Algorithm specific input data (as received within OC-OLR, e.g.
>       Reduction Percentage for Loss)
>
>    
>     5.5.1.2   Overload Control States for reporting nodes
>
>     A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State. 
>
>     An Overload Control State may be identified by the pair of Application-Id
>     and supported Abatement Algorithm.
>
>     The Overload Control State for a given pair of Application and Abatement
>     Algorithm could include the information:
>     - Sequence number
>     - Validity Duration and Expiry Time
>     - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>     
>     5.5.1.3  Maintaining Overload Control States
>
>     Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>     an answer message of application app-id containing an Orig-Host of host-id and a
>     host-type OC-OLR AVP unless such host-type OCS already exists.
>
>     Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>     an answer message of application app-id containing an Orig-Realm of realm-id and a
>     realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>     Reacting nodes delete an OCS when it expires (i.e. when current time
>     minus reception time is greater than validity duration).
>
>     Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>     receiving an answer message of application app-id containing an Orig-Host of
>     host-id and a host-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>     receiving an answer message of application app-id containing an Orig-Realm of
>     realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>     request of application app-id containing an OC-Supported-Features AVP
>     indicating support of the Abatement Algorithm Alg (which the reporting
>     node selects) while being overloaded, unless such OCS already exists.
>
>     Reporting nodes delete an OCS when it expires.
>
>     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>     need to modify the requested amount of application app-id traffic reduction.
>
> Ulrich
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------080803060406060203040009
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Acronym overlap is unavoidable.  If we add OCS in the
      abbreviations section then we should be ok.

      

      Steve

      

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

    

    

      
Dear all,

I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) 
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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 towards
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OLR
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

   
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State. 

    An Overload Control State may be identified by the pair of Application-Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatement
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

    
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of realm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
    receiving an answer message of application app-id containing an Orig-Host of
    host-id and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Realm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
    need to modify the requested amount of application app-id traffic reduction.

Ulrich


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



    

    

  


--------------080803060406060203040009--


From nobody Mon Mar 24 12:07:39 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 72B0E1A02D1; Mon, 24 Mar 2014 12:07:33 -0700 (PDT)
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 3MRx3oQARKME; Mon, 24 Mar 2014 12:07:31 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6632E1A02C5; Mon, 24 Mar 2014 12:07:29 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:55744 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSADV-0001dT-TV; Mon, 24 Mar 2014 12:07:28 -0700
Message-ID: <5330826D.9080100@usdonovans.com>
Date: Mon, 24 Mar 2014 14:07:25 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Janet P Gunn 
References: <066.d4a6efb42ff3bd328e8b56b872c4e1a7@trac.tools.ietf.org> <081.d67cf98bf010626435cad725cb5095f0@trac.tools.ietf.org>  <5330362E.10005@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020608060803080600010207"
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/rN_vxjlz6LlqvWONUivXG0RbIf8
Cc: DiME , dime@ietf.org
Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-Supported-Features AVP in answer messages
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, 24 Mar 2014 19:07:33 -0000

This is a multi-part message in MIME format.
--------------020608060803080600010207
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I didn't get this into the current snapshot but have it marked to put
into the next -02 snapshot.

Steve

On 3/24/14 9:11 AM, Janet P Gunn wrote:
> Fine with me
>
> Janet
>
> "DiME"  wrote on 03/24/2014 09:42:06 AM:
>
> > From: Steve Donovan 
> > To: dime@ietf.org
> > Date: 03/24/2014 09:42 AM
> > Subject: Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> > Supported-Features AVP in answer messages
> > Sent by: "DiME" 
> >
> > Janet,
> >
> > Well, in the sense that the current overload condition caused the
> > current abatement request, the wording is mostly correct.  I agree
> > it can be made more clear.  It might be better if we changed the
> > word condition to report.
> >
> > Steve
>
> > On 3/21/14 4:10 PM, Janet P Gunn wrote:
> > Just a question.
> >
> > In the phrase " it
> >    applies the traffic abatement based on the commonly
> supported/selected
> >    algorithm with the reporting node and the current overload
> condition."
> >
> > Is it really the "current overload CONDITION", or the "current
> > abatement REQUESTED"?
> >
> > If the message is asking for a 10% reduction in traffic, that does
> > not actually identify the "current overload condition".
> >
> >
> > Janet
> >
> >
> >
> >
> > From:        "dime issue tracker" 
> > To:        srdonovan@usdonovans.com
> > Cc:        dime@ietf.org
> > Date:        03/21/2014 09:33 AM
> > Subject:        Re: [Dime] [dime] #30 (draft-docdt-dime-ovli): OC-
> > Supported-Features AVP in answer messages
> > Sent by:        "DiME" 
> >
> >
> >
> > #30: OC-Supported-Features AVP in answer messages
> >
> > Changes (by srdonovan@usdonovans.com):
> >
> > * status:  new => closed
> > * resolution:   => fixed
> >
> >
> > Comment:
> >
> > We reached the tentative agreement in the DIME meeting on the following:
> >
> > OC-Supported-Features handling:
> >
> > Agreed: OC-Supported-Features AVP MUST be included in all answer
> messages
> > (we had already agreed that it must be included in all request
> messages).
> > Agreed: Reacting node advertises all supported algorithms;
> > Agreed: Reporting node responds with the single algorithm it will be
> > using;
> > Agreed: Handling of other feature bits is defined in the extension
> drafts
> >
> > Based on this I believe we need the text changes outlined below.
> >
> > Let me know if I have missed any.
> >
> > If we agree on the text changes then we can close the issue and I'll
> > update the document accordingly.
> >
> > Regards,
> >
> > Steve
> >
> > -----
> >
> > Section 5.3.2, paragraph 1:
> >
> > Change:
> >
> > The answer message
> >    initiating endpoint MAY announce as many supported capabilities as it
> >    has (the announced set is a subject to local policy and
> >    configuration). However, at least one of the announced capabilities
> >    MUST be the same as received in the request message.
> >
> >
> > To:
> >
> > The reporting node MUST include the OC-Supported-Features AVP in all
> > response messages for transactions where the request message
> included the
> > OC-Supported-Features AVP.  The reporting node MUST announce support of
> > the single algorithm that the reporting node will request the reacting
> > node to use to mitigate overload instances.  The reporting node MUST NOT
> > change the selected algorithm during a period of time that it is in an
> > overload state and, as a result, is sending OC-OLR AVPs in answer
> > messages.
> >
> >     Note: There will always be at least one algorithm supported by both
> > the reacting and reporting nodes as all nodes that support DOIC must
> > support the loss algorithm defined in this document.
> >
> > The handling of feature bits in the OC-Feature-Vector AVP that are not
> > associated with overload abatement algorithms MUST be specified by the
> > extension that defines the feature.
> >
> > Paragraph 2:
> >
> > Change:
> >
> > The answer message initiating endpoint MUST NOT include any overload
> >    control solution defined AVPs into its answer messages if the request
> >    message initiating endpoint has not indicated support at the
> >    beginning of the created session (or transaction in a case of non-
> >    session state maintaining applications). The same also applies if
> >    none of the announced capabilities match between the two endpoints.
> >
> > To:
> >
> > The reporting node MUST NOT include the OC-Supported-Features AVP,
> OC-OLR
> > AVP or any other overload control AVPs defined in extension drafts in
> > response messages for transaction where the request message does not
> > include the OC-Supported-Features AVP.  Lack of the
> OC-Supported-Features
> > AVP in the request message indicates that the sender of the request
> > message does not support DOIC.
> >
> > Section 5.5.2, Paragraph 1:
> >
> > Change:
> >
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
> >    applies the traffic abatement based on the commonly supported
> >    algorithm with the reporting node and the current overload condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP or indirectly remembering the previously
> >    used traffic abatement algorithm with the given reporting node.
> >
> > To: (removing the last portion of the last sentence)
> >
> >    Once a reacting node receives an OC-OLR AVP from a reporting node, it
> >    applies the traffic abatement based on the commonly supported
> >    algorithm with the reporting node and the current overload condition.
> >    The reacting node learns the reporting node supported abatement
> >    algorithms directly from the received answer message containing the
> >    OC-Supported-Features AVP.
> >
> > -----
> >
> > +1, with a minor suggested edit:
> >
> > On Mar 17, 2014, at 2:03 PM, Steve Donovan 
> > wrote:
> >
> > > Change:
> > >    Once a reacting node receives an OC-OLR AVP from a reporting
> node, it
> > >    applies the traffic abatement based on the commonly supported
> > >    algorithm with the reporting node and the current overload
> condition.
> > >    The reacting node learns the reporting node supported abatement
> > >    algorithms directly from the received answer message containing the
> > >    OC-Supported-Features AVP or indirectly remembering the previously
> > >    used traffic abatement algorithm with the given reporting node.
> >
> > > To: (removing the last portion of the last sentence)
> > >    Once a reacting node receives an OC-OLR AVP from a reporting
> node, it
> > >    applies the traffic abatement based on the commonly supported
> >
> > s/"commonly supported"/selected
> >
> > "Commonly supported" is no longer descriptive. There may be several
> > commonly supported algorithm, but the reporting node selects just one.
> >
> > >    algorithm with the reporting node and the current overload
> condition.
> > >    The reacting node learns the reporting node supported abatement
> > >    algorithms directly from the received answer message containing the
> > >    OC-Supported-Features AVP.
> > >
> >
> > --
> > --------------------------------------+---------------------------
> > Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
> >     Type:  defect                    |      Status:  closed
> > Priority:  major                     |   Milestone:
> > Component:  draft-docdt-dime-ovli     |     Version:
> > Severity:  Active WG Document        |  Resolution:  fixed
> > Keywords:                            |
> > --------------------------------------+---------------------------
> >
> > Ticket URL: 
> > 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


--------------020608060803080600010207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I didn't get this into
      the current snapshot but have it marked to put into the next -02
      snapshot.

      

      Steve

      

    
    
On 3/24/14 9:11 AM, Janet P Gunn wrote:

    

    
Fine with me
      

      

      Janet
      

      

      "DiME" <dime-bounces@ietf.org> wrote
          on 03/24/2014 09:42:06 AM:

          

          > From: Steve Donovan <srdonovan@usdonovans.com>
      

      > To: dime@ietf.org
      

      > Date: 03/24/2014 09:42 AM
      

      > Subject: Re: [Dime] [dime] #30
          (draft-docdt-dime-ovli):
          OC-

          > Supported-Features AVP in answer messages
      

      > Sent by: "DiME"
          <dime-bounces@ietf.org>
      

      > 

          > Janet,

          > 

          > Well, in the sense that the current overload condition
          caused the
          

          > current abatement request, the wording is mostly correct.
           I
          agree 

          > it can be made more clear.  It might be better if we
          changed
          the 

          > word condition to report.

          > 

          > Steve

        
      

      > On 3/21/14 4:10 PM, Janet P Gunn wrote:
      

      > Just a question. 

          > 

          > In the phrase " it

          >    applies the traffic abatement based on the commonly
          supported/selected

          >    algorithm with the reporting node and the current
          overload
          condition." 

          > 

          > Is it really the "current overload CONDITION", or the
          "current
          

          > abatement REQUESTED"? 

          > 

          > If the message is asking for a 10% reduction in traffic,
          that does
          

          > not actually identify the "current overload condition".
          

          > 

          > 

          > Janet 

          > 

          > 

          > 

          > 

          > From:        "dime issue tracker"
          <trac+dime@grenache.tools.ietf.org>
          

          > To:        srdonovan@usdonovans.com 

          > Cc:        dime@ietf.org 

          > Date:        03/21/2014 09:33 AM 

          > Subject:        Re: [Dime] [dime] #30
          (draft-docdt-dime-ovli):
          OC-

          > Supported-Features AVP in answer messages 

          > Sent by:        "DiME" <dime-bounces@ietf.org>
          

          > 

          > 

          > 

          > #30: OC-Supported-Features AVP in answer messages

          > 

          > Changes (by srdonovan@usdonovans.com):

          > 

          > * status:  new => closed

          > * resolution:   => fixed

          > 

          > 

          > Comment:

          > 

          > We reached the tentative agreement in the DIME meeting on
          the following:

          > 

          > OC-Supported-Features handling:

          > 

          > Agreed: OC-Supported-Features AVP MUST be included in all
          answer messages

          > (we had already agreed that it must be included in all
          request messages).

          > Agreed: Reacting node advertises all supported
          algorithms;

          > Agreed: Reporting node responds with the single algorithm
          it will
          be

          > using;

          > Agreed: Handling of other feature bits is defined in the
          extension
          drafts

          > 

          > Based on this I believe we need the text changes outlined
          below.

          > 

          > Let me know if I have missed any.

          > 

          > If we agree on the text changes then we can close the
          issue and I'll

          > update the document accordingly.

          > 

          > Regards,

          > 

          > Steve

          > 

          > -----

          > 

          > Section 5.3.2, paragraph 1:

          > 

          > Change:

          > 

          > The answer message

          >    initiating endpoint MAY announce as many supported
          capabilities
          as it

          >    has (the announced set is a subject to local policy
          and

          >    configuration). However, at least one of the announced
          capabilities

          >    MUST be the same as received in the request message.

          > 

          > 

          > To:

          > 

          > The reporting node MUST include the OC-Supported-Features
          AVP in all

          > response messages for transactions where the request
          message included
          the

          > OC-Supported-Features AVP.  The reporting node MUST
          announce
          support of

          > the single algorithm that the reporting node will request
          the reacting

          > node to use to mitigate overload instances.  The
          reporting node
          MUST NOT

          > change the selected algorithm during a period of time
          that it is in
          an

          > overload state and, as a result, is sending OC-OLR AVPs
          in answer

          > messages.

          > 

          >     Note: There will always be at least one algorithm
          supported
          by both

          > the reacting and reporting nodes as all nodes that
          support DOIC must

          > support the loss algorithm defined in this document.

          > 

          > The handling of feature bits in the OC-Feature-Vector AVP
          that are
          not

          > associated with overload abatement algorithms MUST be
          specified by
          the

          > extension that defines the feature.

          > 

          > Paragraph 2:

          > 

          > Change:

          > 

          > The answer message initiating endpoint MUST NOT include
          any overload

          >    control solution defined AVPs into its answer messages
          if the request

          >    message initiating endpoint has not indicated support
          at the

          >    beginning of the created session (or transaction in a
          case of non-

          >    session state maintaining applications). The same also
          applies if

          >    none of the announced capabilities match between the
          two endpoints.

          > 

          > To:

          > 

          > The reporting node MUST NOT include the
          OC-Supported-Features AVP,
          OC-OLR

          > AVP or any other overload control AVPs defined in
          extension drafts
          in

          > response messages for transaction where the request
          message does not

          > include the OC-Supported-Features AVP.  Lack of the
          OC-Supported-Features

          > AVP in the request message indicates that the sender of
          the request

          > message does not support DOIC.

          > 

          > Section 5.5.2, Paragraph 1:

          > 

          > Change:

          > 

          >    Once a reacting node receives an OC-OLR AVP from a
          reporting
          node, it

          >    applies the traffic abatement based on the commonly
          supported

          >    algorithm with the reporting node and the current
          overload
          condition.

          >    The reacting node learns the reporting node supported
          abatement

          >    algorithms directly from the received answer message
          containing the

          >    OC-Supported-Features AVP or indirectly remembering
          the
          previously

          >    used traffic abatement algorithm with the given
          reporting
          node.

          > 

          > To: (removing the last portion of the last sentence)

          > 

          >    Once a reacting node receives an OC-OLR AVP from a
          reporting
          node, it

          >    applies the traffic abatement based on the commonly
          supported

          >    algorithm with the reporting node and the current
          overload
          condition.

          >    The reacting node learns the reporting node supported
          abatement

          >    algorithms directly from the received answer message
          containing the

          >    OC-Supported-Features AVP.

          > 

          > -----

          > 

          > +1, with a minor suggested edit:

          > 

          > On Mar 17, 2014, at 2:03 PM, Steve Donovan
          <srdonovan@usdonovans.com>

          > wrote:

          > 

          > > Change:

          > >    Once a reacting node receives an OC-OLR AVP from
          a reporting node, it

          > >    applies the traffic abatement based on the
          commonly
          supported

          > >    algorithm with the reporting node and the current
          overload condition.

          > >    The reacting node learns the reporting node
          supported
          abatement

          > >    algorithms directly from the received answer
          message
          containing the

          > >    OC-Supported-Features AVP or indirectly
          remembering
          the previously

          > >    used traffic abatement algorithm with the given
          reporting node.

          > 

          > > To: (removing the last portion of the last sentence)

          > >    Once a reacting node receives an OC-OLR AVP from
          a reporting node, it

          > >    applies the traffic abatement based on the
          commonly
          supported

          > 

          > s/"commonly supported"/selected

          > 

          > "Commonly supported" is no longer descriptive. There may
          be several

          > commonly supported algorithm, but the reporting node
          selects just
          one.

          > 

          > >    algorithm with the reporting node and the current
          overload condition.

          > >    The reacting node learns the reporting node
          supported
          abatement

          > >    algorithms directly from the received answer
          message
          containing the

          > >    OC-Supported-Features AVP.

          > >

          > 

          > -- 

          >
          --------------------------------------+---------------------------

          > Reporter:  lionel.morand@orange.com  |      
          Owner:  Ulrich Wiehe

          >     Type:  defect          
                   |      Status:  closed

          > Priority:  major              
                |   Milestone:

          > Component:  draft-docdt-dime-ovli     |    
          Version:

          > Severity:  Active WG Document        |  Resolution:
           fixed

          > Keywords:                
                     |

          >
          --------------------------------------+---------------------------

          > 

          > Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/30#comment:1>

          > dime <http://tools.ietf.org/wg/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

        
    

    

  


--------------020608060803080600010207--


From nobody Mon Mar 24 12:27:24 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 00CED1A02A8 for ; Mon, 24 Mar 2014 12:27:22 -0700 (PDT)
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 U5H5abCdsOY2 for ; Mon, 24 Mar 2014 12:27:14 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 6E24A1A02AF for ; Mon, 24 Mar 2014 12:27:13 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id EE31B3B40F6; Mon, 24 Mar 2014 20:27:11 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id D0785C8056; Mon, 24 Mar 2014 20:27:11 +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, 24 Mar 2014 20:27:11 +0100
From: 
To: Steve Donovan , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRRecscXj4P/C40GW6f1v1eWv+5rr96eAgAQ/IICAACZMgIAAKEkAgAAdh9A=
Date: Mon, 24 Mar 2014 19:27:10 +0000
Message-ID: <14717_1395689231_5330870F_14717_15599_1_6B7134B31289DC4FAF731D844122B36E51905A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com>
In-Reply-To: <53307B7C.4000200@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.6]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51905APEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.24.134215
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/GdQpwgRyURbdfQzwFa8Hn04oOnI
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 24 Mar 2014 19:27:22 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51905APEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Let say that we have a working assumption on this one and please move on.

There is no need to reach a 100% agreement on this one to be able to publis=
h the version 02 and to have something consistent.

So please Ulrich, don't forget your concern but please accept that the curr=
ent working assumption. And let see if the concern is still valid afterward.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 mars 2014 19:38
=C0 : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve






_______________________________________________

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_6B7134B31289DC4FAF731D844122B36E51905APEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Let say th=
at we have a working assumption on this one and please move on.<=
/span>


 =
;


There is n=
o need to reach a 100% agreement on this one to be able to publish the vers=
ion 02 and to have something consistent.


 =
;


So please =
Ulrich, don't forget your concern but please accept that the current workin=
g assumption. And let see if the concern is still valid afterward.


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 mars 2014 19:38

=C0 : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


Ok, we are going back=
wards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I do not agree.


 <=
/p>

We should =
still have the option



3) support=
 report type 0 (this is called host report) and support of report type 1 (t=
his has been called relam report but people argued it should
 better be called realm routed request report).


 


Whether or=
 not we need in addition to type 0 and type 1 (or as a replacement of type =
1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There are =
a lot of open questions  with regard to #55 and I have not seen a conc=
lusion.


Where I ha=
ve seen a conclusion is issue #34 and that is inline with option 3).=



 


Unless we =
conclude on #55, or decide to re-open #34, option 3) is what should go in t=
he -02 draft.


 


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulrich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan wrote:<=
/p>





Ulrich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I don̵=
7;t know what happend in London.


Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 

















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.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_6B7134B31289DC4FAF731D844122B36E51905APEXCVZYM13corpora_--


From nobody Mon Mar 24 13:17:28 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 C77AA1A02AC for ; Mon, 24 Mar 2014 13:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 mVzxF10hnAIe for ; Mon, 24 Mar 2014 13:17:23 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 74D261A0298 for ; Mon, 24 Mar 2014 13:17:23 -0700 (PDT)
Received: from localhost ([127.0.0.1]:38465 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WSBJ4-0002Pw-Tp; Mon, 24 Mar 2014 21:17:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Mar 2014 20:17:14 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/44#comment:1
Message-ID: <072.6892b07263eb158352dabe97ef8b9ed4@trac.tools.ietf.org>
References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org>
X-Trac-Ticket-ID: 44
In-Reply-To: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/B0I0OKuPZILVLDGx51JWozHvQUk
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #44 (draft-docdt-dime-ovli): Incorrect sequence number behavior
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, 24 Mar 2014 20:17:26 -0000

#44: Incorrect sequence number behavior

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Change the last sentence of section 4.3, paragraph 3 to “The reacting node
 SHOULD discard an OC-OLR AVP with a sequence number that is less than or
 equal to the previously received sequence number.â€

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  trivial      |   Milestone:
Component:  draft-       |     Version:
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Mon Mar 24 13:39: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 D516E1A02EF for ; Mon, 24 Mar 2014 13:39:09 -0700 (PDT)
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 gNzRN-04El9z for ; Mon, 24 Mar 2014 13:39:07 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8FD1A02F2 for ; Mon, 24 Mar 2014 13:38:52 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56098 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSBdp-0006sT-J2 for dime@ietf.org; Mon, 24 Mar 2014 13:38:51 -0700
Message-ID: <533097D1.3090803@usdonovans.com>
Date: Mon, 24 Mar 2014 15:38:41 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com>
In-Reply-To: <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com>
Content-Type: multipart/alternative; boundary="------------060204060200000607090105"
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/urcTC765-pm4qjHUzaCUEwoSBGw
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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, 24 Mar 2014 20:39:10 -0000

This is a multi-part message in MIME format.
--------------060204060200000607090105
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Here's some proposed wording that will hopefully let us close this issue:

Regards,

Steve

-----

Section 4.5., paragraph 3 -

Current -02 wording:

As a general guidance for implementations it is RECOMMENDED never to
   let any overload report to timeout.  Following to this rule, an
   overload endpoint should explicitly signal the end of overload
   condition and not rely on the expiration of the validity time of the
   overload report in the reacting node.  This is achieved by sending an
   updated overload report (meaning it must contain a new sequence
   number) with the OC-Validity-Duration AVP value set to zero ("0").

Proposed wording:

   A reporting node SHOULD explicitly signal the end of overload
   condition in a timely manner.  This is achieved by sending an
   updated overload report (meaning the OLR contains a new sequence
   number) with the OC-Validity-Duration AVP value set to zero ("0").

  A reacting node MUST invalidate and remove an overload report that
  expires without an explicit overload report containing an
OC-Validity-Duration
  value set to zero ("0").


On 2/11/14 4:31 PM, Jouni Korhonen wrote:
> Fine with me.
>
> - Jouni
>
> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome  wrote:
>
>> Ben, Nirav,
>>
>> I follow same argumentation.
>> Regards
>> /MCruz
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
>> Sent: martes, 11 de febrero de 2014 11:23
>> To: Ben Campbell; Jouni Korhonen
>> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>>
>> Ben,
>>
>> I resonate with your thinking below.
>>
>> Regards,
>> Nirav.
>>
>> -----Original Message-----
>> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>> Sent: Monday, February 10, 2014 9:54 PM
>> To: Jouni Korhonen
>> Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>>
>>
>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen  wrote:
>>
>>> My reasoning for explicit termination was that knowing the 
>>> implementation folks they will let overload conditions expire unless advised otherwise.
>>> And having unnecessary stuff hanging around waiting for a cleanup is 
>>> not a good thing in general. But I am open here for other options..
>>>
>> I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report. 
>>
>> And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.
>>
>> _______________________________________________
>> 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
>


--------------060204060200000607090105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Here's some proposed wording
      that will hopefully let us close this issue:

      

      Regards,

      

      Steve

      

      -----

      

      Section 4.5., paragraph 3 - 

      

      Current -02 wording:

      

      As a general guidance for implementations it is RECOMMENDED never
      to

         let any overload report to timeout.  Following to this rule, an

         overload endpoint should explicitly signal the end of overload

         condition and not rely on the expiration of the validity time
      of the

         overload report in the reacting node.  This is achieved by
      sending an

         updated overload report (meaning it must contain a new sequence

         number) with the OC-Validity-Duration AVP value set to zero
      ("0").

      

      Proposed wording:

      

         A reporting node SHOULD explicitly signal the end of overload

         condition in a timely manner.  This is achieved by sending an

         updated overload report (meaning the OLR contains a new
      sequence

         number) with the OC-Validity-Duration AVP value set to zero
      ("0").

      

        A reacting node MUST invalidate and remove an overload report
      that

        expires without an explicit overload report containing an OC-Validity-Duration

        value set to zero ("0").

      

      

    
    
On 2/11/14 4:31 PM, Jouni Korhonen
      wrote:

    

    

      
Fine with me.

- Jouni

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



      

        
Ben, Nirav,

I follow same argumentation.
Regards
/MCruz

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Nirav Salot (nsalot)
Sent: martes, 11 de febrero de 2014 11:23
To: Ben Campbell; Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire

Ben,

I resonate with your thinking below.

Regards,
Nirav.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, February 10, 2014 9:54 PM
To: Jouni Korhonen
Cc: dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire


On Feb 10, 2014, at 5:16 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:



        

          
My reasoning for explicit termination was that knowing the 
implementation folks they will let overload conditions expire unless advised otherwise.
And having unnecessary stuff hanging around waiting for a cleanup is 
not a good thing in general. But I am open here for other options..



        

        
I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report. 

And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.

_______________________________________________
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



    

    

  


--------------060204060200000607090105--


From nobody Mon Mar 24 13:47:28 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 233951A02AC for ; Mon, 24 Mar 2014 13:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ndd35FjwiY9I for ; Mon, 24 Mar 2014 13:47:20 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CB3391A0271 for ; Mon, 24 Mar 2014 13:47:19 -0700 (PDT)
Received: from localhost ([127.0.0.1]:40168 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WSBm5-0001HQ-Nn; Mon, 24 Mar 2014 21:47:13 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Mar 2014 20:47:13 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/42#comment:1
Message-ID: <072.d58d2af6e8679bd82a596549dafb6361@trac.tools.ietf.org>
References: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org>
X-Trac-Ticket-ID: 42
In-Reply-To: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hI2BdePdJVqCuBdCONPF4HrOi8A
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #42 (draft-docdt-dime-ovli): IETF defined example of a stateless application.
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, 24 Mar 2014 20:47:22 -0000

#42: IETF defined example of a stateless application.


Comment (by srdonovan@usdonovans.com):

 Added RFC4006 as an IETF defined session-based application.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  trivial      |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Mon Mar 24 13:47:40 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 915861A02CF for ; Mon, 24 Mar 2014 13:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 QSpOrD5aGiZ3 for ; Mon, 24 Mar 2014 13:47:29 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4A71A02B2 for ; Mon, 24 Mar 2014 13:47:29 -0700 (PDT)
Received: from localhost ([127.0.0.1]:40191 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WSBmF-00041C-9c; Mon, 24 Mar 2014 21:47:23 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Mar 2014 20:47:23 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/42#comment:2
Message-ID: <072.9012a87171bc4be9046f143cb35e78ad@trac.tools.ietf.org>
References: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org>
X-Trac-Ticket-ID: 42
In-Reply-To: <057.ff314df275dab29348f2c0fdfc761219@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/y1_lccMxaoEympmyzgrMjMHg_mg
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #42 (draft-docdt-dime-ovli): IETF defined example of a stateless application.
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, 24 Mar 2014 20:47:33 -0000

#42: IETF defined example of a stateless application.

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  trivial      |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Mon Mar 24 14:06:39 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 965331A02DC for ; Mon, 24 Mar 2014 14:06:30 -0700 (PDT)
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 qmBTRra4iAoL for ; Mon, 24 Mar 2014 14:06:29 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 560261A02CC for ; Mon, 24 Mar 2014 14:06:29 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:56237 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSC4d-0000l3-OD for dime@ietf.org; Mon, 24 Mar 2014 14:06:28 -0700
Message-ID: <53309E4F.7050509@usdonovans.com>
Date: Mon, 24 Mar 2014 16:06:23 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------000902040108050803040109"
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/zdaZRzh-M8akCv9IxC9INtTRenI
Subject: Re: [Dime] Issue#31 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, 24 Mar 2014 21:06:30 -0000

This is a multi-part message in MIME format.
--------------000902040108050803040109
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

Can someone boil down the various proposed wording for this issue into
what we want to have in the -02 draft.

Thanks,

Steve
On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that
> survived a throttling
>  
> Dear all,
>  
> I did not receive much support for the proposal to define an
> OC-Ongoing-Throttling-Info AVP in request messages that survived a
> throttlting.
>  
> However, we seem to agree on some principles:
>  
> Missing OLR in answer means "no change"; it does not mean "no
> overload/no throttling requested"
>  
> Reporting nodes SHOULD include OLR in every answer that it sends in
> response to a request message which indicated OLR_DEFAULT_ALGO support
> unless the reporting node has very good reasons not to do so. Exact
> wording is not yet agreed.
>  
> Ulrich
>  
>  
>  
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------000902040108050803040109
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    All,

      

      Can someone boil down the various proposed wording for this issue
      into what we want to have in the -02 draft.

      

      Thanks,

      

      Steve

    
    
On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      
      
          
#31: Sending OC-Ongoing-Throttling-Info AVP in request
            messages that survived a throttling

          
 

          
Dear all,

          
 

          
I did not receive much support for the proposal to define
            an OC-Ongoing-Throttling-Info AVP in request messages that
            survived a throttlting.

          
 

          
However, we seem to agree on some principles:

          
 

          
Missing OLR in answer means “no change”; it does not mean
            “no overload/no throttling requested”

          
 

          
Reporting nodes SHOULD include OLR in every answer that
            it sends in response to a request message which indicated OLR_DEFAULT_ALGO
              support unless the reporting node has very
            good reasons not to do so. Exact wording is not yet agreed.
          

          
 

          
Ulrich

          
 

          
 

          
 

        
      

      

      

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


    

    

  


--------------000902040108050803040109--


From nobody Mon Mar 24 14:09:44 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 C18E01A02B6 for ; Mon, 24 Mar 2014 14:09:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 FPbgviuP_mHt for ; Mon, 24 Mar 2014 14:09:39 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E204F1A028B for ; Mon, 24 Mar 2014 14:09:38 -0700 (PDT)
Received: from localhost ([127.0.0.1]:41083 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WSC7g-0007Ut-Bf; Mon, 24 Mar 2014 22:09:32 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Mon, 24 Mar 2014 21:09:32 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/38#comment:1
Message-ID: <072.c1447e75b51feea327f1a5a8f7c4f60c@trac.tools.ietf.org>
References: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org>
X-Trac-Ticket-ID: 38
In-Reply-To: <057.23609e95665c9eb1e8580a31702a64b0@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vXJ1uU1IarN89sp7N-Vh-CWrrD4
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #38 (draft-docdt-dime-ovli): Server Farm Definition Issue
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, 24 Mar 2014 21:09:41 -0000

#38: Server Farm Definition Issue

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This issue went away with the changes resulting from issue #24.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Tue Mar 25 00:00:30 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 200AA1A0370 for ; Tue, 25 Mar 2014 00:00:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 fzQyMwtu3UHF for ; Tue, 25 Mar 2014 00:00:20 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 589D01A0359 for ; Tue, 25 Mar 2014 00:00:19 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCK15176; Tue, 25 Mar 2014 07:00:17 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 06:59:47 +0000
Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 07:00:16 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 25 Mar 2014 15:00:07 +0800
From: "Shishufeng (Susan)" 
To: Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIA==
Date: Tue, 25 Mar 2014 07:00:06 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com>
In-Reply-To: <53302446.9080700@usdonovans.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3DE93SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/20cIcYqppjbDJ5dQ4L4rMoKF65U
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 25 Mar 2014 07:00:26 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3DE93SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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








--_000_26C84DFD55BC3040A45BF70926E55F2587C3DE93SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve,<=
o:p>


 =
;


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 Steve Donovan [mail=
to:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and r=
eached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


 


Lets have it explicit then. Use '<' and '>'=
 to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> =
wrote:


 




I'm ok with either direction but generally lean t=
oward being explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
o:p>




Hello,


I think the agreement tendency is the contrary: O=
C-Report-Type is not required, while default value is Host. i.e. it will re=
main as it is now in the draft.


This may be of some advantage for some applicatio=
ns that may only use Host, as long as they may never generate Realm reports=
.


If there is consensus on this, I will go with thi=
s.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan=



Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


All,


 


Do we have consensus that the OC-Report-Type AVP =
is required?


 


If so then one change would be as indicated in th=
e syntax definition proposed by Lionel.  We would also remove wording =
on the default value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?&n=
bsp; 


 


I presonally don't see this as critical but we ca=
n add this requirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if i=
t has a default 


value and the receiver knows exactly how to proce=
ed when the AVP is 


not present?


 


If a node does not include it when it should, the=
 implementation is 


broken. Wouldn't a broken node be able to put wro=
ng report type into 


the AVP even if the AVP is mandatory?<=
/span>


 


Anyway, if it is my statement keeping issue #54 s=
till open, consider 


it resolved from my side. I am OK making the OC-R=
eport-Type AVP as 


required/mandatory AVP. Should we also consider i=
t having a fixed 


position just after the OC-Sequence-Number AVP as=
 well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolom=
e <maria.cruz.barto=
lome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend t=
o prefer to make it mandatory, since I think this is less error-prone, sinc=
e the only node that knows the requested Report-Type is the reporting, if f=
or any reason a reporting is omitting it (since it is optional), it will be=
 always interpreted as HOST, but this type may be wrong.<=
/pre>

 


I think DEFAULT values should never be error-pron=
e, but used in "general cases", as a simplification, like e.g. a =
default for the Validity-Duration. Default Validity-Duration will never be =
an "error", it could be not the best value (compared with another=
 value perfectly tuned to reporting node overload situation) but never the =
use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell<=
/span>


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


I actually prefer making it mandatory. The cost o=
f adding it is trivial--even more so for a reporting node that only support=
s the default. The value of having it is less opportunity for interop error=
s.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro=
te:


 


 


Agree that it is a small optimization, which I pu=
t there because at 


the beginning there seemed to be a lot of worry o=
n every extra AVP 


;-)


 


I prefer having the AVP optional but with a defau=
lt value just like 


it is now. We have the same for the reduction per=
centage and the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not p=
resent the OLR is of type Host, which was fine for me and keeps my preferen=
ce. 


We may have  deployments where Realm OLR is =
not used, or where statistically the HOST type is the most frequent, so to =
have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I =
agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lione=
l.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolom=
e@ericsson.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" i=
nstead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  [ OC-Report-Type ]


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  { OC-Report-Type }


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:=
26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP=
 is 0 (i.e. the host  


report).


 


This AVP is always required, right? Then, I think=
 it is more precise that  we define this AVP as mandatory.<=
/span>


 


--


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


Reporter:  maria.cruz.bartolome@ericsson.com  | &nbs=
p;    Owner:  MCruz


  Type:  defect    =
             &n=
bsp;           |&nbs=
p; Bartolom=E9


Priority:  major    &nbs=
p;            &=
nbsp;            |&n=
bsp;    Status:  new


Component:  draft-docdt-dime-ovli  =
;            | =
 Milestone:


Severity:  Active WG Document  &nb=
sp;            =
  |    Version:  1.0


        &=
nbsp;           &nbs=
p;             =
          |   K=
eywords:


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket=
/54>


dime &=
lt;http://tools.ietf.org/wg/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 et=
re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me=
ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law; they shoul=
d 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 fo=
r 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

 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


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



 


 


 




 






--_000_26C84DFD55BC3040A45BF70926E55F2587C3DE93SZXEMA512MBXchi_--


From nobody Tue Mar 25 00:05:31 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 5296D1A0383 for ; Tue, 25 Mar 2014 00:05:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RhItG6Y-xlSd for ; Tue, 25 Mar 2014 00:05:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 482A71A037F for ; Tue, 25 Mar 2014 00:05:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX39247; Tue, 25 Mar 2014 07:05:17 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 07:04:44 +0000
Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 07:05:13 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 25 Mar 2014 15:05:02 +0800
From: "Shishufeng (Susan)" 
To: "lionel.morand@orange.com" , "Wiehe, Ulrich (NSN - DE/Munich)" , "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAABf6gIAALFyAgAAFzQCAAXNXgA==
Date: Tue, 25 Mar 2014 07:05:01 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3DEB6@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com>, <53302446.9080700@usdonovans.com>  <5BCBA1FC2B7F0B4C9D935572D9000668151D1E62@DEMUMBX014.nsn-intra.net> <8734_1395679863_53306277_8734_13050_1_6B7134B31289DC4FAF731D844122B36E518BC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <8734_1395679863_53306277_8734_13050_1_6B7134B31289DC4FAF731D844122B36E518BC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3DEB6SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xZHjZG-AAmCtsM2e2uYbl6Lim74
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 25 Mar 2014 07:05:28 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3DEB6SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Lionel,

That's because we have no chance to change the situation with Session-id, w=
hich is already there for many years. This does not mean it is correct. :)

As I clarified many times, OLR-Report-Type is not useful for some Diameter =
applications or deployment, this could justify its optionality.

If everyone can live with the texts as they are, maybe we can close the dis=
cussion on it and move on.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Tuesday, March 25, 2014 12:51 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext TROTTIN, JEAN-JACQUES (JEAN-JACQUE=
S); Steve Donovan; Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

IMHO it is a lot of fuse for something not so critical!
Session-id is for no use at all in a lot of Diameter applications and no on=
e complains :)

Here it is even simpler: there is a clear use of this AVP. This info (the e=
xplicit AVP or the default value) needs to be taken into account in the pro=
cess of the received OLR and any compliant implementation needs to be able =
to understand the OLR-Report-Type.
So except "optimization", what is the rational not to make it required in t=
he OLR?

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : lundi 24 mars 2014 17:30
=C0 : ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Steve Donovan; Shishufeng (=
Susan); Jouni Korhonen
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

+1

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 2:52 PM
To: Steve Donovan; Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi all

I am also in line with the agreement tendency as that OC-Report-Type is not=
 required (so to keep the text as it is in the draft); I expressed this  pr=
eference a while ago.


Best regards

JJacques



________________________________
De : DiME [dime-bounces@ietf.org] de la part de Steve Donovan [srdonovan@us=
donovans.com]
Date d'envoi : lundi 24 mars 2014 13:25
=C0 : Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

--_000_26C84DFD55BC3040A45BF70926E55F2587C3DEB6SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Lion=
el,


 =
;


That’=
;s because we have no chance to change the situation with Session-id, which=
 is already there for many years. This does not mean it is correct.
J


 =
;


As I clari=
fied many times, OLR-Report-Type is not useful for some Diameter applicatio=
ns or deployment, this could justify its optionality.


 =
;


If everyon=
e can live with the texts as they are, maybe we can close the discussion on=
 it and move on.


 =
;


Best Regar=
ds,


Susan=



 =
;






From: lionel.morand@orange.com [mailto:lionel.morand@orange=
.com]


Sent: Tuesday, March 25, 2014 12:51 AM

To: Wiehe, Ulrich (NSN - DE/Munich); ext TROTTIN, JEAN-JACQUES (JEAN=
-JACQUES); Steve Donovan; Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


IMHO it is=
 a lot of fuse for something not so critical!


Session-id=
 is for no use at all in a lot of Diameter applications and no one complain=
s
J


 =
;


Here it is=
 even simpler: there is a clear use of this AVP. This info (the explicit AV=
P or the default value) needs to be taken into account in
 the process of the received OLR and any compliant implementation needs to =
be able to understand the OLR-Report-Type.


So except =
"optimization", what is the rational not to make it required in t=
he OLR?



 =
;


Lionel


 =
;






De : DiME [mailto:d=
ime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : lundi 24 mars 2014 17:30

=C0 : ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); Steve Donovan; =
Shishufeng (Susan); Jouni Korhonen

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


+1=



 =







From: DiME [mailto=
:dime-bounces@ietf.org]
On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: Monday, March 24, 2014 2:52 PM

To: Steve Donovan; Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 




Hi all



 =



I am also in =
line with the agreement tendency as that OC-Report-Type is not required (so=
 to keep the text as it is in the draft); I expressed this
  preference a while ago.

 


 =



Best regards<=
/span>


 =



JJacques



 =













De : DiME =
[dime-bounces@ietf.org]
 de la part de Steve Donovan [srdonovan@usdonovans.com]

Date d'envoi : lundi 24 mars 2014 13:25

=C0 : Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 1=
0:59 PM, Shishufeng (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discu=
ssion on this and reached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan=



 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gm=
ail.com] 


Sent: Saturday, March 22, 2014=
 10:38 AM


To: Steve Donovan


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #54=
: OC-Report-Type as mandatory AVP


 


 


Lets have it explicit then. Us=
e '<' and '>' to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, S=
teve Donovan =
<srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction b=
ut generally lean toward being explicit.


 


Do we have other opinions?&nbs=
p; 


 


Steve=



On 3/18/14 12:16 PM, Maria Cru=
z Bartolome wrote:




Hello,


I think the agreement tendency=
 is the contrary: OC-Report-Type is not required, while default value is Ho=
st. i.e. it will remain as it is now in the draft.=



This may be of some advantage =
for some applications that may only use Host, as long as they may never gen=
erate Realm reports.


If there is consensus on this,=
 I will go with this.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] =
On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2=
014 17:47


To: dime@ietf.org


Subject: Re: [Dime] [dime] #54=
: OC-Report-Type as mandatory AVP


 


All,<=
o:p>


 


Do we have consensus that the =
OC-Report-Type AVP is required?<=
/pre>

 


If so then one change would be=
 as indicated in the syntax definition proposed by Lionel.  We would a=
lso remove wording on the default value.


 


Jouni,


 


How do we indicate a fixed pos=
ition for an AVP?  


 


I presonally don't see this as=
 critical but we can add this requirement if there is consensus.


 


Regards,


 


Steve=



 


On 2/28/14 10:27 AM, Jouni Kor=
honen wrote:


 


Hi,


 


How having the AVP could be le=
ss error prone if it has a default 


value and the receiver knows e=
xactly how to proceed when the AVP is <=
/span>


not present?


 


If a node does not include it =
when it should, the implementation is <=
/span>


broken. Wouldn't a broken node=
 be able to put wrong report type into =



the AVP even if the AVP is man=
datory?


 


Anyway, if it is my statement =
keeping issue #54 still open, consider =



it resolved from my side. I am=
 OK making the OC-Report-Type AVP as 


required/mandatory AVP. Should=
 we also consider it having a fixed 


position just after the OC-Seq=
uence-Number AVP as well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, =
Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view,=
 but I still tend to prefer to make it mandatory, since I think this is les=
s error-prone, since the only node that knows the requested Report-Type is =
the reporting, if for any reason a reporting is omitting it (since it is op=
tional), it will be always interpreted as HOST, but this type may be wrong.=



 


I think DEFAULT values should =
never be error-prone, but used in "general cases", as a simplific=
ation, like e.g. a default for the Validity-Duration. Default Validity-Dura=
tion will never be an "error", it could be not the best value (co=
mpared with another value perfectly tuned to reporting node overload situat=
ion) but never the use of a Default value should lead to an erroneous behav=
ior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] =
On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero d=
e 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.org


Subject: Re: [Dime] [dime] #54=
: OC-Report-Type as mandatory AVP


 


I actually prefer making it ma=
ndatory. The cost of adding it is trivial--even more so for a reporting nod=
e that only supports the default. The value of having it is less opportunit=
y for interop errors.


 


On Feb 13, 2014, at 6:05 AM, J=
ouni Korhonen &=
lt;jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optim=
ization, which I put there because at <=
/span>


the beginning there seemed to =
be a lot of worry on every extra AVP 


;-)


 


I prefer having the AVP option=
al but with a default value just like <=
/span>


it is now. We have the same fo=
r the reduction percentage and the 


validity time as well.<=
span lang=3D"DE">


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, =
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin=
@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indica=
tes that when not present the OLR is of type Host, which was fine for me an=
d keeps my preference. 


We may have  deployments =
where Realm OLR is not used, or where statistically the HOST type is the mo=
st frequent, so to have the grouped OLR-AVP containing a minimum of AVPs mi=
nimizes parsing. I agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] D=
e la part de 


lionel.morand@orange.com Envoy=E9 : mer=
credi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson.com O=
bjet : Re: [Dime] 


[dime] #54: OC-Report-Type as =
mandatory AVP


 


Hi Maria Cruz,


 


I'm assuming that you mean &qu=
ot;required" instead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: =
TBD2 >


     =
      < OC-Sequence-Number >


     =
      [ OC-Report-Type ]<=
o:p>


     =
      [ OC-Reduction-Percentage ]


     =
      [ OC-Validity-Duration ]


     =
    * [ AVP ]

 


You would prefer:


 


OC-OLR ::=3D < AVP Header: =
TBD2 >


     =
      < OC-Sequence-Number >


     =
      { OC-Report-Type }<=
o:p>


     =
      [ OC-Reduction-Percentage ]


     =
      [ OC-Validity-Duration ]


     =
    * [ AVP ]

 


And I'm fine with this proposa=
l.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] D=
e la part de dime issue 


tracker Envoy=E9 : mercredi 12=
 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com<=
/a> Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as =
mandatory AVP


 


#54: OC-Report-Type as mandato=
ry AVP


 


Now in chapter 4.6:


 


 The default value of the=
 OC-Report-Type AVP is 0 (i.e. the host  


report).


 


This AVP is always required, r=
ight? Then, I think it is more precise that  we define this AVP as man=
datory.


 


--


------------------------------=
-----------------+---------------------


------------------------------=
-----------------+---


------------------------------=
-----------------+---


Reporter:  maria.cruz.bartolo=
me@ericsson.com  |      Owner:  MCru=
z


  Type:  defect =
;            &n=
bsp;            =
;   |  Bartolom=E9


Priority:  major &nb=
sp;            =
            &nb=
sp;   |     Status:  new


Component:  draft-docdt-d=
ime-ovli           &=
nbsp;  |  Milestone:

Severity:  Active WG Docu=
ment            =
;     |    Version:  1.0


     =
            &nb=
sp;            =
            &nb=
sp; |   Keywords:

------------------------------=
-----------------+---------------------


------------------------------=
-----------------+---


------------------------------=
-----------------+---


 


Ticket URL: <http://tr=
ac.tools.ietf.org/wg/dime/trac/ticket/54>


dime <http://tools.ietf.org/wg/dime/><=
/a>


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_______________________________________=



______________________________=
______________________


 


Ce message et ses pieces joint=
es peuvent contenir des informations confidentielles ou privilegiees et ne =
doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si v=
ous 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 messa=
ge a ete altere, deforme ou falsifie. Merci.<=
/o:p>


 


This message and its attachmen=
ts may contain confidential or privileged information that may be protected=
 by law; they should not be distributed, used or copied without authorisati=
on.


If you have received this emai=
l in error, please notify the sender and delete this message and its attach=
ments.


As emails may be altered, Oran=
ge is not liable for messages that have been modified, changed or falsified=
.


Thank you.


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime


 


 




______________________________=
_________________


DiME mailing list


DiME@ietf.org<=
/span>


https://www.ietf.org/mailman/lis=
tinfo/dime






 








____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3DEB6SZXEMA512MBXchi_--


From nobody Tue Mar 25 00:48: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 A04011A0363 for ; Tue, 25 Mar 2014 00:48:20 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 XSadcPcBX1mu for ; Tue, 25 Mar 2014 00:48:14 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 715051A0134 for ; Tue, 25 Mar 2014 00:48:13 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2P7mBwC010520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 07:48:11 GMT
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 s2P7mBrq023774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 08:48:11 +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; Tue, 25 Mar 2014 08:48:11 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 08:48:11 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext lionel.morand@orange.com" , Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRUlVL8WBONWpVkShCkGbZ2B6UJrwNmSAgAAvmYCAAB77AIAADcsAgADX7uA=
Date: Tue, 25 Mar 2014 07:48:10 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D1FE6@DEMUMBX014.nsn-intra.net>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <14717_1395689231_5330870F_14717_15599_1_6B7134B31289DC4FAF731D844122B36E51905A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <14717_1395689231_5330870F_14717_15599_1_6B7134B31289DC4FAF731D844122B36E51905A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1FE6DEMUMBX014nsnin_"
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: 33212
X-purgate-ID: 151667::1395733691-0000128C-877912CB/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/3HhGZXlFLtNs5Q2JdbiDzXWAWDk
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 07:48:20 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1FE6DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I don't agree with this working assumption.

And I strongly disagree with the proposed way forward.

Ulrich

From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Monday, March 24, 2014 8:27 PM
To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: RE: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Let say that we have a working assumption on this one and please move on.

There is no need to reach a 100% agreement on this one to be able to publis=
h the version 02 and to have something consistent.

So please Ulrich, don't forget your concern but please accept that the curr=
ent working assumption. And let see if the concern is still valid afterward=
.

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 mars 2014 19:38
=C0 : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve







_______________________________________________

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_5BCBA1FC2B7F0B4C9D935572D9000668151D1FE6DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I don̵=
7;t agree with this working assumption.


 =
;


And I stro=
ngly disagree with the proposed way forward.


 =
;


Ulrich


 =
;






From:=
 ext lionel.morand@o=
range.com
 [mailto:lionel.morand@orange.com] 

Sent: Monday, March 24, 2014 8:27 PM

To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: RE: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Let say th=
at we have a working assumption on this one and please move on.


 


There is n=
o need to reach a 100% agreement on this one to be able to publish the vers=
ion 02 and to have something consistent.


 


So please =
Ulrich, don't forget your concern but please accept that the current workin=
g assumption. And let see if the concern is still valid afterward.


 


Regards,


 


Lionel


 






De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : lundi 24 mars 2014 19:38

=C0 : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


Ok,=
 we are going backwards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I do not agre=
e.


 =



We should =
still have the option



3) support=
 report type 0 (this is called host report) and support of report type 1 (t=
his has been called relam report but people argued it should
 better be called realm routed request report).


 


Whether or=
 not we need in addition to type 0 and type 1 (or as a replacement of type =
1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There are =
a lot of open questions  with regard to #55 and I have not seen a conc=
lusion.


Where I ha=
ve seen a conclusion is issue #34 and that is inline with option 3).=



 


Unless we =
conclude on #55, or decide to re-open #34, option 3) is what should go in t=
he -02 draft.


 


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan =
wrote:






Ulr=
ich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I don̵=
7;t know what happend in London.=



Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   <=
/o:p>


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 



















_______________________________________________


DiME mailing list


DiME@ietf.org


https://w=
ww.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.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D1FE6DEMUMBX014nsnin_--


From nobody Tue Mar 25 00:56:42 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 238811A01FF for ; Tue, 25 Mar 2014 00:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FZiXXEIF3CIs for ; Tue, 25 Mar 2014 00:56:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E5D511A0136 for ; Tue, 25 Mar 2014 00:56:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEX43915; Tue, 25 Mar 2014 07:56:32 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 07:56:01 +0000
Received: from SZXEMA401-HUB.china.huawei.com (10.82.72.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 07:56:30 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA401-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0158.001; Tue, 25 Mar 2014 15:56:21 +0800
From: "Shishufeng (Susan)" 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
Thread-Index: AQHPR4FM/aygBHyaP0STQC1LVSZ3tZrxcFXg
Date: Tue, 25 Mar 2014 07:56:21 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3DF19@SZXEMA512-MBX.china.huawei.com>
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> <072.d5e30cfd5cc5ac461bc3774ad9853b2b@trac.tools.ietf.org>  <5BCBA1FC2B7F0B4C9D935572D9000668151D1EC2@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1EC2@DEMUMBX014.nsn-intra.net>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2FrN0zX92jGIP1zzFl-sGC7H5hM
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
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, 25 Mar 2014 07:56:39 -0000

+1

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Sent: Tuesday, March 25, 2014 12:49 AM
To: ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overvie=
w

+1

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 4:41 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overvie=
w

Hi Steve

I am oK on your text apart a few sentences on the realm overload for which =
for me we have not yet concluded (cf my to day mail in the thread  [Dime] R=
esolution on action to discuss the need for Realm-Routed-Reports.

This is about this paragraph and especially the word "entire":=20
=20
	On the other hand, an "entire" Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an "entire" realm.

So I think a bit premature to insert this part of text as it is.

Best regards

JJacques=20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker=
 Envoy=E9=A0: lundi 24 mars 2014 14:24 =C0=A0: draft-docdt-dime-ovli@tools.=
ietf.org; srdonovan@usdonovans.com Cc=A0: dime@ietf.org Objet=A0: Re: [Dime=
] [dime] #41 (draft-docdt-dime-ovli): Need better overview

#41: Need better overview

Changes (by srdonovan@usdonovans.com):

 * status:  new =3D> closed
 * resolution:   =3D> fixed


Comment:

 The following wording for section 3.0 was added.  A new issue will be  ope=
ned to reflect that the remainder of section 3 needs to be made  consistent=
 with the current state of the DIOC solution.

 -----

    The Diameter Overload Information Conveyance (DOIC) mechanism allows
    Diameter nodes to request other nodes to perform overload abatement
    actions, that is, actions to reduce the load offered to the
    overloaded node.

    A Diameter node that supports DOIC is known as a "DOIC endpoint".
    Any Diameter node can act as a DOIC endpoint, including clients,
    servers, and agents.  DOIC endpoints are further divided into
    "Reporting Nodes" and "Reacting Nodes."  A reporting node requests
    overload abatement by sending an Overload Report (OLR) to one or more
    reacting nodes.

    A reacting node consumes OLRs, and performs whatever actions are
    needed to fulfill the requests.  A Reporting node may report overload
    on its own behalf, or on behalf of other (typically upstream) nodes.
    Likewise, a reacting node may perform overload abatement on its own
    behalf, or on behalf of other (typically downstream) nodes.

    A node's role as a DOIC endpoint is independent of its Diameter role.
    For example, Diameter relay and proxy agents may act as DOIC
    endpoints, even though they are not endpoints in the Diameter sense.
    Since Diameter enables bi-directional applications, where Diameter
    servers can send requests towards Diameter clients, a given Diameter
    node can simultaneously act as a reporting node and reacting node.

    Likewise, an relay or proxy agent may act as a reacting node from the
    perspective of upstream nodes, and a reporting node from the
    perspective of downstream nodes.

    DOIC endpoints do not generate new messages to carry DOIC related
    information.  Rather, they "piggyback" DOIC information over existing
    Diameter messages by inserting new AVPs into existing Diameter
    requests and responses.  Nodes indicate support for DOIC, and any
    needed DOIC parameters by inserting an OC_Supported_Features AVP
    (Section 4.1) into existing requests and responses.  Reporting nodes
    send OLRs by inserting OC-OLR AVPs.  (Section 4.3)

    A given OLR applies to the Diameter realm and application of the
    Diameter message that carries it.  If a reporting node supports more
    than one realm and/or application, it reports independently for each
    combination of realm and application.  Similarly, OC-Feature-Vector
    AVPs apply to the realm and application of the enclosing message.
    This implies that a node may support DOIC for one application and/or
    realm, but not another, and may indicate different DOIC parameters
    for each application and realm for which it supports DOIC.

    Reacting nodes perform overload abatement according to an agreed-upon
    abatement algorithm.  An abatement algorithm defines the meaning of
    the parameters of an OLR, and the procedures required for overload
    abatement.  This document specifies a single must-support algorithm,
    namely the "loss" algorithm [ref?].  Future specifications may
    introduce new algorithms.

    Overload conditions may vary in scope.  For example, a single
    Diameter node may be overloaded, in which case reacting nodes may
    reasonably attempt to send throttled requests to other destinations
    or via other agents.  On the other hand, an entire Diameter realm may
    be overloaded, in which case such attempts would do harm.  DOIC OLRs
    have a concept of "report type" (Section 4.6), where the type defines
    such behaviors.  Report types are extensible.  This document defines
    report types for overload of a specific server, and for overload of
    an entire realm.

    While a reporting node sends OLRs to "adjacent" reacting nodes, nodes
    that are "adjacent" for DOIC purposes may not be adjacent from a
    Diameter, or transport, perspective.  For example, one or more
    Diameter agents that do not support DOIC may exist between a given
    pair of reporting and reacting nodes, as long as those agents pass
    unknown AVPs through unmolested.  The report types described in this
    document can safely pass through non-supporting agents.  This may not
    be true for report types defined in future specifications.  Documents
    that introduce new report types MUST describe any limitations on
    their use across non-supporting agents.

--=20
-------------------------+----------------------------------------------
-------------------------+---
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+----------------------------------------------
-------------------------+---

Ticket URL: 
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 Tue Mar 25 00:58: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 89C431A0136 for ; Tue, 25 Mar 2014 00:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iPPW6VEOS-tb for ; Tue, 25 Mar 2014 00:57:55 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7267E1A037B for ; Tue, 25 Mar 2014 00:57:54 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCK20564; Tue, 25 Mar 2014 07:57:51 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 07:57:21 +0000
Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 25 Mar 2014 07:57:49 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Tue, 25 Mar 2014 15:57:41 +0800
From: "Shishufeng (Susan)" 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPR3wUvSEzOz4ciEGnqmsHJ1T4+prxcLnQ
Date: Tue, 25 Mar 2014 07:57:40 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3DF2D@SZXEMA512-MBX.china.huawei.com>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3DF2DSZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qzm_ToFD4ATRna5hkRxmWbfkOM4
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 07:58:00 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3DF2DSZXEMA512MBXchi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Tuesday, March 25, 2014 12:14 AM
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve




_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_26C84DFD55BC3040A45BF70926E55F2587C3DF2DSZXEMA512MBXchi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











+1


 =
;






From:=
 Wiehe, Ulrich (NSN =
- DE/Munich)
 [mailto:ulrich.wiehe@nsn.com] 

Sent: Tuesday, March 25, 2014 12:14 AM

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Steve,


 


I do not agre=
e.


 


We should =
still have the option



3) support=
 report type 0 (this is called host report) and support of report type 1 (t=
his has been called relam report but people argued it should
 better be called realm routed request report).


 =
;


Whether or=
 not we need in addition to type 0 and type 1 (or as a replacement of type =
1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There are =
a lot of open questions  with regard to #55 and I have not seen a conc=
lusion.


Where I ha=
ve seen a conclusion is issue #34 and that is inline with option 3).


 =
;


Unless we =
conclude on #55, or decide to re-open #34, option 3) is what should go in t=
he -02 draft.


 =
;


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan =
wrote:






Ulr=
ich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I don̵=
7;t know what happend in London.=



Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   <=
/o:p>


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 












_______________________________________________=



DiME mailing list


DiME@ietf.org


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




 






--_000_26C84DFD55BC3040A45BF70926E55F2587C3DF2DSZXEMA512MBXchi_--


From nobody Tue Mar 25 01:07: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 E24CC1A012F for ; Tue, 25 Mar 2014 01:07:33 -0700 (PDT)
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 ThdMimsOyhVL for ; Tue, 25 Mar 2014 01:07:30 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 13CA91A0076 for ; Tue, 25 Mar 2014 01:07:29 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2P87R66021408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Mar 2014 03:07:28 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2P87Qrk022362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Mar 2014 09:07:26 +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, 25 Mar 2014 09:07:26 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
Thread-Index: AQHPQgrXESB9RsUdU0edWfJzJEYY2prrxWUAgAAQ0YCAAIMrgIAAMw6AgAOWP4CAAVCG4A==
Date: Tue, 25 Mar 2014 08:07:25 +0000
Message-ID: 
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>   <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com> <53302397.7020006@usdonovans.com>
In-Reply-To: <53302397.7020006@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.40]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202672B74FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gXjUirEGkAW3hhLI4XgN_Qhn3r0
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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, 25 Mar 2014 08:07:34 -0000

--_000_E194C2E18676714DACA9C3A2516265D202672B74FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

Effectively we should be cautious with M bit for AVPS inside a grouped AVP =
such as OC-OLR AVP, and as Ben proposed, I am also rather in favour of not =
using the Mbit inside a DOC group AVP, including application specific AVPs.

In the thread discussion it  was mentioned the use of OC-feature and  also =
relay node that is application  independent.

Hereafter my  case:


After our IETF draft having become a RFC, IETF standardizes an extension,  =
which adds a new flag in OC-feature AVP. This extension is not specific to =
a Diameter application

-          A  relay oonly supporting our IETF draft, will observe that OC-f=
eature value does not fit to what it knows. I expect here that relay will d=
o nothing about DOC as the meaning of the OC-OLR may be different of what i=
t knows. OK? I als othink it applies to a proxy DA

-          If the relay supports the extension, it will recognize  the OC-f=
eature value and will behave according this value. So OK. Should we have so=
me text in the IETF draft?

Now, this is a Diameter  application (eg a 3GPP one) that will define an ex=
tension for its own use . Is this application is allowed to use bits of OC-=
Features AVP to indicate this application specific feature (or even algorit=
hm). How to avoid the application to use the same bits as future IETF exten=
sions? Will we be driven to use another OC-Application-Specific-Feature AVP=
, or have bits  in OC-Feature  reserved for application specific extensions=
., or other?  A constraint is that  a relay (application unaware) should ne=
vertheless  detect there is application specific extensions (without knowin=
g their meaning) so to not do DOC actions.

I understand this is not directly linked to our immediate scope, but we may=
 try  to be future proof allowing application specific extensions and Relay=
 node supporting the generic DOC.

Do you agree on this potential issue? If yes may be to analyse what to add =
in the IETF draft to be future proof.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : lundi 24 mars 2014 13:23
=C0 : dime@ietf.org
Objet : Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics

Do we have proposed wording to be included in the -02 version of the draft =
on this issue?

Steve
On 3/22/14 12:36 AM, Ben Campbell wrote:



On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  wrote:





Ben,



On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:





On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  wrote:





Consider the case of a Diameter _relay_ that supports DOIC. It is not aware=
 of any application-specific rules about m-bits. It receives an OC-Supporte=
d-Features or an OC-OLR that has a mandatory AVP that it doesn't recognize.=
 Logically, it should probably ignore the entire OC-Supported-Features or O=
C-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject th=
e message. Rather it's likely to try to apply the OC-Supported-Features or =
OC-OLR incorrectly.



RFC6733 also says that relays perform not do any application level

processing. If a relay supports DOIC and does something goofy that

is left for implementation, we should no care nor try to fix the

situation. The implementation is already bending the rules in that

case.



Hi Jouni,



I'm not talking about the case of the relay doing something goofy. Rather, =
I mean when a relay tries to perform basic DOIC processing of an OLR as des=
cribed in the base DOIC spec, but ignores some extension AVP that changes t=
he meaning of the OLR. It's not bending the rules so much as failing to rec=
ognize someone else changing the rules.



Ah, I see your point. But if one adds AVPs to the default algorithm

that change he behaviour and does not a) declare it as a new algorithm

or b) add a new supported feature flag, then that is a proprietary

(broken) implementation. We cannot really protect against those..



I think that's reasonable. My original point was that extensions should not=
 try to use the m-bit for that purpose. If they have something that is not =
backwards compatible, it needs to be negotiated in the feature vector.





_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_E194C2E18676714DACA9C3A2516265D202672B74FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable












Hi


 


Effectively we should be cautious with M b=
it for AVPS inside a grouped AVP such as OC-OLR AVP, and as Ben proposed, I=
 am also rather in
favour of not using the Mbit inside a DOC group AVP, including application specific AVPs.<=
/span>


 


In the thread discussion it
 was mentioned the use of OC-feature and  also relay node that is application
 independent.


 


Hereafter my
 case:


 


After ou=
r IETF draft having become a RFC, IETF standardizes an extension,
 which adds a new flag in OC-feature AVP. This extension =
is not specific to a Diameter application


=
-     =
    
A  relay oonly supporting our IETF=
 draft, will observe that OC-feature value does not fit to what it knows. I=
 expect here that relay will do nothing about
 DOC as the meaning of the OC-OLR may be different of what it knows. OK? I =
als othink it applies to a proxy DA


=
-     =
    
If the relay supports the extension, it will=
 recognize
 the OC-feature value and will behave according this valu=
e. So OK. Should we have some text in the IETF draft?


 <=
/p>

Now, this is a Diameter
 application (eg a 3GPP one=
) that will define an extension for its own use . Is this application is al=
lowed to use bits of OC-Features AVP to indicate this application specific =
feature (or even algorithm). How to avoid
 the application to use the same bits as future IETF extensions? Will we be=
 driven to use another OC-Application-Specific-Feature AVP, or have bits
 in OC-Feature  reserved for applicatio=
n specific extensions., or other?  A constraint is t=
hat
 a relay (application unaware) should nevertheless =
 detect there is application specific extensions (without knowi=
ng their meaning) so to not do DOC actions.
 


 


I understand this is not directly linked t=
o our immediate scope, but we may try
 to be future proof allowing application specific extensi=
ons and Relay node supporting the generic DOC.


 


Do you agree on this potential issue? If y=
es may be to
analyse what to add in the IETF draft to be f=
uture proof.


 


Best regards


 


JJacques
 


  


 






De :
DiME [mailto:dime-bounces@ietf.org] De la =
part de Steve Donovan

Envoy=E9 : lundi 24 mars 2014 13:23

=C0 : dime@ietf.org

Objet :
Re: [Dime] [dime] #48: Setting M-Bit
gives wrong 
semantics






 


Do we have propo=
sed wording to be included in the -02 version of the draft on this issue?


Steve




On 3/22/14 12:36 AM, Ben Campbell wrote:






 


On Mar 21, 2014, at 9:33 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:=



 




 


Ben,


 


On Mar 22, 2014, at 2:44 AM, Ben Campbell <ben@nostrum.com> wrote:


 




 


On Mar 21, 2014, at 12:43 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote=
:


 






 


Consider the case of a Diameter _relay_ that supports DOIC. It is not =
aware of any application-specific rules about m-bits. It receives an OC-Sup=
ported-Features or an OC-OLR that has a mandatory AVP that it doesn't recog=
nize. Logically, it should probably ignore the entire OC-Supported-Features=
 or OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reje=
ct the message. Rather it's likely to try to apply the OC-Supported-Feature=
s or OC-OLR incorrectly.




 


RFC6733 also says that relays perform not do any application level

processing. If a relay supports DOIC and does something goofy that

is left for implementation, we should no care nor try to fix the


situation. The implementation is already bending the rules in that

case.




 


Hi Jouni,


 


I'm not talking about the case of the relay doing something goofy. Rat=
her, I mean when a relay tries to perform basic DOIC processing of an OLR a=
s described in the base DOIC spec, but ignores some extension AVP that chan=
ges the meaning of the OLR. It's not bending the rules so much as failing t=
o recognize someone else changing the rules.




 


Ah, I see your point. But if one adds AVPs to the default algorithm

that change he behaviour and does not a) declare it as a new algorithm=



or b) add a new supported feature flag, then that is a proprietary

(broken) implementation. We cannot really protect against those..



 


I think that's reasonable. My original point was that extensions shoul=
d not try to use the m-bit for that purpose. If they have something that is=
 not backwards compatible, it needs to be negotiated in the feature vector.=



 


 


_______________________________________________


DiME mailing list


DiME@ietf.org

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


 




 








--_000_E194C2E18676714DACA9C3A2516265D202672B74FR712WXCHMBA12z_--


From nobody Tue Mar 25 01:08: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 BA14A1A0076 for ; Tue, 25 Mar 2014 01:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 WRqqzTrQogMC for ; Tue, 25 Mar 2014 01:08:29 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF0A1A012F for ; Tue, 25 Mar 2014 01:08:24 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2P87e3E011981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 08:07:40 GMT
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 s2P87ef9003015 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 09:07:40 +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; Tue, 25 Mar 2014 09:07:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 09:07:40 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAHYCmoA==
Date: Tue, 25 Mar 2014 08:07:39 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D2014@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@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.112]
Content-Type: text/plain; charset="iso-8859-1"
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: 6654
X-purgate-ID: 151667::1395734860-0000137C-031DB1FA/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/dvQW0a2NFCtIz79LUkrekfAYRRk
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 08:08:33 -0000

Hi JJacques,

let me try to give an example:

Client C1 supports algorithms A1 and A2.
Server S supports algorithms A1 and A2.
Client C2 supports only algorithm A1.

C1 sends an application x request indicating support of A1 and A2 to the se=
rver S.
Now S selects one single algorithm (in this example A2) and requests some r=
eduction using A2.  S has a OCS identified by the pair (x,A2).

Now client C2 sends an application x request indicating support of A1 to S.=
=20
Again S selects one single algorithm (in this case A1) and requests some re=
duction using A1. S has an OCS identified by the pair (x,A1).

In summary it is right that S selects one single algorithm out of the set o=
f adveritzed algorithms, but this does not mean that S must only maintain o=
ne OCS.

Best regards
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:08 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich)
Envoy=E9=A0: lundi 24 mars 2014 18:24
=C0=A0: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Objet=A0: Re: [Dime] issue #56 proposed conclusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)=20
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

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


From nobody Tue Mar 25 01:24: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 861141A013B for ; Tue, 25 Mar 2014 01:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 S8z-2q4_OwWx for ; Tue, 25 Mar 2014 01:24:14 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id A96791A012F for ; Tue, 25 Mar 2014 01:24:13 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2P8O9jw031334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 08:24:09 GMT
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 s2P8O975027758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 09:24:09 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 09:24:08 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 09:24:08 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAAWgNwAAcxQhg
Date: Tue, 25 Mar 2014 08:24:07 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@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.112]
Content-Type: text/plain; charset="iso-8859-1"
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: 7831
X-purgate-ID: 151667::1395735849-0000128C-D6174AAF/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/bhv7Kg3aYeu2z32oiK7EiF3Lvhw
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 08:24:16 -0000

Hi JJacques

Your concern is related to issue #35. For #35 we almost reached the conclus=
ion not to address client specific throttling in the 02-draft.

The latest proposal to solve #35 was to let clients indicate in OC-Supporte=
d-Features that they are clients; agents taking the role of reacting nodes =
on behalf of clients would not indicate  so. Servers must not request clien=
t specific throtting from reacting nodes that did not indicate that they ar=
e clients.
With this (partial) solution of #35 there would not be any impact to my pro=
posal for #56.

Best regards
Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given =
client=20

Your description of state is defined per Application and Abatement, so not =
including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There =
is the rate control algorithm that we will study, and here I am questioning=
 if we will not be driven to have a state per client, as the requested rate=
 will be rather specific to a client, some clients may have a small traffic=
  and others a large traffic, meaning to define a requested rate per client=
 somewhere.=20

So I may again repeat myself that the normal state would be per client in g=
eneral, which does not exclude to group all clients and consider a state co=
mmon to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but=
 it also concern other tickets.

Best regards=20

JJacques  =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
Envoy=E9=A0: lundi 24 mars 2014 19:08
=C0=A0: dime@ietf.org
Objet=A0: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: lundi 24 mars 2014 18:24 =C0=A0: Wiehe, Ulrich (=
NSN - DE/Munich); dime@ietf.org Objet=A0: Re: [Dime] issue #56 proposed con=
clusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

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

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


From nobody Tue Mar 25 02:02: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 4DFE01A0396 for ; Tue, 25 Mar 2014 02:02:40 -0700 (PDT)
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 MfWw_t0w98a2 for ; Tue, 25 Mar 2014 02:02:38 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 640E61A0379 for ; Tue, 25 Mar 2014 02:02:38 -0700 (PDT)
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 s2P92Z4A019806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Mar 2014 04:02:36 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2P92Z7e026466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Mar 2014 10:02:35 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 25 Mar 2014 10:02:35 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] DOIC Default Algorithm Specification
Thread-Index: AQHPQg1mSrntxLF47UmNCQBgXGvw6JrrxgcAgAXFv4A=
Date: Tue, 25 Mar 2014 09:02:34 +0000
Message-ID: 
References: <4857132E-EB7E-4844-B9F4-81DD209E0705@nostrum.com> <5750EB10-9E07-4CD7-A122-CD5DDBD73003@gmail.com>
In-Reply-To: <5750EB10-9E07-4CD7-A122-CD5DDBD73003@gmail.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.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/rMIhyQvVt0g78Sz5XJf-etAXDds
Subject: Re: [Dime] DOIC Default Algorithm Specification
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, 25 Mar 2014 09:02:40 -0000

Hi

I agree with Ben to differentiate general statements which are algorithm in=
dependent from the ones particular to the default algorithm, otherwise it m=
ay be a source of ambiguities/ misinterpretations . Now is this statement g=
rouping into a referenced section easy? I do not know. I hope this will not=
 have a too large impact on the draft.

Best regards

JJacques=20




-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: vendredi 21 mars 2014 18:46
=C0=A0: Ben Campbell
Cc=A0: dime@ietf.org list
Objet=A0: Re: [Dime] DOIC Default Algorithm Specification




On Mar 18, 2014, at 2:18 AM, Ben Campbell  wrote:

> Hi,
>=20
> In re-reading dime-ovli, I noticed that the procedures for the "default" =
abatement algorithm are spread through several parts of the text. That's go=
ing to make life difficult down the road for a couple of reasons:
>=20
> 1) There's no easily referenced section that fully defines the algorithm.=
 That will be a problem for other docs that want to talk about the algorith=
m (e.g. 3GPP specs), or even other sections in dime-ovli that want to menti=
on the default algorithm by reference.
>=20
> 2) It makes extensibility harder, as it will be more difficult to define =
new algorithms, if they need to modify behavior that is spread throughout d=
ime-ovli, rather than simply supersede a specific section of dime-ovli.
>=20
> I propose that we move all algorithm-specific behavior to its own section=
, and have any other sections that need to talk about the default algorithm=
 reference that section rather than attempt to describe the behavior.

That would work for me.

- Jouni


>=20
> Thanks!
>=20
> Ben.
> _______________________________________________
> 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 Tue Mar 25 02:07: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 A08151A0396 for ; Tue, 25 Mar 2014 02:07:42 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 8Usk13Q7DRU5 for ; Tue, 25 Mar 2014 02:07:39 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D9A191A0386 for ; Tue, 25 Mar 2014 02:07:38 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2P97ZKE006750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 09:07:35 GMT
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 s2P97Kqk030420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 10:07:34 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 10:07:30 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 10:07:31 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAGo2wAAHhMgAA==
Date: Tue, 25 Mar 2014 09:07:30 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D205C@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> <533081C6.9080103@usdonovans.com>
In-Reply-To: <533081C6.9080103@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D205CDEMUMBX014nsnin_"
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: 23394
X-purgate-ID: 151667::1395738455-0000128C-399E1BB6/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/s91t6ZmgntoWXIuL0t-E1YmflPk
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 09:07:42 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D205CDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

please see inline.

Ulrich
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 8:05 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Ulrich,

I have a few comments inline (towards the end of your proposal).

Steve
On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Dear all,



I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".



I'm fine with not abbreviating "Overload Control State".



I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.



Ulrich



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich)

Sent: Thursday, March 20, 2014 2:08 PM

To: dime@ietf.org

Subject: issue #56 proposed conclusion



#56: Bad Description of Overload Control State





Dear all,



I have received comments from Steve, MCruz and Jouni.



I believe all comments are covered by the following proposed text:







    5.5.1.  Overload Control State (OCS)



    5.5.1.1   Overload Control States for reacting nodes



    A reacting node 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=
s

      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 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

    following information:

    - Sequence number (as reveived in OC-OLR)

    - Time of expiry  (deviated from validity duration as received in OC-OL=
R

      and time of reception)

    - Selected Abatement Algorithm (as received in OC-Supported-Features)

    - Algorithm specific input data (as received within OC-OLR, e.g.

      Reduction Percentage for Loss)





    5.5.1.2   Overload Control States for reporting nodes



    A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State.



    An Overload Control State may be identified by the pair of Application-=
Id

    and supported Abatement Algorithm.



    The Overload Control State for a given pair of Application and Abatemen=
t

    Algorithm could include the information:

    - Sequence number

    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Percentage for Loss)





    5.5.1.3  Maintaining Overload Control States



    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving

    an answer message of application app-id containing an Orig-Host of host=
-id and a

    host-type OC-OLR AVP unless such host-type OCS already exists.



    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving

    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a

    realm-type OC-OLR AVP unless such realm type OCS already exists.



    Reacting nodes delete an OCS when it expires (i.e. when current time

    minus reception time is greater than validity duration).



    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when

    receiving an answer message of application app-id containing an Orig-Ho=
st of

    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he

    stored sequence number.



    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when

    receiving an answer message of application app-id containing an Orig-Re=
alm of

    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the

    stored sequence number.



    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a

    request of application app-id containing an OC-Supported-Features AVP

    indicating support of the Abatement Algorithm Alg (which the reporting

    node selects) while being overloaded, unless such OCS already exists.
SRD> I would think the reporting node would create the OCS when it determin=
es it needs a reduction, independent when it receives requests from various=
 reacting nodes.
 when not receiving requests, there is no need for reduction; the n=
eed of reduction is determined when a request is received.
Furthermore: If the reporting node determines that it needs a reduction ind=
ependently from a received request, which Algorithm would it select? 





    Reporting nodes delete an OCS when it expires.
SRD> Or when it explicitly sends an OLR with validity duration of zero.
 no. Let me give an example:
Server S has an OCS identified by the pair (Application x, Loss) with the c=
ontent: Sequence number =3D5, duration=3D 30 sec/expiry time=3D 9:45:59, pe=
rcentage =3D10%.
At 9:45:30 Client C1 sends an application x request to S and gets back an O=
LR indicating 10% for 30 sec.
At 9.45:57 Client C2 send an application x request to S and gets back an OL=
R indicating 10% for 30sec.
At 9:45:58 S decides that it is no longer overloaded. It therefore updates =
the OCS to contain: sequence number=3D6, duration =3D 0sec/expiry time=3D 9=
:46:30, percentage =3D0%.
At 9:45:59 C1 sends an application x request to S and gets back the explici=
t OLR with validity duration of zero. S must not delet the OCS at this time=
.
At 9:46:01 C2 sends an application x request to S and (because the OCS was =
not deleted in the previous step) gets back the explicit OLR with validity =
duration of zero. If the OCS was deleted in the previous step C2 would cont=
inue throttling until 9:46:27.







    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the

    need to modify the requested amount of application app-id traffic reduc=
tion.



Ulrich





_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D205CDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,<=
/p>

 <=
/p>

please see inline.


 <=
/p>

Ulrich<=
/p>





From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 8:05 PM

To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion<=
/p>





 


Ulrich,



I have a few comments inline (towards the end of your proposal).



Steve




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






Dear all,


 


I have received a further comment asking not to abbreviate "Overl=
oad Control State" as OCS is used for "Online Charging System&quo=
t;.


 


I'm fine with not abbreviating "Overload Control State".


 


I shall close issue #56 to meet Steve's deadline for the 02-draft, unl=
ess I receive more comments by tomorrow.


 


Ulrich


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) 


Sent: Thursday, March 20, 2014 2:08 PM


To: dime@ietf.org

Subject: issue #56 proposed conclusion


 


#56: Bad Description of Overload Control State


 


 


Dear all,


 


I have received comments from Steve, MCruz and Jouni.


 


I believe all comments are covered by the following proposed text:


 


 


 


    5.5.1.  Overload Control State (OCS)


 


    5.5.1.1   Overload Control States for rea=
cting nodes


 


    A reacting node maintains per supported Diameter ap=
plication


    - a host-type Overload Control State for each Desti=
nation-Host towards


      which it sends host-type requests and


    - a realm-type Overload Control State for each Dest=
ination-Realm towards


      which it sends realm-type requests.


 


    A host-type Overload Control State may be identifie=
d by the pair of


    Application-Id and Destination-Host.

    A realm-type Overload Control State may be identifi=
ed 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-Real=
m could include the


    following information:


    - Sequence number (as reveived in OC-OLR)


    - Time of expiry  (deviated from validity dura=
tion as received in OC-OLR


      and time of reception)


    - Selected Abatement Algorithm (as received in OC-S=
upported-Features)


    - Algorithm specific input data (as received within=
 OC-OLR, e.g.


      Reduction Percentage for Loss)


 


   


    5.5.1.2   Overload Control States fo=
r reporting nodes


 


    A reporting node maintains per supported Diameter a=
pplication and per


    supported (and eventually selected) Abatement Algor=
ithm an Overload


    Control State. 


 


    An Overload Control State may be identified by the =
pair of Application-Id


    and supported Abatement Algorithm.


 


    The Overload Control State for a given pair of Appl=
ication and Abatement


    Algorithm could include the information:=



    - Sequence number


    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Per=
centage for Loss)


 


    


    5.5.1.3  Maintaining Overload Control Sta=
tes


 


    Reacting nodes create a host-type OCS identified by=
 OCS-Id =3D (app-id,host-id) when receiving


    an answer message of application app-id containing =
an Orig-Host of host-id and a


    host-type OC-OLR AVP unless such host-type OCS alre=
ady exists.


 


    Reacting nodes create a realm-type OCS identified b=
y OCS-Id =3D (app-id,realm-id) when receiving


    an answer message of application app-id containing =
an Orig-Realm of realm-id and a


    realm-type OC-OLR AVP unless such realm type OCS al=
ready exists.


 


    Reacting nodes delete an OCS when it expires (i.e. =
when current time


    minus reception time is greater than validity durat=
ion).


 


    Reacting nodes update the host-type OCS identified =
by OCS-Id =3D (app-id,host-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Host of


    host-id and a host-type OC-OLR AVP with a sequence =
number higher than the


    stored sequence number.


 


    Reacting nodes update the realm-type OCS identified=
 by OCS-Id =3D (app-id,realm-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Realm of


    realm-id and a realm-type OC-OLR AVP with a sequenc=
e number higher than the


    stored sequence number.


 


    Reporting nodes create an OCS identified by OCS-Id =
=3D (app-id,Alg) when receiving a


    request of application app-id containing an OC-Supp=
orted-Features AVP


    indicating support of the Abatement Algorithm Alg (=
which the reporting


    node selects) while being overloaded, unless such O=
CS already exists.




SRD> I would think the repor=
ting node would create the OCS when it determines it needs a reduction, ind=
ependent when it receives requests from various reacting nodes. 


<Ulrich> when not=
 receiving requests, there is no need for reduction; the need of reduction =
is determined when a request is received.


Further=
more: If the reporting node determines that it needs a reduction independen=
tly from a received request, which Algorithm would it select? </Ulrich&g=
t;


 


 


    Reporting nodes delete =
an OCS when it expires.


SRD> Or when it explicitly sends an OLR with vali=
dity duration of zero.


<Ulrich=
> no. Let me give an example:


Server S h=
as an OCS identified by the pair (Application x, Loss) with the content: Se=
quence number =3D5, duration=3D 30 sec/expiry time=3D 9:45:59, percentage
 =3D10%.


At 9:45:30=
 Client C1 sends an application x request to S and gets back an OLR indicat=
ing 10% for 30 sec.


At 9.45:57=
 Client C2 send an application x request to S and gets back an OLR indicati=
ng 10% for 30sec.


At 9:45:58=
 S decides that it is no longer overloaded. It therefore updates the OCS to=
 contain: sequence number=3D6, duration =3D 0sec/expiry time=3D
 9:46:30, percentage =3D0%.


At 9:45:59=
 C1 sends an application x request to S and gets back the explicit OLR with=
 validity duration of zero. S must not delet the OCS at this
 time.


At 9:46:01=
 C2 sends an application x request to S and (because the OCS was not delete=
d in the previous step) gets back the explicit OLR with validity
 duration of zero. If the OCS was deleted in the previous step C2 would con=
tinue throttling until 9:46:27.</Ulrich>









 


 


    Reporting nodes update the OCS=
 identified by OCS-Id =3D (app-id,Alg) when they detect the


    need to modify the requested a=
mount of application app-id traffic reduction.


 


Ulrich


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 


 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D205CDEMUMBX014nsnin_--


From nobody Tue Mar 25 02:08:46 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 2B8031A0386 for ; Tue, 25 Mar 2014 02:08:41 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 ynrTgWXzPOIM for ; Tue, 25 Mar 2014 02:08:35 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 810C11A0369 for ; Tue, 25 Mar 2014 02:08:35 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2P98XWD009099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 09:08:33 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2P98Wid018777 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 10:08:33 +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, 25 Mar 2014 10:08:32 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 10:08:32 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAG7ogAAH3vzQA==
Date: Tue, 25 Mar 2014 09:08:32 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D206F@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> <53308244.5010305@usdonovans.com>
In-Reply-To: <53308244.5010305@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D206FDEMUMBX014nsnin_"
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: 18072
X-purgate-ID: 151667::1395738513-0000128C-CD52107C/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9oskfDzFWVTcq_boZfYSgtAhPRU
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 09:08:41 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D206FDEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Also fine with me.
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 8:07 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Ulrich,

Acronym overlap is unavoidable.  If we add OCS in the abbreviations section=
 then we should be ok.

Steve
On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Dear all,



I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".



I'm fine with not abbreviating "Overload Control State".



I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.



Ulrich



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich)

Sent: Thursday, March 20, 2014 2:08 PM

To: dime@ietf.org

Subject: issue #56 proposed conclusion



#56: Bad Description of Overload Control State





Dear all,



I have received comments from Steve, MCruz and Jouni.



I believe all comments are covered by the following proposed text:







    5.5.1.  Overload Control State (OCS)



    5.5.1.1   Overload Control States for reacting nodes



    A reacting node 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=
s

      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 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

    following information:

    - Sequence number (as reveived in OC-OLR)

    - Time of expiry  (deviated from validity duration as received in OC-OL=
R

      and time of reception)

    - Selected Abatement Algorithm (as received in OC-Supported-Features)

    - Algorithm specific input data (as received within OC-OLR, e.g.

      Reduction Percentage for Loss)





    5.5.1.2   Overload Control States for reporting nodes



    A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State.



    An Overload Control State may be identified by the pair of Application-=
Id

    and supported Abatement Algorithm.



    The Overload Control State for a given pair of Application and Abatemen=
t

    Algorithm could include the information:

    - Sequence number

    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Percentage for Loss)





    5.5.1.3  Maintaining Overload Control States



    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving

    an answer message of application app-id containing an Orig-Host of host=
-id and a

    host-type OC-OLR AVP unless such host-type OCS already exists.



    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving

    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a

    realm-type OC-OLR AVP unless such realm type OCS already exists.



    Reacting nodes delete an OCS when it expires (i.e. when current time

    minus reception time is greater than validity duration).



    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when

    receiving an answer message of application app-id containing an Orig-Ho=
st of

    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he

    stored sequence number.



    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when

    receiving an answer message of application app-id containing an Orig-Re=
alm of

    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the

    stored sequence number.



    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a

    request of application app-id containing an OC-Supported-Features AVP

    indicating support of the Abatement Algorithm Alg (which the reporting

    node selects) while being overloaded, unless such OCS already exists.



    Reporting nodes delete an OCS when it expires.



    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the

    need to modify the requested amount of application app-id traffic reduc=
tion.



Ulrich





_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D206FDEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Also fine with me.


Ulrich<=
/p>

 <=
/p>





From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 8:07 PM

To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion<=
/p>





 


Ulrich,



Acronym overlap is unavoidable.  If we add OCS in the abbreviations se=
ction then we should be ok.



Steve




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






Dear all,


 


I have received a further comment asking not to abbreviate "Overl=
oad Control State" as OCS is used for "Online Charging System&quo=
t;.


 


I'm fine with not abbreviating "Overload Control State".


 


I shall close issue #56 to meet Steve's deadline for the 02-draft, unl=
ess I receive more comments by tomorrow.


 


Ulrich


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) 


Sent: Thursday, March 20, 2014 2:08 PM


To: dime@ietf.org

Subject: issue #56 proposed conclusion


 


#56: Bad Description of Overload Control State


 


 


Dear all,


 


I have received comments from Steve, MCruz and Jouni.


 


I believe all comments are covered by the following proposed text:


 


 


 


    5.5.1.  Overload Control State (OCS)


 


    5.5.1.1   Overload Control States for rea=
cting nodes


 


    A reacting node maintains per supported Diameter ap=
plication


    - a host-type Overload Control State for each Desti=
nation-Host towards


      which it sends host-type requests and


    - a realm-type Overload Control State for each Dest=
ination-Realm towards


      which it sends realm-type requests.


 


    A host-type Overload Control State may be identifie=
d by the pair of


    Application-Id and Destination-Host.

    A realm-type Overload Control State may be identifi=
ed 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-Real=
m could include the


    following information:


    - Sequence number (as reveived in OC-OLR)


    - Time of expiry  (deviated from validity dura=
tion as received in OC-OLR


      and time of reception)


    - Selected Abatement Algorithm (as received in OC-S=
upported-Features)


    - Algorithm specific input data (as received within=
 OC-OLR, e.g.


      Reduction Percentage for Loss)


 


   


    5.5.1.2   Overload Control States fo=
r reporting nodes


 


    A reporting node maintains per supported Diameter a=
pplication and per


    supported (and eventually selected) Abatement Algor=
ithm an Overload


    Control State. 


 


    An Overload Control State may be identified by the =
pair of Application-Id


    and supported Abatement Algorithm.


 


    The Overload Control State for a given pair of Appl=
ication and Abatement


    Algorithm could include the information:=



    - Sequence number


    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Per=
centage for Loss)


 


    


    5.5.1.3  Maintaining Overload Control Sta=
tes


 


    Reacting nodes create a host-type OCS identified by=
 OCS-Id =3D (app-id,host-id) when receiving


    an answer message of application app-id containing =
an Orig-Host of host-id and a


    host-type OC-OLR AVP unless such host-type OCS alre=
ady exists.


 


    Reacting nodes create a realm-type OCS identified b=
y OCS-Id =3D (app-id,realm-id) when receiving


    an answer message of application app-id containing =
an Orig-Realm of realm-id and a


    realm-type OC-OLR AVP unless such realm type OCS al=
ready exists.


 


    Reacting nodes delete an OCS when it expires (i.e. =
when current time


    minus reception time is greater than validity durat=
ion).


 


    Reacting nodes update the host-type OCS identified =
by OCS-Id =3D (app-id,host-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Host of


    host-id and a host-type OC-OLR AVP with a sequence =
number higher than the


    stored sequence number.


 


    Reacting nodes update the realm-type OCS identified=
 by OCS-Id =3D (app-id,realm-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Realm of


    realm-id and a realm-type OC-OLR AVP with a sequenc=
e number higher than the


    stored sequence number.


 


    Reporting nodes create an OCS identified by OCS-Id =
=3D (app-id,Alg) when receiving a


    request of application app-id containing an OC-Supp=
orted-Features AVP


    indicating support of the Abatement Algorithm Alg (=
which the reporting


    node selects) while being overloaded, unless such O=
CS already exists.


 


    Reporting nodes delete an OCS when it expires.=



 


    Reporting nodes update the OCS identified by OCS-Id=
 =3D (app-id,Alg) when they detect the


    need to modify the requested amount of application =
app-id traffic reduction.


 


Ulrich


 


 


_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime


 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D206FDEMUMBX014nsnin_--


From nobody Tue Mar 25 02:24: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 483A31A0386 for ; Tue, 25 Mar 2014 02:24:50 -0700 (PDT)
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 glyqVVUNFrpD for ; Tue, 25 Mar 2014 02:24:44 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9131A036B for ; Tue, 25 Mar 2014 02:24:44 -0700 (PDT)
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 s2P9OffU011897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 25 Mar 2014 04:24:42 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2P9Odkr018875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 25 Mar 2014 10:24:39 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 25 Mar 2014 10:24:39 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAGo2wAAHhMgAAABlxpQ
Date: Tue, 25 Mar 2014 09:24:38 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> <533081C6.9080103@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D205C@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D205C@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D202672BEEFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/32LUWl7nVamStGY21zRAebT4m_0
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 09:24:50 -0000

--_000_E194C2E18676714DACA9C3A2516265D202672BEEFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Ulrich Steve

>From the Ulrich use case about deletion of OCS, which is for me valid,  I u=
nderstand that the reporting node has to ensure that all its clients receiv=
ed its updated  OLR with validity time 0,  so with the hope this does not c=
reate  an "OCS status" per client. Steve statement applies when there is a =
per client handling of  the OLR in the reporting node (this is another disc=
ussion point). The fact to globally handle the clients has also some conseq=
uences even if there is an interest for it.

Best regards.

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : mardi 25 mars 2014 10:08
=C0 : ext Steve Donovan; dime@ietf.org
Objet : Re: [Dime] issue #56 proposed conclusion

Steve,

please see inline.

Ulrich
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 8:05 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Ulrich,

I have a few comments inline (towards the end of your proposal).

Steve
On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Dear all,



I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".



I'm fine with not abbreviating "Overload Control State".



I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.



Ulrich



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich)

Sent: Thursday, March 20, 2014 2:08 PM

To: dime@ietf.org

Subject: issue #56 proposed conclusion



#56: Bad Description of Overload Control State





Dear all,



I have received comments from Steve, MCruz and Jouni.



I believe all comments are covered by the following proposed text:







    5.5.1.  Overload Control State (OCS)



    5.5.1.1   Overload Control States for reacting nodes



    A reacting node 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=
s

      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 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

    following information:

    - Sequence number (as reveived in OC-OLR)

    - Time of expiry  (deviated from validity duration as received in OC-OL=
R

      and time of reception)

    - Selected Abatement Algorithm (as received in OC-Supported-Features)

    - Algorithm specific input data (as received within OC-OLR, e.g.

      Reduction Percentage for Loss)





    5.5.1.2   Overload Control States for reporting nodes



    A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State.



    An Overload Control State may be identified by the pair of Application-=
Id

    and supported Abatement Algorithm.



    The Overload Control State for a given pair of Application and Abatemen=
t

    Algorithm could include the information:

    - Sequence number

    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Percentage for Loss)





    5.5.1.3  Maintaining Overload Control States



    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving

    an answer message of application app-id containing an Orig-Host of host=
-id and a

    host-type OC-OLR AVP unless such host-type OCS already exists.



    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving

    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a

    realm-type OC-OLR AVP unless such realm type OCS already exists.



    Reacting nodes delete an OCS when it expires (i.e. when current time

    minus reception time is greater than validity duration).



    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when

    receiving an answer message of application app-id containing an Orig-Ho=
st of

    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he

    stored sequence number.



    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when

    receiving an answer message of application app-id containing an Orig-Re=
alm of

    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the

    stored sequence number.



    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a

    request of application app-id containing an OC-Supported-Features AVP

    indicating support of the Abatement Algorithm Alg (which the reporting

    node selects) while being overloaded, unless such OCS already exists.
SRD> I would think the reporting node would create the OCS when it determin=
es it needs a reduction, independent when it receives requests from various=
 reacting nodes.
 when not receiving requests, there is no need for reduction; the n=
eed of reduction is determined when a request is received.
Furthermore: If the reporting node determines that it needs a reduction ind=
ependently from a received request, which Algorithm would it select? 





    Reporting nodes delete an OCS when it expires.
SRD> Or when it explicitly sends an OLR with validity duration of zero.
 no. Let me give an example:
Server S has an OCS identified by the pair (Application x, Loss) with the c=
ontent: Sequence number =3D5, duration=3D 30 sec/expiry time=3D 9:45:59, pe=
rcentage =3D10%.
At 9:45:30 Client C1 sends an application x request to S and gets back an O=
LR indicating 10% for 30 sec.
At 9.45:57 Client C2 send an application x request to S and gets back an OL=
R indicating 10% for 30sec.
At 9:45:58 S decides that it is no longer overloaded. It therefore updates =
the OCS to contain: sequence number=3D6, duration =3D 0sec/expiry time=3D 9=
:46:30, percentage =3D0%.
At 9:45:59 C1 sends an application x request to S and gets back the explici=
t OLR with validity duration of zero. S must not delet the OCS at this time=
.
At 9:46:01 C2 sends an application x request to S and (because the OCS was =
not deleted in the previous step) gets back the explicit OLR with validity =
duration of zero. If the OCS was deleted in the previous step C2 would cont=
inue throttling until 9:46:27.






    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the

    need to modify the requested amount of application app-id traffic reduc=
tion.



Ulrich





_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_E194C2E18676714DACA9C3A2516265D202672BEEFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Ulrich Steve


 <=
/p>

From the Ulrich use case =
about deletion of OCS, which is for me valid,  I understand that the r=
eporting node has to ensure that all its clients received its
 updated  OLR with validity time 0,  so with the hope this does n=
ot create  an “OCS status” per client. Steve statement app=
lies when there is a per client handling of  the OLR in the reporting =
node (this is another discussion point). The fact to globally handle
 the clients has also some consequences even if there is an interest for it=
.


 <=
/p>

Best regards.=



 


JJacques &nbs=
p;


 






De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : mardi 25 mars 2014 10:08

=C0 : ext Steve Donovan; dime@ietf.org

Objet : Re: [Dime] issue #56 proposed conclusion






 


Steve,


 


please see in=
line.


 


Ulrich






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 8:05 PM

To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion<=
/p>





 


Ulr=
ich,



I have a few comments inline (towards the end of your proposal).



Steve




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






Dear all,


 


I have received a further comment asking not to abbr=
eviate "Overload Control State" as OCS is used for "Online C=
harging System".


 


I'm fine with not abbreviating "Overload Contro=
l State".


 


I shall close issue #56 to meet Steve's deadline for=
 the 02-draft, unless I receive more comments by tomorrow.


 


Ulrich


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich) 


Sent: Thursday, March 20, 2014 2:08 PM


To: dime@ietf.org


Subject: issue #56 proposed conclusion


 


#56: Bad Description of Overload Control State<=
/o:p>


 


 


Dear all,


 


I have received comments from Steve, MCruz and Jouni=
.


 


I believe all comments are covered by the following =
proposed text:


 


 


 


    5.5.1.  Overload Control Sta=
te (OCS)


 


    5.5.1.1   Overload Cont=
rol States for reacting nodes


 


    A reacting node maintains per sup=
ported Diameter application


    - a host-type Overload Control St=
ate for each Destination-Host towards


      which it sends host-t=
ype requests and


    - a realm-type Overload Control S=
tate for each Destination-Realm towards


      which it sends realm-=
type requests.


 


    A host-type Overload Control Stat=
e may be identified by the pair of


    Application-Id and Destination-Ho=
st.


    A realm-type Overload Control Sta=
te may be identified by the pair of


    Application-Id and Destination-Re=
alm.


    The host-type/realm-type Overload=
 Control State for a given pair of


    Application and Destination-Host =
/ Destination-Realm could include the


    following information:=



    - Sequence number (as reveived in=
 OC-OLR)


    - Time of expiry  (deviated =
from validity duration as received in OC-OLR


      and time of reception=
)


    - Selected Abatement Algorithm (a=
s received in OC-Supported-Features)


    - Algorithm specific input data (=
as received within OC-OLR, e.g.


      Reduction Percentage =
for Loss)


 


   


    5.5.1.2   Overload=
 Control States for reporting nodes


 


    A reporting node maintains per su=
pported Diameter application and per


    supported (and eventually selecte=
d) Abatement Algorithm an Overload


    Control State. =



 


    An Overload Control State may be =
identified by the pair of Application-Id


    and supported Abatement Algorithm=
.


 


    The Overload Control State for a =
given pair of Application and Abatement


    Algorithm could include the infor=
mation:


    - Sequence number


    - Validity Duration and Expiry Ti=
me


    - Algorithm specific input data (=
e.g. Reduction Percentage for Loss)


 


    


    5.5.1.3  Maintaining Ov=
erload Control States


 


    Reacting nodes create a host-type=
 OCS identified by OCS-Id =3D (app-id,host-id) when receiving


    an answer message of application =
app-id containing an Orig-Host of host-id and a


    host-type OC-OLR AVP unless such =
host-type OCS already exists.


 


    Reacting nodes create a realm-typ=
e OCS identified by OCS-Id =3D (app-id,realm-id) when receiving<=
/span>


    an answer message of application =
app-id containing an Orig-Realm of realm-id and a


    realm-type OC-OLR AVP unless such=
 realm type OCS already exists.


 


    Reacting nodes delete an OCS when=
 it expires (i.e. when current time


    minus reception time is greater t=
han validity duration).


 


    Reacting nodes update the host-ty=
pe OCS identified by OCS-Id =3D (app-id,host-id) when

    receiving an answer message of ap=
plication app-id containing an Orig-Host of


    host-id and a host-type OC-OLR AV=
P with a sequence number higher than the


    stored sequence number.


 


    Reacting nodes update the realm-t=
ype OCS identified by OCS-Id =3D (app-id,realm-id) when

    receiving an answer message of ap=
plication app-id containing an Orig-Realm of


    realm-id and a realm-type OC-OLR =
AVP with a sequence number higher than the


    stored sequence number.


 


    Reporting nodes create an OCS ide=
ntified by OCS-Id =3D (app-id,Alg) when receiving a


    request of application app-id con=
taining an OC-Supported-Features AVP


    indicating support of the Abateme=
nt Algorithm Alg (which the reporting


    node selects) while being overloa=
ded, unless such OCS already exists.




SRD> I would think the reporting node would creat=
e the OCS when it determines it needs a reduction, independent when it rece=
ives requests from various reacting nodes. 


<Ulrich> when not receiving requests, t=
here is no need for reduction; the need of reduction is determined when a r=
equest is received.


Furthermore: If the re=
porting node determines that it needs a reduction independently from a rece=
ived request, which Algorithm would it select? </Ulrich><=
/o:p>


 


 


    Reporting nodes delete an OCS whe=
n it expires.


SRD> Or when it explicitly send=
s an OLR with validity duration of zero.


<Ulrich> no. Let me=
 give an example:


Server S has an OCS ident=
ified by the pair (Application x, Loss) with the content: Sequence number =
=3D5, duration=3D 30 sec/expiry time=3D 9:45:59, percentage =3D10%.


At 9:45:30 Client C1 send=
s an application x request to S and gets back an OLR indicating 10% for 30 =
sec.


At 9.45:57 Client C2 send=
 an application x request to S and gets back an OLR indicating 10% for 30se=
c.


At 9:45:58 S decides that=
 it is no longer overloaded. It therefore updates the OCS to contain: seque=
nce number=3D6, duration =3D 0sec/expiry time=3D 9:46:30, percentage
 =3D0%.


At 9:45:59 C1 sends an ap=
plication x request to S and gets back the explicit OLR with validity durat=
ion of zero. S must not delet the OCS at this time.


At 9:46:01 C2 sends an ap=
plication x request to S and (because the OCS was not deleted in the previo=
us step) gets back the explicit OLR with validity duration
 of zero. If the OCS was deleted in the previous step C2 would continue thr=
ottling until 9:46:27.</Ulrich>


 


 


 


    Reporting nodes update the OCS identified by OCS-Id=
 =3D (app-id,Alg) when they detect the


    need to modify the requested amount of application app-id traffic reduction.


 


Ulrich


 


 


_______________________________________________=



DiME mailing list


DiME@ietf.org


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


 


 






--_000_E194C2E18676714DACA9C3A2516265D202672BEEFR712WXCHMBA12z_--


From nobody Tue Mar 25 03:22:22 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 D68631A0181 for ; Tue, 25 Mar 2014 03:21:45 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 psF-szky0kVA for ; Tue, 25 Mar 2014 03:21:41 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89E1A017B for ; Tue, 25 Mar 2014 03:21:41 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2PALcDt011369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 10:21:38 GMT
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 s2PALc3A016847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 11:21:38 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 11:21:38 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 11:21:38 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue#31 status
Thread-Index: Ac8tfUYIV82WBUGEQQ+YDsLcVKoJfQaH0FqAAB0AC2A=
Date: Tue, 25 Mar 2014 10:21:37 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D20E8@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net> <53309E4F.7050509@usdonovans.com>
In-Reply-To: <53309E4F.7050509@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D20E8DEMUMBX014nsnin_"
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: 25727
X-purgate-ID: 151667::1395742899-0000137C-05BAA2A7/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/c2R8YIO1wGxebvXyQcNZE1ZW3Gk
Subject: Re: [Dime] Issue#31 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, 25 Mar 2014 10:21:46 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D20E8DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,

I think we can easily extend the proposed text for #56 to cover these point=
s:



    5.5.1.  Overload Control State (OCS)



    5.5.1.1   Overload Control States for reacting nodes



    A reacting node 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=
s

      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 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

    following information:

    - Sequence number (as reveived in OC-OLR)

    - Time of expiry  (deviated from validity duration as received in OC-OL=
R

      and time of reception)

    - Selected Abatement Algorithm (as received in OC-Supported-Features)

    - Algorithm specific input data (as received within OC-OLR, e.g.

      Reduction Percentage for Loss)





    5.5.1.2   Overload Control States for reporting nodes



    A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State.



    An Overload Control State may be identified by the pair of Application-=
Id

    and supported Abatement Algorithm.



    The Overload Control State for a given pair of Application and Abatemen=
t

    Algorithm could include the information:

    - Sequence number

    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

    Overload Control States for reporting nodes containing a validity durat=
ion of 0 sec. should

    not expire before any previously sent (stale) OLR has timed out at any =
reacting node.



    5.5.1.3  Maintaining Overload Control States



    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving

    an answer message of application app-id containing an Orig-Host of host=
-id and a

    host-type OC-OLR AVP unless such host-type OCS already exists.



    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving

    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a

    realm-type OC-OLR AVP unless such realm type OCS already exists.



    Reacting nodes delete an OCS when it expires (i.e. when current time

    minus reception time is greater than validity duration).



    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when

    receiving an answer message of application app-id containing an Orig-Ho=
st of

    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he

    stored sequence number.



    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when

    receiving an answer message of application app-id containing an Orig-Re=
alm of

    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the

    stored sequence number.



    Reacting nodes do not delete an OCS when receiving an answer message th=
at does not

    contain an OC-OLR AVP (i.e. absence of OLR means "no change").



    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a

    request of application app-id containing an OC-Supported-Features AVP

    indicating support of the Abatement Algorithm Alg (which the reporting

    node selects) while being overloaded, unless such OCS already exists.



    Reporting nodes delete an OCS when it expires.



    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the

    need to modify the requested amount of application app-id traffic reduc=
tion.



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 10:06 PM
To: dime@ietf.org
Subject: Re: [Dime] Issue#31 status

All,

Can someone boil down the various proposed wording for this issue into what=
 we want to have in the -02 draft.

Thanks,

Steve
On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that surviv=
ed a throttling

Dear all,

I did not receive much support for the proposal to define an OC-Ongoing-Thr=
ottling-Info AVP in request messages that survived a throttlting.

However, we seem to agree on some principles:

Missing OLR in answer means "no change"; it does not mean "no overload/no t=
hrottling requested"

Reporting nodes SHOULD include OLR in every answer that it sends in respons=
e to a request message which indicated OLR_DEFAULT_ALGO support unless the =
reporting node has very good reasons not to do so. Exact wording is not yet=
 agreed.

Ulrich







_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D20E8DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


 =
;


I think we=
 can easily extend the proposed text for #56 to cover these points:


 =
;


 =
;


    5.5.1.&nb=
sp; Overload Control State (OCS)


 


    5.5.1.1&n=
bsp;  Overload Control States for reacting nodes


 


    A reactin=
g node maintains per supported Diameter application


    - a host-=
type Overload Control State for each Destination-Host towards


    &nbs=
p; which it sends host-type requests and


    - a realm=
-type Overload Control State for each Destination-Realm towards<=
/span>


    &nbs=
p; which it sends realm-type requests.


 


    A host-ty=
pe Overload Control State may be identified by the pair of


    Applicati=
on-Id and Destination-Host.


    A realm-t=
ype Overload Control State may be identified by the pair of


    Applicati=
on-Id and Destination-Realm.


    The host-=
type/realm-type Overload Control State for a given pair of


    Applicati=
on and Destination-Host / Destination-Realm could include the


    following=
 information:


    - Sequenc=
e number (as reveived in OC-OLR)


    - Time of=
 expiry  (deviated from validity duration as received in OC-OLR


    &nbs=
p; and time of reception)


    - Selecte=
d Abatement Algorithm (as received in OC-Supported-Features)


    - Algorit=
hm specific input data (as received within OC-OLR, e.g.

    &nbs=
p; Reduction Percentage for Loss)


 


   


    5.5.=
1.2   Overload Control States for reporting nodes


 


    A reporti=
ng node maintains per supported Diameter application and per


    supported=
 (and eventually selected) Abatement Algorithm an Overload


    Co=
ntrol State. 


 


    An Overlo=
ad Control State may be identified by the pair of Application-Id=



    and suppo=
rted Abatement Algorithm.


 


    The Overl=
oad Control State for a given pair of Application and Abatement<=
/span>


    Algorithm=
 could include the information:


    - Sequenc=
e number


    - Validit=
y Duration and Expiry Time


    - Algorit=
hm specific input data (e.g. Reduction Percentage for Loss)


    Overload Control States for reporting nodes containing a v=
alidity duration of 0 sec. should


 &n=
bsp;  not expire before any previously sent (stale) OLR has timed out =
at any reacting node.


    


    5.5.=
1.3  Maintaining Overload Control States


 


    Reacting =
nodes create a host-type OCS identified by OCS-Id =3D (app-id,host-id) when=
 receiving


    an answer=
 message of application app-id containing an Orig-Host of host-id and a


    host-type=
 OC-OLR AVP unless such host-type OCS already exists.


 


    Reacting =
nodes create a realm-type OCS identified by OCS-Id =3D (app-id,realm-id) wh=
en receiving


    an answer=
 message of application app-id containing an Orig-Realm of realm-id and a


    realm-typ=
e OC-OLR AVP unless such realm type OCS already exists.

 


    Reacting =
nodes delete an OCS when it expires (i.e. when current time


    minus rec=
eption time is greater than validity duration).


 


    Reacting =
nodes update the host-type OCS identified by OCS-Id =3D (app-id,host-id) wh=
en


    receiving=
 an answer message of application app-id containing an Orig-Host of


    host-id a=
nd a host-type OC-OLR AVP with a sequence number higher than the=



    stored se=
quence number.


 


    Reacting =
nodes update the realm-type OCS identified by OCS-Id =3D (app-id,realm-id) =
when


    receiving=
 an answer message of application app-id containing an Orig-Realm of


    realm-id =
and a realm-type OC-OLR AVP with a sequence number higher than the


    stored se=
quence number.


 


    Reacting nodes do not delete an OCS when receiving an answ=
er message that does not


 &n=
bsp;  contain an OC-OLR AVP (i.e. absence of OLR means “no chang=
e”).


 


    Reporting=
 nodes create an OCS identified by OCS-Id =3D (app-id,Alg) when receiving a=



    request o=
f application app-id containing an OC-Supported-Features AVP


    indicatin=
g support of the Abatement Algorithm Alg (which the reporting


    node sele=
cts) while being overloaded, unless such OCS already exists.


 


    Reporting=
 nodes delete an OCS when it expires.


 


    Reporting=
 nodes update the OCS identified by OCS-Id =3D (app-id,Alg) when they detec=
t the


    need to m=
odify the requested amount of application app-id traffic reduction.


 =
;


 =
;


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 10:06 PM

To: dime@ietf.org

Subject: Re: [Dime] Issue#31 status






 


All,



Can someone boil down the various proposed wording for this issue into what=
 we want to have in the -02 draft.



Thanks,



Steve




On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:








#31: Sending OC-Ongoing-Throttling-Info=
 AVP in request messages that survived a throttling






 






Dear all,






 






I did not receive much support for the =
proposal to define an OC-Ongoing-Throttling-Info AVP in request messages th=
at survived a throttlting.






 






However, we seem to agree on some princ=
iples:






 






Missing OLR in answer means “no c=
hange”; it does not mean “no overload/no throttling requested&#=
8221;






 






Reporting nodes SHOULD include OLR in e=
very answer that it sends in response to a request message which indicated
OLR_DEFAULT_ALGO 
support unless the reporting node has very good reasons not to=
 do so. Exact wording is not yet agreed.







 






Ulrich






 






 






 













_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D20E8DEMUMBX014nsnin_--


From nobody Tue Mar 25 04:44: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 C6D9C1A0029 for ; Tue, 25 Mar 2014 04:44:26 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 OLyVovPNacT3 for ; Tue, 25 Mar 2014 04:44:21 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0F21A006E for ; Tue, 25 Mar 2014 04:44:21 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2PBiJjq007076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 11:44:19 GMT
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2PBiI3p003939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 12:44:18 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 12:44:18 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 12:44:17 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRUlVL8WBONWpVkShCkGbZ2B6UJrwNmSAgAAvmYCAAB77AIABLGLQ
Date: Tue, 25 Mar 2014 11:44:17 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com>
In-Reply-To: <53307B7C.4000200@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2197DEMUMBX014nsnin_"
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: 23786
X-purgate-ID: 151667::1395747859-0000137C-D3A52400/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/N0IxxcujRgzdsflkKirg-fuQIPk
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 11:44:27 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2197DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,
I don't think we are going backwards (we may be out of synch though)

Can you please summarize the status of #23 and #55.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve






_______________________________________________

DiME mailing list

DiME@ietf.org

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



--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2197DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


I don̵=
7;t think we are going backwards (we may be out of synch though)=



 =
;


Can you pl=
ease summarize the status of #23 and #55.


 =
;


Ulrich


 =
;


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 7:38 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ok, we are going back=
wards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I do not agree.


 <=
/p>

We should =
still have the option



3) support=
 report type 0 (this is called host report) and support of report type 1 (t=
his has been called relam report but people argued it should
 better be called realm routed request report).


 


Whether or=
 not we need in addition to type 0 and type 1 (or as a replacement of type =
1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There are =
a lot of open questions  with regard to #55 and I have not seen a conc=
lusion.


Where I ha=
ve seen a conclusion is issue #34 and that is inline with option 3).=



 


Unless we =
conclude on #55, or decide to re-open #34, option 3) is what should go in t=
he -02 draft.


 


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulrich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan wrote:<=
/p>





Ulrich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I don̵=
7;t know what happend in London.


Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 

















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2197DEMUMBX014nsnin_--


From nobody Tue Mar 25 05:10: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 2757A1A0085 for ; Tue, 25 Mar 2014 05:10:11 -0700 (PDT)
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 dqGH4diLzIDm for ; Tue, 25 Mar 2014 05:10:09 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id CCA291A0084 for ; Tue, 25 Mar 2014 05:10:09 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65416 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSQB8-0005SO-Uz for dime@ietf.org; Tue, 25 Mar 2014 05:10:08 -0700
Message-ID: <5331721A.5080502@usdonovans.com>
Date: Tue, 25 Mar 2014 07:10:02 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <4857132E-EB7E-4844-B9F4-81DD209E0705@nostrum.com> <5750EB10-9E07-4CD7-A122-CD5DDBD73003@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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/8sHs3gk7CfYCZtF0DFIsH9ATV6Q
Subject: Re: [Dime] DOIC Default Algorithm Specification
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, 25 Mar 2014 12:10:11 -0000

JJ,

I agree, when we do this, we will try to minimize impact to the draft, 
but there will be changes in the overall structure.  It will definitely 
be done in a way that does not change any of the normative requirements 
in the draft.

This will likely be the primary focus of the -03 version of the draft.

Regards,

Steve

On 3/25/14, 4:02 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi
>
> I agree with Ben to differentiate general statements which are algorithm independent from the ones particular to the default algorithm, otherwise it may be a source of ambiguities/ misinterpretations . Now is this statement grouping into a referenced section easy? I do not know. I hope this will not have a too large impact on the draft.
>
> Best regards
>
> JJacques
>
>
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoyé : vendredi 21 mars 2014 18:46
> À : Ben Campbell
> Cc : dime@ietf.org list
> Objet : Re: [Dime] DOIC Default Algorithm Specification
>
>
>
>
> On Mar 18, 2014, at 2:18 AM, Ben Campbell  wrote:
>
>> Hi,
>>
>> In re-reading dime-ovli, I noticed that the procedures for the "default" abatement algorithm are spread through several parts of the text. That's going to make life difficult down the road for a couple of reasons:
>>
>> 1) There's no easily referenced section that fully defines the algorithm. That will be a problem for other docs that want to talk about the algorithm (e.g. 3GPP specs), or even other sections in dime-ovli that want to mention the default algorithm by reference.
>>
>> 2) It makes extensibility harder, as it will be more difficult to define new algorithms, if they need to modify behavior that is spread throughout dime-ovli, rather than simply supersede a specific section of dime-ovli.
>>
>> I propose that we move all algorithm-specific behavior to its own section, and have any other sections that need to talk about the default algorithm reference that section rather than attempt to describe the behavior.
> That would work for me.
>
> - Jouni
>
>
>> Thanks!
>>
>> Ben.
>> _______________________________________________
>> 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 Tue Mar 25 05:21:30 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 F2A2F1A00D1 for ; Tue, 25 Mar 2014 05:20:56 -0700 (PDT)
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 xC8xh58pD37i for ; Tue, 25 Mar 2014 05:20:55 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1239C1A00BE for ; Tue, 25 Mar 2014 05:20:55 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65432 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSQLY-0000SQ-FM; Tue, 25 Mar 2014 05:20:52 -0700
Message-ID: <5331749F.5090200@usdonovans.com>
Date: Tue, 25 Mar 2014 07:20:47 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> <533081C6.9080103@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D205C@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D205C@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------090307040902010104050503"
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/LvxwtAn4a010FyWXQqvkP6M3JrI
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 12:20:57 -0000

This is a multi-part message in MIME format.
--------------090307040902010104050503
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ulrich,

Please see inline.

Steve

>          Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>
>          request of application app-id containing an OC-Supported-Features AVP
>
>          indicating support of the Abatement Algorithm Alg (which the reporting
>
>          node selects) while being overloaded, unless such OCS already exists.
>
> SRD> I would think the reporting node would create the OCS when it 
> determines it needs a reduction, independent when it receives requests 
> from various reacting nodes.
>  when not receiving requests, there is no need for reduction; 
> the need of reduction is determined when a request is received.
>
> Furthermore: If the reporting node determines that it needs a 
> reduction independently from a received request, which Algorithm would 
> it select? 
>
SRD2> You are correct that the algorithm can't be selected until the 
request arrives.  My point was that there would be state indicating the 
reporting node is overloaded already in place.
>
>   
>   
>      Reporting nodes delete an OCS when it expires.
>
> SRD> Or when it explicitly sends an OLR with validity duration of zero.
>
>  no. Let me give an example:
>
> Server S has an OCS identified by the pair (Application x, Loss) with 
> the content: Sequence number =5, duration= 30 sec/expiry time= 
> 9:45:59, percentage =10%.
>
> At 9:45:30 Client C1 sends an application x request to S and gets back 
> an OLR indicating 10% for 30 sec.
>
> At 9.45:57 Client C2 send an application x request to S and gets back 
> an OLR indicating 10% for 30sec.
>
> At 9:45:58 S decides that it is no longer overloaded. It therefore 
> updates the OCS to contain: sequence number=6, duration = 0sec/expiry 
> time= 9:46:30, percentage =0%.
>
> At 9:45:59 C1 sends an application x request to S and gets back the 
> explicit OLR with validity duration of zero. S must not delet the OCS 
> at this time.
>
> At 9:46:01 C2 sends an application x request to S and (because the OCS 
> was not deleted in the previous step) gets back the explicit OLR with 
> validity duration of zero. If the OCS was deleted in the previous step 
> C2 would continue throttling until 9:46:27.
>
SRD> This is a good description of the need to keep the state in the 
server until it times out.  Thanks.
>
>
>
>   
>   
>      Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>      need to modify the requested amount of application app-id traffic reduction.
>   
> Ulrich
>   
>   
> _______________________________________________
> DiME mailing list
> DiME@ietf.org  
> https://www.ietf.org/mailman/listinfo/dime
>   
>


--------------090307040902010104050503
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

    

    Please see inline.

    

    Steve

    

     
    

      

        

          
    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a

          
    request of application app-id containing an OC-Supported-Features AVP

          
    indicating support of the Abatement Algorithm Alg (which the reporting

          
    node selects) while being overloaded, unless such OCS already exists.

        

        
SRD> I would think
            the reporting node would create the OCS when it determines
            it needs a reduction, independent when it receives requests
            from various reacting nodes. 
            

          <Ulrich>
            when not receiving requests, there is no need for reduction;
            the need of reduction is determined when a request is
            received.

        
Furthermore:
            If the reporting node determines that it needs a reduction
            independently from a received request, which Algorithm would
            it select? </Ulrich>

      

    

    SRD2> You are correct that the algorithm can't be selected until
    the request arrives.  My point was that there would be state
    indicating the reporting node is overloaded already in place. 

    

      

        

        
 

        
 

        
    Reporting nodes delete an OCS when it expires.

        
SRD> Or when it explicitly sends an OLR
          with validity duration of zero.

        
<Ulrich> no. Let me give an example:

        
Server S has an OCS identified by the pair
            (Application x, Loss) with the content: Sequence number =5,
            duration= 30 sec/expiry time= 9:45:59, percentage =10%.

        
At 9:45:30 Client C1 sends an application x
            request to S and gets back an OLR indicating 10% for 30 sec.

        
At 9.45:57 Client C2 send an application x
            request to S and gets back an OLR indicating 10% for 30sec.

        
At 9:45:58 S decides that it is no longer
            overloaded. It therefore updates the OCS to contain:
            sequence number=6, duration = 0sec/expiry time= 9:46:30,
            percentage =0%.

        
At 9:45:59 C1 sends an application x request to
            S and gets back the explicit OLR with validity duration of
            zero. S must not delet the OCS at this time.

        
At 9:46:01 C2 sends an application x request to
            S and (because the OCS was not deleted in the previous step)
            gets back the explicit OLR with validity duration of zero.
            If the OCS was deleted in the previous step C2 would
            continue throttling until 9:46:27.</Ulrich>

      

    

    SRD> This is a good description of the need to keep the state in
    the server until it times out.  Thanks.

    

      

        

        


            

            

        
 

        
 

        
    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the

        
    need to modify the requested amount of application app-id traffic reduction.

        
 

        
Ulrich

        
 

        
 

        
_______________________________________________

        
DiME mailing list

        
DiME@ietf.org

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

        
 

        
 

      

    

    

  


--------------090307040902010104050503--


From nobody Tue Mar 25 05:39: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 1BDAC1A00DD for ; Tue, 25 Mar 2014 05:38:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 MNJaPtC3WvIj for ; Tue, 25 Mar 2014 05:38:25 -0700 (PDT)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C03CE1A00BE for ; Tue, 25 Mar 2014 05:38:24 -0700 (PDT)
Received: by mail-la0-f47.google.com with SMTP id y1so307859lam.6 for ; Tue, 25 Mar 2014 05:38:22 -0700 (PDT)
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=wq5gBS23WupPq/2NquoxePRYORh1qEoNun/RxjZQ+N4=; b=owHnL5jcPtJoxoligGxc/3ZCa4TcZ8LNvWfGMQt3igDdsRRri7LgWIfA3MwdJ+iR6m /dKVNa2o7WSFy8ZfrYp3si+/yGK7u+nh7MjHU02F+ta0PcahYWtxxg1xTvMoPJFuflqk UTAu5t3XgmVQF+E9BMnrIwfIcOQCsAxIai8PjPgIxK92/p8uP7qX6xagyToHJB9KTOLp ePP3HzxkYhyVuMES6xsyDY0CrWDsJGIeIk7JSdX3iT4nkOlCaNfSOZQ7BHCbWcFkUi68 UE0eMHm8wdOhW7cE36i8rRkGlNPE7kEy0wE0ba/LQvJdotlv1Ahc0rBr2WcnDm+WjxKw DNVw==
X-Received: by 10.112.51.202 with SMTP id m10mr137342lbo.63.1395751102845; Tue, 25 Mar 2014 05:38:22 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:fdd8:8cad:e27:1d18? ([2001:1bc8:101:f101:fdd8:8cad:e27:1d18]) by mx.google.com with ESMTPSA id q4sm11693556lbh.20.2014.03.25.05.38.15 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 05:38:16 -0700 (PDT)
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: 
Date: Tue, 25 Mar 2014 14:38:17 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <98C36821-0110-4A8C-9CFB-FDC2C1D88768@gmail.com>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>   <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com> <53302397.7020006@usdonovans.com> 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/YNigAVuTJMZQ8jBem2YidJJh0NA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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, 25 Mar 2014 12:38:28 -0000

Hi,

On Mar 25, 2014, at 10:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" =
 wrote:

> Hi
> =20
> Effectively we should be cautious with M bit for AVPS inside a grouped =
AVP such as OC-OLR AVP, and as Ben proposed, I am also rather in favour =
of not using the Mbit inside a DOC group AVP, including application =
specific AVPs.
> =20
> In the thread discussion it  was mentioned the use of OC-feature and  =
also relay node that is application  independent.
> =20
> Hereafter my  case:
> =20
> After our IETF draft having become a RFC, IETF standardizes an =
extension,  which adds a new flag in OC-feature AVP. This extension is =
not specific to a Diameter application
> -          A  relay oonly supporting our IETF draft, will observe that =
OC-feature value does not fit to what it knows. I expect here that relay =
will do nothing about DOC as the meaning of the OC-OLR may be different =
of what it knows. OK? I als othink it applies to a proxy DA

I would expect the behaviour be like this.. otherwise there will be =
issues.

> -          If the relay supports the extension, it will recognize  the =
OC-feature value and will behave according this value. So OK. Should we =
have some text in the IETF draft?

By default relays should not even look into DOIC stuff.. since relays =
are only supposed to route requests. But we cannot prohibit some relay =
implementations doing "enhanced" processing on requests. For that part I =
think there is no need to say anything.

> =20
> Now, this is a Diameter  application (eg a 3GPP one) that will define =
an extension for its own use . Is this application is allowed to use =
bits of OC-Features AVP to indicate this application specific feature =
(or even algorithm). How to avoid the application to use the same bits =
as future IETF extensions? Will we be driven to use=20

If you define a new application, you are still supposed to register your =
feature bits. Otherwise, there will be a mess. I see no reason why =
someone would like to go this road other than for the pleasure of having =
incompatibility issues to fight with..

> another OC-Application-Specific-Feature AVP, or have bits  in =
OC-Feature reserved for application specific extensions., or other?  A =
constraint is that  a relay (application unaware) should nevertheless  =
detect there is application specific extensions (without knowing their =
meaning) so to not do DOC actions. =20

The process of registering a new feature flag is made so easy with IANA =
that there should not be a reason not to do so. Feature flags are not =
application specific per se, or that is how its use was designed to =
begin with. They could be but then relays definitely should not look =
into those..


> =20
> I understand this is not directly linked to our immediate scope, but =
we may try  to be future proof allowing application specific extensions =
and Relay node supporting the generic DOC.

If you want to be on the safe ground, you do these things with proxies.

> =20
> Do you agree on this potential issue? If yes may be to analyse what to =
add in the IETF draft to be future proof.

I agree there will be issues if someone deliberately starts doing weird =
stuff with relays and also fooling around with feature flags.. We are =
already on the edge with feature flags in general, since they allow =
adding new functionality to applications without doing how Diameter was =
designed to do that - getting a new application-id.

- Jouni


> =20
> Best regards
> =20
> JJacques =20
>  =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : lundi 24 mars 2014 13:23
> =C0 : dime@ietf.org
> Objet : Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
> =20
> Do we have proposed wording to be included in the -02 version of the =
draft on this issue?
>=20
> Steve
>=20
> On 3/22/14 12:36 AM, Ben Campbell wrote:
> =20
> On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  =
wrote:
> =20
> =20
> Ben,
> =20
> On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:
> =20
> =20
> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  =
wrote:
> =20
> =20
> Consider the case of a Diameter _relay_ that supports DOIC. It is not =
aware of any application-specific rules about m-bits. It receives an =
OC-Supported-Features or an OC-OLR that has a mandatory AVP that it =
doesn't recognize. Logically, it should probably ignore the entire =
OC-Supported-Features or OC-OLR grouped-AVP. But it won't. Being a =
relay, it's not going to reject the message. Rather it's likely to try =
to apply the OC-Supported-Features or OC-OLR incorrectly.
> =20
> RFC6733 also says that relays perform not do any application level
> processing. If a relay supports DOIC and does something goofy that
> is left for implementation, we should no care nor try to fix the
> situation. The implementation is already bending the rules in that
> case.
> =20
> Hi Jouni,
> =20
> I'm not talking about the case of the relay doing something goofy. =
Rather, I mean when a relay tries to perform basic DOIC processing of an =
OLR as described in the base DOIC spec, but ignores some extension AVP =
that changes the meaning of the OLR. It's not bending the rules so much =
as failing to recognize someone else changing the rules.
> =20
> Ah, I see your point. But if one adds AVPs to the default algorithm
> that change he behaviour and does not a) declare it as a new algorithm
> or b) add a new supported feature flag, then that is a proprietary
> (broken) implementation. We cannot really protect against those..
> =20
> I think that's reasonable. My original point was that extensions =
should not try to use the m-bit for that purpose. If they have something =
that is not backwards compatible, it needs to be negotiated in the =
feature vector.
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Mar 25 05:39:35 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 BA15D1A00DD for ; Tue, 25 Mar 2014 05:38:54 -0700 (PDT)
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 6-JsS4UnELlY for ; Tue, 25 Mar 2014 05:38:48 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 46A471A00BE for ; Tue, 25 Mar 2014 05:38:48 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:65446 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSQco-00045N-7u; Tue, 25 Mar 2014 05:38:42 -0700
Message-ID: <533178CD.9030707@usdonovans.com>
Date: Tue, 25 Mar 2014 07:38:37 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Shishufeng (Susan)" ,  Jouni Korhonen 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------090907050303070002050100"
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/eX94WJpYQjlkS4umS5gV88g2TC8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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, 25 Mar 2014 12:38:55 -0000

This is a multi-part message in MIME format.
--------------090907050303070002050100
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Susan,

We have not been following a process of determining consensus based on a 
majority of companies expressing a preference.  It is also the case 
that, in the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which 
side would actually have a majority.

We might need to change our process to speed things up, but right now we 
have been striving for true consensus where everyone agrees. Note that 
this doesn't mean everyone agrees with the technical reasoning behind 
the decision.  There have been many cases where agreement is reached 
because it was more important to get something finished then to win a 
technical argument.

If we can't start moving a little faster then we will likely need to 
change to rough consensus, where the measure is that most everyone 
agrees.  However, in the IETF, even this is not a voting process. If 
things are close to 50-50 in opinions then the correct process is to 
continue to discuss the technical merits of each alternative until rough 
consensus is reached.

Regards,

Steve

On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
>
> Hi Steve,
>
> As I know, majority companies expressed preference to keep the AVP as 
> optional and keep the texts as they are. You have preference to have 
> it explicitly but ok with either way. That's how I assumed we reached 
> consensus.
>
> Best Regards,
>
> Susan
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Monday, March 24, 2014 8:26 PM
> *To:* Shishufeng (Susan); Jouni Korhonen
> *Cc:* dime@ietf.org
> *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
> Susan,
>
> We are in the middle of the discussion and have not yet reached consensus.
>
> I agree with Jouni on making it explicit.  Either way, we should try 
> to make a decision quickly.
>
> Steve
>
> On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:
>
>     Hello Jouni,
>
>       
>
>     I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft.
>
>       
>
>     Best Regards,
>
>     Susan
>
>       
>
>       
>
>     -----Original Message-----
>
>     From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]
>
>     Sent: Saturday, March 22, 2014 10:38 AM
>
>     To: Steve Donovan
>
>     Cc:dime@ietf.org  
>
>     Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>       
>
>       
>
>     Lets have it explicit then. Use '<' and '>' to make the position fixed.
>
>       
>
>     - Jouni
>
>       
>
>     On Mar 19, 2014, at 1:29 AM, Steve Donovan    wrote:
>
>       
>
>         I'm ok with either direction but generally lean toward being explicit.
>
>           
>
>         Do we have other opinions?
>
>           
>
>         Steve
>
>         On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
>
>             Hello,
>
>             I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.
>
>             This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.
>
>             If there is consensus on this, I will go with this.
>
>             Best regards
>
>             /MCruz
>
>               
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>
>             Sent: martes, 18 de marzo de 2014 17:47
>
>             To:dime@ietf.org  
>
>             Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>               
>
>             All,
>
>               
>
>             Do we have consensus that the OC-Report-Type AVP is required?
>
>               
>
>             If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.
>
>               
>
>             Jouni,
>
>               
>
>             How do we indicate a fixed position for an AVP?
>
>               
>
>             I presonally don't see this as critical but we can add this requirement if there is consensus.
>
>               
>
>             Regards,
>
>               
>
>             Steve
>
>               
>
>             On 2/28/14 10:27 AM, Jouni Korhonen wrote:
>
>               
>
>             Hi,
>
>               
>
>             How having the AVP could be less error prone if it has a default
>
>             value and the receiver knows exactly how to proceed when the AVP is
>
>             not present?
>
>               
>
>             If a node does not include it when it should, the implementation is
>
>             broken. Wouldn't a broken node be able to put wrong report type into
>
>             the AVP even if the AVP is mandatory?
>
>               
>
>             Anyway, if it is my statement keeping issue #54 still open, consider
>
>             it resolved from my side. I am OK making the OC-Report-Type AVP as
>
>             required/mandatory AVP. Should we also consider it having a fixed
>
>             position just after the OC-Sequence-Number AVP as well since it is
>
>             going to in every OC-OLR?
>
>               
>
>             - Jouni
>
>               
>
>               
>
>               
>
>             On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome    wrote:
>
>               
>
>               
>
>             Hello all,
>
>               
>
>             I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
>
>               
>
>             I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
>
>               
>
>             Best regards
>
>             /MCruz
>
>               
>
>             -----Original Message-----
>
>             From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>
>             Sent: viernes, 14 de febrero de 2014 23:13
>
>             To: Jouni Korhonen
>
>             Cc:dime@ietf.org  
>
>             Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>               
>
>             I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
>
>               
>
>             On Feb 13, 2014, at 6:05 AM, Jouni Korhonen    wrote:
>
>               
>
>               
>
>             Agree that it is a small optimization, which I put there because at
>
>             the beginning there seemed to be a lot of worry on every extra AVP
>
>             ;-)
>
>               
>
>             I prefer having the AVP optional but with a default value just like
>
>             it is now. We have the same for the reduction percentage and the
>
>             validity time as well.
>
>               
>
>             - Jouni
>
>               
>
>             On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"    wrote:
>
>               
>
>             Hi Mcruz
>
>               
>
>             The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference.
>
>             We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
>
>               
>
>             Best regards
>
>               
>
>             JJacques
>
>               
>
>               
>
>               
>
>               
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de
>
>             lionel.morand@orange.com    Envoyé : mercredi 12 février 2014 15:46 À :
>
>             dime@ietf.org  ;maria.cruz.bartolome@ericsson.com    Objet : Re: [Dime]
>
>             [dime] #54: OC-Report-Type as mandatory AVP
>
>               
>
>             Hi Maria Cruz,
>
>               
>
>             I'm assuming that you mean "required" instead of "mandatory", right?
>
>               
>
>             So instead of:
>
>               
>
>             OC-OLR ::= < AVP Header: TBD2 >
>
>                         < OC-Sequence-Number >
>
>                         [ OC-Report-Type ]
>
>                         [ OC-Reduction-Percentage ]
>
>                         [ OC-Validity-Duration ]
>
>                       * [ AVP ]
>
>               
>
>             You would prefer:
>
>               
>
>             OC-OLR ::= < AVP Header: TBD2 >
>
>                         < OC-Sequence-Number >
>
>                         { OC-Report-Type }
>
>                         [ OC-Reduction-Percentage ]
>
>                         [ OC-Validity-Duration ]
>
>                       * [ AVP ]
>
>               
>
>             And I'm fine with this proposal.
>
>               
>
>             Cheers,
>
>               
>
>             Lionel
>
>               
>
>             -----Message d'origine-----
>
>             De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue
>
>             tracker Envoyé : mercredi 12 février 2014 15:26 À :
>
>             maria.cruz.bartolome@ericsson.com    Cc :dime@ietf.org    Objet : [Dime]
>
>             [dime] #54: OC-Report-Type as mandatory AVP
>
>               
>
>             #54: OC-Report-Type as mandatory AVP
>
>               
>
>             Now in chapter 4.6:
>
>               
>
>               The default value of the OC-Report-Type AVP is 0 (i.e. the host
>
>             report).
>
>               
>
>             This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
>
>               
>
>             --
>
>             -----------------------------------------------+---------------------
>
>             -----------------------------------------------+---
>
>             -----------------------------------------------+---
>
>             Reporter:maria.cruz.bartolome@ericsson.com     |      Owner:  MCruz
>
>                Type:  defect                             |  Bartolomé
>
>             Priority:  major                              |     Status:  new
>
>             Component:  draft-docdt-dime-ovli              |  Milestone:
>
>             Severity:  Active WG Document                 |    Version:  1.0
>
>                                                          |   Keywords:
>
>             -----------------------------------------------+---------------------
>
>             -----------------------------------------------+---
>
>             -----------------------------------------------+---
>
>               
>
>             Ticket URL:  
>
>             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
>
>               
>
>               
>
>           
>
>         _______________________________________________
>
>         DiME mailing list
>
>         DiME@ietf.org  
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>       
>
>       
>
>       
>


--------------090907050303070002050100
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Susan,

    

    We have not been following a process of determining consensus based
    on a majority of companies expressing a preference.  It is also the
    case that, in the IETF, companies do not contribute, individuals
    contribute.

    

    In addition, if we did take a "vote" on this one, I'm not sure which
    side would actually have a majority.

    

    We might need to change our process to speed things up, but right
    now we have been striving for true consensus where everyone agrees. 
    Note that this doesn't mean everyone agrees with the technical
    reasoning behind the decision.  There have been many cases where
    agreement is reached because it was more important to get something
    finished then to win a technical argument.

    

    If we can't start moving a little faster then we will likely need to
    change to rough consensus, where the measure is that most everyone
    agrees.  However, in the IETF, even this is not a voting process. 
    If things are close to 50-50 in opinions then the correct process is
    to continue to discuss the technical merits of each alternative
    until rough consensus is reached.

    

    Regards,

    

    Steve

    

    
On 3/25/14, 2:00 AM, Shishufeng (Susan)
      wrote:

    

    

      
      
      
      

        
Hi Steve,

        
 

        
As I know, majority companies expressed
            preference to keep the AVP as optional and keep the texts as
            they are. You have preference to have it explicitly but ok
            with either way. That’s how I assumed we reached consensus.

        
 

        
Best Regards,

        
Susan

        
 

        

          

            
From: Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Monday, March 24, 2014 8:26 PM

                To: Shishufeng (Susan); Jouni Korhonen

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        
Susan,

            

            We are in the middle of the discussion and have not yet
            reached consensus.

            

            I agree with Jouni on making it explicit.  Either way, we
            should try to make a decision quickly.

            

            Steve

        

          
On 3/23/14 10:59 PM,
              Shishufeng (Susan) wrote:

        

        

          
Hello Jouni,

          
 

          
I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 

          
 

          
Best Regards,

          
Susan

          
 

          
 

          
-----Original Message-----

          
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

          
Sent: Saturday, March 22, 2014 10:38 AM

          
To: Steve Donovan

          
Cc: dime@ietf.org

          
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

          
 

          
 

          
Lets have it explicit then. Use '<' and '>' to make the position fixed.

          
 

          
- Jouni

          
 

          
On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

          
 

          

            
I'm ok with either direction but generally lean toward being explicit.

            
 

            
Do we have other opinions?  

            
 

            
Steve

            
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

            

              
Hello,

              
I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.

              
This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.

              
If there is consensus on this, I will go with this.

              
Best regards

              
/MCruz

              
 

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

              
Sent: martes, 18 de marzo de 2014 17:47

              
To: dime@ietf.org

              
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

              
 

              
All,

              
 

              
Do we have consensus that the OC-Report-Type AVP is required?

              
 

              
If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.

              
 

              
Jouni,

              
 

              
How do we indicate a fixed position for an AVP?  

              
 

              
I presonally don't see this as critical but we can add this requirement if there is consensus.

              
 

              
Regards,

              
 

              
Steve

              
 

              
On 2/28/14 10:27 AM, Jouni Korhonen wrote:

              
 

              
Hi,

              
 

              
How having the AVP could be less error prone if it has a default 

              
value and the receiver knows exactly how to proceed when the AVP is 

              
not present?

              
 

              
If a node does not include it when it should, the implementation is 

              
broken. Wouldn't a broken node be able to put wrong report type into 

              
the AVP even if the AVP is mandatory?

              
 

              
Anyway, if it is my statement keeping issue #54 still open, consider 

              
it resolved from my side. I am OK making the OC-Report-Type AVP as 

              
required/mandatory AVP. Should we also consider it having a fixed 

              
position just after the OC-Sequence-Number AVP as well since it is 

              
going to in every OC-OLR?

              
 

              
- Jouni

              
 

              
 

              
 

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

              
 

              
 

              
Hello all,

              
 

              
I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.

              
 

              
I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.

              
 

              
Best regards

              
/MCruz

              
 

              
-----Original Message-----

              
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

              
Sent: viernes, 14 de febrero de 2014 23:13

              
To: Jouni Korhonen

              
Cc: dime@ietf.org

              
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

              
 

              
I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.

              
 

              
On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

              
 

              
 

              
Agree that it is a small optimization, which I put there because at 

              
the beginning there seemed to be a lot of worry on every extra AVP 

              
;-)

              
 

              
I prefer having the AVP optional but with a default value just like 

              
it is now. We have the same for the reduction percentage and the 

              
validity time as well.

              
 

              
- Jouni

              
 

              
On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:

              
 

              
Hi Mcruz

              
 

              
The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 

              
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.

              
 

              
Best regards

              
 

              
JJacques

              
 

              
 

              
 

              
 

              
-----Message d'origine-----

              
De : DiME [mailto:dime-bounces@ietf.org] De la part de 

              
lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À :

              
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 

              
[dime] #54: OC-Report-Type as mandatory AVP

              
 

              
Hi Maria Cruz,

              
 

              
I'm assuming that you mean "required" instead of "mandatory", right?

              
 

              
So instead of:

              
 

              
OC-OLR ::= < AVP Header: TBD2 >

              
           < OC-Sequence-Number >

              
           [ OC-Report-Type ]

              
           [ OC-Reduction-Percentage ]

              
           [ OC-Validity-Duration ]

              
         * [ AVP ]

              
 

              
You would prefer:

              
 

              
OC-OLR ::= < AVP Header: TBD2 >

              
           < OC-Sequence-Number >

              
           { OC-Report-Type }

              
           [ OC-Reduction-Percentage ]

              
           [ OC-Validity-Duration ]

              
         * [ AVP ]

              
 

              
And I'm fine with this proposal.

              
 

              
Cheers,

              
 

              
Lionel

              
 

              
-----Message d'origine-----

              
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 

              
tracker Envoyé : mercredi 12 février 2014 15:26 À :

              
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 

              
[dime] #54: OC-Report-Type as mandatory AVP

              
 

              
#54: OC-Report-Type as mandatory AVP

              
 

              
Now in chapter 4.6:

              
 

              
 The default value of the OC-Report-Type AVP is 0 (i.e. the host  

              
report).

              
 

              
This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.

              
 

              
--

              
-----------------------------------------------+---------------------

              
-----------------------------------------------+---

              
-----------------------------------------------+---

              
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

              
  Type:  defect                             |  Bartolomé

              
Priority:  major                              |     Status:  new

              
Component:  draft-docdt-dime-ovli              |  Milestone:

              
Severity:  Active WG Document                 |    Version:  1.0

              
                                            |   Keywords:

              
-----------------------------------------------+---------------------

              
-----------------------------------------------+---

              
-----------------------------------------------+---

              
 

              
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>

              
dime <http://tools.ietf.org/wg/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

              
 

              
 

            

            
 

            
_______________________________________________

            
DiME mailing list

            
DiME@ietf.org

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

          

          
 

          
 

          
 

        

        
 

      

    

    

  


--------------090907050303070002050100--


From nobody Tue Mar 25 06:48:49 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 224401A011B for ; Tue, 25 Mar 2014 06:48:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 o0uW9iE_95Mi for ; Tue, 25 Mar 2014 06:48:44 -0700 (PDT)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4E43C1A0115 for ; Tue, 25 Mar 2014 06:48:44 -0700 (PDT)
Received: by mail-lb0-f174.google.com with SMTP id u14so384653lbd.33 for ; Tue, 25 Mar 2014 06:48:42 -0700 (PDT)
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=ZJURgrN9Ak1iAc2Jz5L0gKHeJdPB/w8R/4qcyQffCkU=; b=Db5Rbe25lmdRn8pa1shqW6S7VwpehQu6dJkIDGlW8rTNdXaYm/0z89KESP/++EecMV l5NsA0//pKiHY51rRzLAi4Zm7mRvuQLqtQn5N1woAv0hg2ANWECryH4kjyQ2WWQAApGG UindCenO3x1zWevEJZ/5I8/H8hXnmE1rkspe6mg5lL8grAuVOcJvPfOwUhWgA7+70y8R 7f+7uurDCB9UvmnsYg3moiWytzlbU4+r86j1DWJ/xrnR6X7KkXopfeOqyNv0KYXJ/Kns ZKLcjsf+dlKivRWmemHE7uBB3G1TeaoJRfHDZowwAHBK92BvGcsbHDuNAV+iwA9zaq4f AMCA==
X-Received: by 10.152.87.14 with SMTP id t14mr531693laz.52.1395755322383; Tue, 25 Mar 2014 06:48:42 -0700 (PDT)
Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id qa7sm11803270lbb.6.2014.03.25.06.48.36 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 06:48:36 -0700 (PDT)
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: <533097D1.3090803@usdonovans.com>
Date: Tue, 25 Mar 2014 15:48:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <39DF4595-FB8E-4250-BB1E-62AF45D87528@gmail.com>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lc6Bcily2hXB7z88ngCSqJmO_o8
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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, 25 Mar 2014 13:48:47 -0000

Fine with me.

On Mar 24, 2014, at 10:38 PM, Steve Donovan  =
wrote:

> Here's some proposed wording that will hopefully let us close this =
issue:
>=20
> Regards,
>=20
> Steve
>=20
> -----
>=20
> Section 4.5., paragraph 3 -=20
>=20
> Current -02 wording:
>=20
> As a general guidance for implementations it is RECOMMENDED never to
>    let any overload report to timeout.  Following to this rule, an
>    overload endpoint should explicitly signal the end of overload
>    condition and not rely on the expiration of the validity time of =
the
>    overload report in the reacting node.  This is achieved by sending =
an
>    updated overload report (meaning it must contain a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
> Proposed wording:
>=20
>    A reporting node SHOULD explicitly signal the end of overload
>    condition in a timely manner.  This is achieved by sending an
>    updated overload report (meaning the OLR contains a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
>   A reacting node MUST invalidate and remove an overload report that
>   expires without an explicit overload report containing an =
OC-Validity-Duration
>   value set to zero ("0").
>=20
>=20
> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>> Fine with me.
>>=20
>> - Jouni
>>=20
>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome=20
>> 
>>  wrote:
>>=20
>>=20
>>> Ben, Nirav,
>>>=20
>>> I follow same argumentation.
>>> Regards
>>> /MCruz
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Nirav Salot (nsalot)
>>> Sent: martes, 11 de febrero de 2014 11:23
>>> To: Ben Campbell; Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting =
overload reports expire
>>>=20
>>> Ben,
>>>=20
>>> I resonate with your thinking below.
>>>=20
>>> Regards,
>>> Nirav.
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Ben Campbell
>>> Sent: Monday, February 10, 2014 9:54 PM
>>> To: Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting =
overload reports expire
>>>=20
>>>=20
>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen=20
>>> 
>>>  wrote:
>>>=20
>>>=20
>>>> My reasoning for explicit termination was that knowing the=20
>>>> implementation folks they will let overload conditions expire =
unless advised otherwise.
>>>> And having unnecessary stuff hanging around waiting for a cleanup =
is=20
>>>> not a good thing in general. But I am open here for other options..
>>>>=20
>>>>=20
>>> I think it's reasonable to say that a reporting node should =
terminate an overload condition in a timely manner. But if it's about to =
expire anyway, then expiration might be just as timely as an explicit =
report.=20
>>>=20
>>> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Mar 25 06:49:31 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 86BC61A0115 for ; Tue, 25 Mar 2014 06:49:28 -0700 (PDT)
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 t2Fc9Xj-I8SV for ; Tue, 25 Mar 2014 06:49:25 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 66E2E1A011E for ; Tue, 25 Mar 2014 06:49:25 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:58681 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSRjC-0006Lh-F6; Tue, 25 Mar 2014 06:49:23 -0700
Message-ID: <5331895D.5050500@usdonovans.com>
Date: Tue, 25 Mar 2014 08:49:17 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060909010800000508090106"
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/S8ZEykhqvLEMMl-cgljULH0xcCo
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 13:49:28 -0000

This is a multi-part message in MIME format.
--------------060909010800000508090106
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

I mean going backwards from where I thought we were after the London
meeting.

We are clearly out of sync but hopefully we can fix that.

Here's my understanding of the status of #23 and #55.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to
realm-routed-reports (RRR).
 - Discussions were ongoing as to the need for both realm reports and
RRR reports.

#55 status:
  - Agreement on adding Realm reports based on the definition that realm
reports apply to all traffic sent to the realm.
  - Limited discussion on the interaction between the new realm reports
and the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
  - Ben expressed the strongest concern with this plan.  Steve and Ben
took action to discuss and come back with a recommendation. 

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types -
host and realm, with realm having the new definition.

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and
revisit later is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to
support realm reports.  Others might have a different opinion.

Summary:
  - I believe we have three options:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan
coming out of the London meeting
   3) Support host, RRR and Realm reports

Regards,

Steve


On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> I don't think we are going backwards (we may be out of synch though)
>
>  
>
> Can you please summarize the status of #23 and #55.
>
>  
>
> Ulrich
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Monday, March 24, 2014 7:38 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Ok, we are going backwards on this one.
>
> I did not include option three because we had moved past that option
> in our discussions, both on the list (I thought), and in the meeting.
>
> I believe that we had come to rough consensus on the need for a realm
> report and the only remaining issue was whether we also included the
> RRR report type.
>
> At this point, the only option is to leave all of the issues related
> to the report types open and attempt to resolve them in the -03 draft.
>
> Steve
>
> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>      
>
>     I do not agree.
>
>      
>
>     We should still have the option
>
>     3) support report type 0 (this is called host report) and support
>     of report type 1 (this has been called relam report but people
>     argued it should better be called realm routed request report).
>
>      
>
>     Whether or not we need in addition to type 0 and type 1 (or as a
>     replacement of type 1) a
>     realm-no-matter-whether-destination-host-is present-or-not report
>       is an open issue (see #55).
>
>     There are a lot of open questions  with regard to #55 and I have
>     not seen a conclusion.
>
>     Where I have seen a conclusion is issue #34 and that is inline
>     with option 3).
>
>      
>
>     Unless we conclude on #55, or decide to re-open #34, option 3) is
>     what should go in the -02 draft.
>
>      
>
>      
>
>     Ulrich
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>     Steve Donovan
>     *Sent:* Monday, March 24, 2014 2:57 PM
>     *To:* dime@ietf.org 
>     *Subject:* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Ulrich,
>     All,
>
>     We have two options for the -02 draft.
>
>     1) Support Host and Realm as proposed below, removing RRR reports.
>     2) Support Host, Realm and RRR reports.
>
>     The default plan is to go with option 1 in the -02 draft, as that
>     was the proposal that came out of the meeting in London.  RRR
>     reports can be added back in if and when we are convinced of the
>     need. 
>
>     If there are strong objections to this then I will update the -02
>     draft to reflect all three report types.
>
>     I plan to make these updates Wednesday morning, Dallas, Texas time.
>
>     Either way I do not expect we will have agreed to wording on the
>     interaction between the report types when a reacting node has
>     multiple report types, all of which apply to individual requests. 
>     This will need to be addressed in the -03 draft.
>
>     Regards,
>
>     Steve
>
>     On 3/21/14 4:05 PM, Steve Donovan wrote:
>
>         Ulrich,
>
>         The discussion should be captured in the minutes to the
>         meeting.  I wasn't able to find them posted yet.
>
>         Jouni, Lionel, what is the status of the minutes for the meeting?
>
>         My reading of emails prior to the London meeting is different
>         from yours.  I believe we had come to the conclusion that we
>         needed host and realm (with the definition of realm as
>         outlined below).  We were still discussing the need for
>         Realm-Routed-Request reports.
>
>         Regards,
>
>         Steve
>
>         On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>             Steve,
>
>              
>
>             I don't know what happend in London.
>
>             Can you please summarize the technical reasons that led to
>             the London agreement.
>
>             E-mail discussions prior to London have clearly directed
>             towards a report type that requests throttling of realm
>             routed request messages (i.e. not containing a destination
>             host) rather than a report type that requests throttling
>             of messages routed towards a realm (no matter whether they
>             contain a destination host or not).   
>
>              
>
>             Ulrich
>
>              
>
>             *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>             *ext Steve Donovan
>             *Sent:* Friday, March 21, 2014 3:33 PM
>             *To:* dime@ietf.org 
>             *Subject:* [Dime] Resolution on action to discuss the need
>             for Realm-Routed-Reports
>
>              
>
>             All,
>
>             Ben and I took the action item to discuss the need for the
>             Realm-Routed-Reports (RRR) report type.
>
>             As you may recall, the consensus coming out of the DIME WG
>             meeting in London was to support two report types:
>
>             - Host -- Impacting requests with a Destination-Host AVP
>             matching the host in the overload report (with the host
>             implicitly determined from the Origin-Host AVP of the
>             answer message carrying the overload report).
>
>             - Realm -- Impacting 100% of the requests with a
>             Destination-Realm AVP matching the realm in the overload
>             report (with the realm implicitly determine from the
>             Origin-Realm of the answer message carrying the overload
>             report).
>
>             The action Ben and I took was to come back with an opinion
>             on whether RRR reports should also be supported.
>
>             My summary of the discussion is that we recommend to NOT
>             include RRR reports in the current version of the base
>             DOIC draft. 
>
>             We still have some concerns with the granularity of
>             control enabled by having just the two report types but
>             the analysis of whether RRR reports are still needed can
>             occur independent of the base DOIC draft.  If there is a
>             determination that RRRs are needed in time to include in
>             the base draft then it can be considered at that time.
>
>             Based on this, I propose the following
>
>             - Resolution to issue #23 is to remove RRR reports from
>             the document.
>             - Resolution to issue #55 is to add Realm reports
>             (actually to redefine them per the above definition).
>             - Resolution to issue #57 is that it no longer applies (as
>             it deals with RRRs).
>
>             There is also need for text describing the interaction
>             between host and the realm reports.  I don't expect we
>             will have consensus on this wording prior to the -02 draft
>             being submitted.  To this end, I'll open a new issue to
>             deal with the need for wording on the interaction.
>
>             Regards,
>
>             Steve
>
>
>
>
>
>
>         _______________________________________________
>
>         DiME mailing list
>
>         DiME@ietf.org 
>
>         https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>  
>


--------------060909010800000508090106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      I mean going backwards from where I thought we were after the
      London meeting.

      

      We are clearly out of sync but hopefully we can fix that.

      

      Here's my understanding of the status of #23 and #55.

      

      Prior to London meeting:

      

      #23 status:

       - Agreement to change the name of existing realm reports to
      realm-routed-reports (RRR).

       - Discussions were ongoing as to the need for both realm reports
      and RRR reports.

      

      #55 status:

        - Agreement on adding Realm reports based on the definition that
      realm reports apply to all traffic sent to the realm.

        - Limited discussion on the interaction between the new realm
      reports and the existing host and RRR reports.

      

      After London meeting:

      

      #23 status:

        - Tentative agreement in London meeting to remove RRR reports.

        - Ben expressed the strongest concern with this plan.  Steve and
      Ben took action to discuss and come back with a recommendation.  

      

      #55 status:

        - No change

      

      Summary:

        - Tentative consensus reached to move forward with two report
      types - host and realm, with realm having the new definition.

      

      Current status:

      

      #23 status:

       - Change the name to RRR

       - Whether or not to remove RRR and revisit later or keep RRR and
      revisit later is an open issue.

      

      #55 status:

        - My opinion is that we have at least rough consensus on the
      need to support realm reports.  Others might have a different opinion.

      

      Summary:

        - I believe we have three options:

      

         1) Support host and RRR reports

         2) Support host and Realm reports -- This was the tentative
      plan coming out of the London meeting

         3) Support host, RRR and Realm reports

      

      Regards,

      

      Steve

      

      

    
    
On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
I don’t think we are going backwards (we may be
            out of synch though)

        
 

        
Can you please summarize the status of #23 and
            #55.

        
 

        
Ulrich

        
 

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Monday, March 24, 2014 7:38 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] Resolution on action to
                discuss the need for Realm-Routed-Reports

          

        

        
 

        
Ok, we are
          going backwards on this one.

          

          I did not include option three because we had moved past that
          option in our discussions, both on the list (I thought), and
          in the meeting.
          

          

          I believe that we had come to rough consensus on the need for
          a realm report and the only remaining issue was whether we
          also included the RRR report type.

          

          At this point, the only option is to leave all of the issues
          related to the report types open and attempt to resolve them
          in the -03 draft.

          

          Steve

        

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

        

        

          
Steve,

          
 

          
I
              do not agree.

          
 

          
We should still have the option
            

          
3) support report type 0 (this is called host
              report) and support of report type 1 (this has been called
              relam report but people argued it should better be called
              realm routed request report).

          
 

          
Whether or not we need in addition to type 0
              and type 1 (or as a replacement of type 1) a
              realm-no-matter-whether-destination-host-is present-or-not
              report   is an open issue (see #55).

          
There are a lot of open questions  with
              regard to #55 and I have not seen a conclusion.

          
Where I have seen a conclusion is issue #34
              and that is inline with option 3).

          
 

          
Unless we conclude on #55, or decide to
              re-open #34, option 3) is what should go in the -02 draft.

          
 

          
 

          
Ulrich

          
 

          

            

              
From: DiME [mailto:dime-bounces@ietf.org]
                  On Behalf Of ext Steve Donovan

                  Sent: Monday, March 24, 2014 2:57 PM

                  To: dime@ietf.org

                  Subject: Re: [Dime] Resolution on action to
                  discuss the need for Realm-Routed-Reports

            

          

          
 

          
Ulrich,

            All,

            

            We have two options for the -02 draft.

            

            1) Support Host and Realm as proposed below, removing RRR
            reports.

            2) Support Host, Realm and RRR reports.

            

            The default plan is to go with option 1 in the -02 draft, as
            that was the proposal that came out of the meeting in
            London.  RRR reports can be added back in if and when we are
            convinced of the need. 
            

            

            If there are strong objections to this then I will update
            the -02 draft to reflect all three report types.

            

            I plan to make these updates Wednesday morning, Dallas,
            Texas time.

            

            Either way I do not expect we will have agreed to wording on
            the interaction between the report types when a reacting
            node has multiple report types, all of which apply to
            individual requests.  This will need to be addressed in the
            -03 draft.

            

            Regards,

            

            Steve

          

            
On 3/21/14 4:05 PM, Steve Donovan
              wrote:

          

          

            
Ulrich,

              

              The discussion should be captured in the minutes to the
              meeting.  I wasn't able to find them posted yet.

              

              Jouni, Lionel, what is the status of the minutes for the
              meeting?

              

              My reading of emails prior to the London meeting is
              different from yours.  I believe we had come to the
              conclusion that we needed host and realm (with the
              definition of realm as outlined below).  We were still
              discussing the need for Realm-Routed-Request reports.

              

              Regards,

              

              Steve

            

              
On 3/21/14 10:09 AM, Wiehe, Ulrich
                (NSN - DE/Munich) wrote:

            

            

              
Steve,

              
 

              
I don’t know what happend in London.

              
Can you please summarize the technical
                  reasons that led to the London agreement.
                

              
E-mail discussions prior to London have
                  clearly directed towards a report type that requests
                  throttling of realm routed request messages (i.e. not
                  containing a destination host) rather than a report
                  type that requests throttling of messages routed
                  towards a realm (no matter whether they contain a
                  destination host or not).   

              
 

              
Ulrich

              
 

              

                

                  
From: DiME [mailto:dime-bounces@ietf.org]
                      On Behalf Of ext Steve Donovan

                      Sent: Friday, March 21, 2014 3:33 PM

                      To: dime@ietf.org

                      Subject: [Dime] Resolution on action to
                      discuss the need for Realm-Routed-Reports

                

              

              
 

              
All,

                

                Ben and I took the action item to discuss the need for
                the Realm-Routed-Reports (RRR) report type.

                

                As you may recall, the consensus coming out of the DIME
                WG meeting in London was to support two report types:

                

                - Host -- Impacting requests with a Destination-Host AVP
                matching the host in the overload report (with the host
                implicitly determined from the Origin-Host AVP of the
                answer message carrying the overload report).

                

                - Realm -- Impacting 100% of the requests with a
                Destination-Realm AVP matching the realm in the overload
                report (with the realm implicitly determine from the
                Origin-Realm of the answer message carrying the overload
                report).

                

                The action Ben and I took was to come back with an
                opinion on whether RRR reports should also be supported.

                

                My summary of the discussion is that we recommend to NOT
                include RRR reports in the current version of the base
                DOIC draft. 
                

                

                We still have some concerns with the granularity of
                control enabled by having just the two report types but
                the analysis of whether RRR reports are still needed can
                occur independent of the base DOIC draft.  If there is a
                determination that RRRs are needed in time to include in
                the base draft then it can be considered at that time.

                

                Based on this, I propose the following 

                

                - Resolution to issue #23 is to remove RRR reports from
                the document.

                - Resolution to issue #55 is to add Realm reports
                (actually to redefine them per the above definition).

                - Resolution to issue #57 is that it no longer applies
                (as it deals with RRRs).

                

                There is also need for text describing the interaction
                between host and the realm reports.  I don't expect we
                will have consensus on this wording prior to the -02
                draft being submitted.  To this end, I'll open a new
                issue to deal with the need for wording on the
                interaction.

                

                Regards,

                

                Steve 

            

            


              

              

              

              

              

            
_______________________________________________

            
DiME mailing list

            
DiME@ietf.org

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

          

          
 

        

        
 

      

    

    

  


--------------060909010800000508090106--


From nobody Tue Mar 25 07:53:31 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 102F41A0153 for ; Tue, 25 Mar 2014 07:53:29 -0700 (PDT)
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 eZzF-U_4Bl_W for ; Tue, 25 Mar 2014 07:53:26 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF071A0154 for ; Tue, 25 Mar 2014 07:53:26 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3BFC418C1A5; Tue, 25 Mar 2014 15:53:24 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1FFC935C04E; Tue, 25 Mar 2014 15:53:24 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 25 Mar 2014 15:53:24 +0100
From: 
To: Jouni Korhonen , Steve Donovan 
Thread-Topic: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
Thread-Index: AQHPR6EfMHhB3NG9bkGH3BrsNfNubprxwdGAgAAi16A=
Date: Tue, 25 Mar 2014 14:53:23 +0000
Message-ID: <15545_1395759204_53319864_15545_4342_1_6B7134B31289DC4FAF731D844122B36E51AB34@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.com> <39DF4595-FB8E-4250-BB1E-62AF45D87528@gmail.com>
In-Reply-To: <39DF4595-FB8E-4250-BB1E-62AF45D87528@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.1]
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.25.51216
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/UchNoBTprJhR4xR9aAnCM0iVdDM
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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, 25 Mar 2014 14:53:29 -0000

+1

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: mardi 25 mars 2014 14:49
=C0=A0: Steve Donovan
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #46: Bad normative advice on not letting overlo=
ad reports expire


Fine with me.

On Mar 24, 2014, at 10:38 PM, Steve Donovan  wrot=
e:

> Here's some proposed wording that will hopefully let us close this issue:
>=20
> Regards,
>=20
> Steve
>=20
> -----
>=20
> Section 4.5., paragraph 3 -=20
>=20
> Current -02 wording:
>=20
> As a general guidance for implementations it is RECOMMENDED never to
>    let any overload report to timeout.  Following to this rule, an
>    overload endpoint should explicitly signal the end of overload
>    condition and not rely on the expiration of the validity time of the
>    overload report in the reacting node.  This is achieved by sending an
>    updated overload report (meaning it must contain a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
> Proposed wording:
>=20
>    A reporting node SHOULD explicitly signal the end of overload
>    condition in a timely manner.  This is achieved by sending an
>    updated overload report (meaning the OLR contains a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
>   A reacting node MUST invalidate and remove an overload report that
>   expires without an explicit overload report containing an OC-Validity-D=
uration
>   value set to zero ("0").
>=20
>=20
> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>> Fine with me.
>>=20
>> - Jouni
>>=20
>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome=20
>> 
>>  wrote:
>>=20
>>=20
>>> Ben, Nirav,
>>>=20
>>> I follow same argumentation.
>>> Regards
>>> /MCruz
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Nirav Salot (nsalot)
>>> Sent: martes, 11 de febrero de 2014 11:23
>>> To: Ben Campbell; Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting ove=
rload reports expire
>>>=20
>>> Ben,
>>>=20
>>> I resonate with your thinking below.
>>>=20
>>> Regards,
>>> Nirav.
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Ben Campbell
>>> Sent: Monday, February 10, 2014 9:54 PM
>>> To: Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting ove=
rload reports expire
>>>=20
>>>=20
>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen=20
>>> 
>>>  wrote:
>>>=20
>>>=20
>>>> My reasoning for explicit termination was that knowing the=20
>>>> implementation folks they will let overload conditions expire unless a=
dvised otherwise.
>>>> And having unnecessary stuff hanging around waiting for a cleanup is=
=20
>>>> not a good thing in general. But I am open here for other options..
>>>>=20
>>>>=20
>>> I think it's reasonable to say that a reporting node should terminate a=
n overload condition in a timely manner. But if it's about to expire anyway=
, then expiration might be just as timely as an explicit report.=20
>>>=20
>>> And of course, the definition of "timely" is somewhat a matter of polic=
y. For example, I can imagine an deployment that had a large number of clie=
nts using fairly short validity durations, and _never_ explicitly signaling=
 an end to an overload condition. This adds a bit of a "slow-start" to the =
recovery, since different clients will expire the overload condition at dif=
ferent times, and the load will ramp up gradually. I don't see anything wro=
ng with that. Of course, it wouldn't work if one chose long validity durati=
ons, or if the signaling of overload to different clients happened in close=
 synchronization.
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>>=20
>>=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 Tue Mar 25 08:04: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 6F6BA1A016B for ; Tue, 25 Mar 2014 08:04:16 -0700 (PDT)
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 c4RMql2zZpXW for ; Tue, 25 Mar 2014 08:04:13 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id A46A61A0133 for ; Tue, 25 Mar 2014 08:04:12 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-4f-53319aeadb27
Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 65.42.04249.AEA91335; Tue, 25 Mar 2014 16:04:10 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 16:04:10 +0100
From: Maria Cruz Bartolome 
To: "lionel.morand@orange.com" , Jouni Korhonen , Steve Donovan 
Thread-Topic: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
Thread-Index: AQHPSDn+t0fDkcbCrUWGV1ADOW2pqZrx5hjg
Date: Tue, 25 Mar 2014 15:04:09 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097A0808@ESESSMB101.ericsson.se>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.com> <39DF4595-FB8E-4250-BB1E-62AF45D87528@gmail.com> <15545_1395759204_53319864_15545_4342_1_6B7134B31289DC4FAF731D844122B36E51AB34@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <15545_1395759204_53319864_15545_4342_1_6B7134B31289DC4FAF731D844122B36E51AB34@PEXCVZYM13.corporate.adroot.infra.ftgroup>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6rWYbBBvd2GVjM7V3BZrF/XQOT xe3tmRYbmngcWDx2zrrL7rFkyU8mj5ZnJ9k8Vr3tYw1gieKySUnNySxLLdK3S+DK2H71P2PB ROOK/xO6WRoYJ2p1MXJySAiYSPz784gVwhaTuHBvPVsXIxeHkMARRolFr2GcJYwS/zb9ZAep YhOwk7h0+gUTSEJEoI9RYnLTDEaQBLOAssTsHQ/AioQFYiXuPJnLBGKLCMRJvHv4jg3CNpKY vnwacxcjBweLgKrE+RmSICavgK9E1w8eiF27WSQeX3zPAuJwCrQxSrT0zwI7jxHovO+n1jBB 7BKXuPVkPhPE2QISS/acZ4awRSVePv4H9Y6SxKLbn6Hq9SRuTJ3CBmFrSyxb+BqsnldAUOLk zCcsExjFZiEZOwtJyywkLbOQtCxgZFnFyFGcWpyUm25ksIkRGE0Ht/y22MF4+a/NIUZpDhYl cd6Pb52DhATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTB6db+8+v9iy7OXK/xvObG8WnL5ysc3 795Ilehdr2bmbknY/VPs95blyRVqx1vLF72McmIKWv7T/sCj0/OKeVe65Jd3Czwsv/1bLvLa /oDbD76W7OIzaHNfO/WxsP3mpZJXdSuOWCaylmgZKoQax8ywlDPzfCD7x0jgsNiL04t46q19 OfzvuP1SYinOSDTUYi4qTgQAFE0O03QCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ut-arZ-fdHQxv-hHmYUEe1Bc6Io
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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, 25 Mar 2014 15:04:16 -0000

It sounds alright

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange=
.com
Sent: martes, 25 de marzo de 2014 15:53
To: Jouni Korhonen; Steve Donovan
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overloa=
d reports expire

+1

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen Env=
oy=E9=A0: mardi 25 mars 2014 14:49 =C0=A0: Steve Donovan Cc=A0: dime@ietf.o=
rg Objet=A0: Re: [Dime] [dime] #46: Bad normative advice on not letting ove=
rload reports expire


Fine with me.

On Mar 24, 2014, at 10:38 PM, Steve Donovan  wrot=
e:

> Here's some proposed wording that will hopefully let us close this issue:
>=20
> Regards,
>=20
> Steve
>=20
> -----
>=20
> Section 4.5., paragraph 3 -
>=20
> Current -02 wording:
>=20
> As a general guidance for implementations it is RECOMMENDED never to
>    let any overload report to timeout.  Following to this rule, an
>    overload endpoint should explicitly signal the end of overload
>    condition and not rely on the expiration of the validity time of the
>    overload report in the reacting node.  This is achieved by sending an
>    updated overload report (meaning it must contain a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
> Proposed wording:
>=20
>    A reporting node SHOULD explicitly signal the end of overload
>    condition in a timely manner.  This is achieved by sending an
>    updated overload report (meaning the OLR contains a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
>   A reacting node MUST invalidate and remove an overload report that
>   expires without an explicit overload report containing an OC-Validity-D=
uration
>   value set to zero ("0").
>=20
>=20
> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>> Fine with me.
>>=20
>> - Jouni
>>=20
>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome=20
>> 
>>  wrote:
>>=20
>>=20
>>> Ben, Nirav,
>>>=20
>>> I follow same argumentation.
>>> Regards
>>> /MCruz
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Nirav Salot (nsalot)
>>> Sent: martes, 11 de febrero de 2014 11:23
>>> To: Ben Campbell; Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting=20
>>> overload reports expire
>>>=20
>>> Ben,
>>>=20
>>> I resonate with your thinking below.
>>>=20
>>> Regards,
>>> Nirav.
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Ben Campbell
>>> Sent: Monday, February 10, 2014 9:54 PM
>>> To: Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting=20
>>> overload reports expire
>>>=20
>>>=20
>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen 
>>>  wrote:
>>>=20
>>>=20
>>>> My reasoning for explicit termination was that knowing the=20
>>>> implementation folks they will let overload conditions expire unless a=
dvised otherwise.
>>>> And having unnecessary stuff hanging around waiting for a cleanup is=20
>>>> not a good thing in general. But I am open here for other options..
>>>>=20
>>>>=20
>>> I think it's reasonable to say that a reporting node should terminate a=
n overload condition in a timely manner. But if it's about to expire anyway=
, then expiration might be just as timely as an explicit report.=20
>>>=20
>>> And of course, the definition of "timely" is somewhat a matter of polic=
y. For example, I can imagine an deployment that had a large number of clie=
nts using fairly short validity durations, and _never_ explicitly signaling=
 an end to an overload condition. This adds a bit of a "slow-start" to the =
recovery, since different clients will expire the overload condition at dif=
ferent times, and the load will ramp up gradually. I don't see anything wro=
ng with that. Of course, it wouldn't work if one chose long validity durati=
ons, or if the signaling of overload to different clients happened in close=
 synchronization.
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>>=20
>>=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.

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


From nobody Tue Mar 25 08:15: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 C5B091A0179 for ; Tue, 25 Mar 2014 08:14:57 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Vg8KIlaIyTp2 for ; Tue, 25 Mar 2014 08:14:52 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2731A016B for ; Tue, 25 Mar 2014 08:14:51 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2PFEnYR027259 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 15:14:49 GMT
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 s2PFEnU8015030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 16:14:49 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 16:14:48 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 16:14:48 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRUlVL8WBONWpVkShCkGbZ2B6UJrwNmSAgAAvmYCAAB77AIABLGLQgAAVV4CAABLf4A==
Date: Tue, 25 Mar 2014 15:14:48 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com>
In-Reply-To: <5331895D.5050500@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2299DEMUMBX014nsnin_"
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: 34513
X-purgate-ID: 151667::1395760489-0000137C-EB849AEC/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6SO-qc91d3K0wCXlLyAcP1qMyKk
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 15:14:58 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2299DEMUMBX014nsnin_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve,
Thank you for this summary.
Please see inline.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,

I mean going backwards from where I thought we were after the London meetin=
g.

We are clearly out of sync but hopefully we can fix that.

Here's my understanding of the status of #23 and #55.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to realm-routed-r=
eports (RRR).
this includes agreement to keep the (newly called) realm-routed-rep=
orts
 - Discussions were ongoing as to the need for both realm reports and RRR r=
eports.
I would say "...as to the need for realm reports in addition to rea=
lm-routed-reports" 


#55 status:
  - Agreement on adding Realm reports based on the definition that realm re=
ports apply to all traffic sent to the realm.
This is what I'm missing. The issue has been very briefly discussed=
 under #34 without conclusion. There was no discussion under #55

  - Limited discussion on the interaction between the new realm reports and=
 the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
What was the technical argument?

  - Ben expressed the strongest concern with this plan.  Steve and Ben took=
 action to discuss and come back with a recommendation.

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types - hos=
t and realm, with realm having the new definition.
What was the technical argument?

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and revisit l=
ater is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to supp=
ort realm reports.  Others might have a different opinion.
 There was no comment posted to issue #55, also no proposed solutio=
n, so I cannot see where the consensus came from


Summary:
  - I believe we have three options:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan coming =
out of the London meeting
< Ulrich> There is not even an issue number identifying problems with RRR a=
nd proposing to remove RRR

   3) Support host, RRR and Realm reports

 I support option 1

Regards,

Steve

On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,
I don't think we are going backwards (we may be out of synch though)

Can you please summarize the status of #23 and #55.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve







_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2299DEMUMBX014nsnin_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve,


Thank you =
for this summary.


Please see=
 inline.


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 2:49 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulrich,



I mean going backwards from where I thought we were after the London meetin=
g.



We are clearly out of sync but hopefully we can fix that.



Here's my understanding of the status of #23 and #55.



Prior to London meeting:



#23 status:

 - Agreement to change the name of existing realm reports to realm-rou=
ted-reports (RRR).=



<Ulrich>this includes agreement to keep the (new=
ly called) realm-routed-reports</Ulrich><=
br>
 - Discussions were ongoing as to the need for both realm reports and =
RRR reports.=



<Ulrich>I would say “…as to the need=
 for realm reports in addition to realm-routed-reports” </Ulrich&g=
t;


=




#55 status:

  - Agreement on adding Realm reports based on the definition that rea=
lm reports apply to all traffic sent to the realm.


<Ulrich>This is what I’m missing. The issu=
e has been very briefly discussed under #34 without conclusion. There was
 no discussion under #55</Ulrich>


=


  - Limited discussion on the interaction between the new realm report=
s and the existing host and RRR reports.



After London meeting:



#23 status:

  - Tentative agreement in London meeting to remove RRR reports.


<Ulrich>What was the technical argument?</Ulr=
ich>


=


  - Ben expressed the strongest concern with this plan.  S=
teve and Ben took action to discuss and come back with a recommendation.&nb=
sp;




#55 status:

  - No change



Summary:

  - Tentative consensus reached to move forward with two report types =
- host and realm, with realm having the new definition.

<Ulrich>What was the techni=
cal argument?</Ulrich>




Current status:



#23 status:

 - Change the name to RRR

 - Whether or not to remove RRR and revisit later or keep RRR and revi=
sit later is an open issue.



#55 status:

  - My opinion is that we have at least rough consensus on the need to=
 support realm reports.  Others might have a different opinion.


<Ulrich> There was no comment posted to issue #5=
5, also no proposed solution, so I cannot see where the consensus
 came from</Ulrich>


=




Summary:

  - I believe we have three options:



   1) Support host and RRR reports

   2) Support host and Realm reports -- This was the tentative pl=
an coming out of the London meeting


< Ulrich> There is not even an issue number iden=
tifying problems with RRR and proposing to remove RRR</Ulrich>


=


   3) Support host, RRR and Realm reports






<Ulrich> I support option 1</Ulrich><=
/o:p>


=


Regards,



Steve








On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) =
wrote:






Steve,


I don̵=
7;t think we are going backwards (we may be out of synch though)


 


Can you pl=
ease summarize the status of #23 and #55.


 


Ulrich


 


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 7:38 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ok, we are going back=
wards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I do not agree.


 <=
/p>

We should =
still have the option



3) support=
 report type 0 (this is called host report) and support of report type 1 (t=
his has been called relam report but people argued it should
 better be called realm routed request report).


 


Whether or=
 not we need in addition to type 0 and type 1 (or as a replacement of type =
1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There are =
a lot of open questions  with regard to #55 and I have not seen a conc=
lusion.


Where I ha=
ve seen a conclusion is issue #34 and that is inline with option 3).=



 


Unless we =
conclude on #55, or decide to re-open #34, option 3) is what should go in t=
he -02 draft.


 


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulrich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan wrote:<=
/p>





Ulrich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)=
 wrote:






Steve,<=
/p>

 <=
/p>

I don̵=
7;t know what happend in London.


Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 



















_______________________________________________


DiME mailing list


DiME@ietf.org


https://www.iet=
f.org/mailman/listinfo/dime




 




 




 






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D2299DEMUMBX014nsnin_--


From nobody Tue Mar 25 08:17: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 86CA91A0182 for ; Tue, 25 Mar 2014 08:16:43 -0700 (PDT)
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 MI3iDLa036-z for ; Tue, 25 Mar 2014 08:16:40 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A8E5C1A0198 for ; Tue, 25 Mar 2014 08:16:38 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c0-53319dd4b004
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CF.4A.10875.4DD91335; Tue, 25 Mar 2014 16:16:36 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 16:16:36 +0100
From: Maria Cruz Bartolome 
To: "Shishufeng (Susan)" , "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPR3wUL8WBONWpVkShCkGbZ2B6UJrxcLnQgAB54pA=
Date: Tue, 25 Mar 2014 15:16:36 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097A082B@ESESSMB101.ericsson.se>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <26C84DFD55BC3040A45BF70926E55F2587C3DF2D@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3DF2D@SZXEMA512-MBX.china.huawei.com>
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: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097A082BESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvje6VuYbBBhfazCzm9q5gs9jQxGNx 7mATm8W6tyuYHFg8Wo68ZfVYsuQnk8fP9VfZPVa97WMNYInisklJzcksSy3St0vgypg3Zypj Qfttxoo3t+awNzAe3c/YxcjJISFgInHw2zYmCFtM4sK99WxdjFwcQgKHGCUuPLsL5SxhlHi9 9ysrSBWbgJ3EpdMvmEASIgKHGSUevj8FNkpYIFzi+9VNbCC2iECExL6GxVC2lcS9+b/BbBYB VYlpsxeD1fMK+ErMuN/BDrHhNJPEkW2nmUESnAJhEkvX/wG7iRHopu+n1oDZzALiEreezIe6 VUBiyZ7zzBC2qMTLx/9YIWwliUW3P0PV50u8/DKBHWKZoMTJmU9YJjCKzEIyahaSsllIyiDi OhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRvbcxMyc9HLDTYzAWDu45bfuDsZT50QOMUpz sCiJ83546xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVFV6pV5/46Qx+Y7dl46tbDc6M/b mKdnPesf3YvZVP76+M5/zx80X146UW7esQLT1e3KNjsDVu3sr9ZzNwxVVrwdbrHvk1ziFTar ny8t5kq+FcqceclMoPrzx/PMl1Py5J6FTF9p7/a2P37CEp5ttVu8Hm/TfO3h1vBgO49m7NPL FywXnTsz0SlLiaU4I9FQi7moOBEAQ3OZP4MCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/La7FATNWYMfiGHmzpjoBJ6XYAyo
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 15:16:43 -0000

--_000_087A34937E64E74E848732CFF8354B92097A082BESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

+1
My understanding of the discussion before London's meeting and in that meet=
ing was that option 3 was considered.
That is, we have two reports, host and realm.
Host applies when Destination_host is present, and then it takes precedence=
 over Realm. If both are present, only Host is applied.
Realm applies when only Destination_realm is present.

And.. we did not have consensus on nothing else, at least this was my inter=
pretation.
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Shishufeng (Susan)
Sent: martes, 25 de marzo de 2014 8:58
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

+1

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Tuesday, March 25, 2014 12:14 AM
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve



_______________________________________________

DiME mailing list

DiME@ietf.org

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


--_000_087A34937E64E74E848732CFF8354B92097A082BESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











+1<=
/p>

My understanding of the d=
iscussion before London’s meeting and in that meeting was that option=
 3 was considered.


That is, we have two repo=
rts, host and realm.



Host applies when Destina=
tion_host is present, and then it takes precedence over Realm. If both are =
present, only Host is applied.


Realm applies when only D=
estination_realm is present.


 <=
/p>

And.. we did not have con=
sensus on nothing else, at least this was my interpretation.


Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Shishufeng (Susan)

Sent: martes, 25 de marzo de 2014 8:58

To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.or=
g

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 




From:
 Wiehe, Ulrich (NSN - DE/Munich) [m=
ailto:ulrich.wiehe@nsn.com]


Sent: Tuesday, March 25, 2014 12:14 AM

To: ext Steve Donovan; dime@ietf.or=
g

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports





&nbs=
p;


Steve,


 


I do not agree.


 




From:
 DiME [mailto:dime-bounces@ietf.or=
g] 
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports




 


Ulrich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan wrote:






Ulrich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:






Steve,


 








=



=



=







From:
 DiME [mailto:dime-bounces@ietf.or=
g] 
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports=







 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 











_____________________________________=
__________


DiME mailing list

DiME=
@ietf.org


https://www.ietf.org/mailman/listinfo/dime=





 





--_000_087A34937E64E74E848732CFF8354B92097A082BESESSMB101erics_--


From nobody Tue Mar 25 08:21: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 6FAAD1A0179 for ; Tue, 25 Mar 2014 08:20:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 Oc3r86GUE3Ji for ; Tue, 25 Mar 2014 08:20:48 -0700 (PDT)
Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 74B8E1A019A for ; Tue, 25 Mar 2014 08:20:47 -0700 (PDT)
X-AuditID: c1b4fb31-b7f888e000000826-85-53319ecd69e6
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 01.76.02086.DCE91335; Tue, 25 Mar 2014 16:20:45 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 16:20:44 +0100
From: Maria Cruz Bartolome 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Steve Donovan" , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRUlVL8WBONWpVkShCkGbZ2B6UJrwNmSAgAAvmYCAAB77AIABLGLQgAAVV4CAABLf4IAAFwsw
Date: Tue, 25 Mar 2014 15:20:44 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@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: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097A0844ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvje7ZeYbBBv3PZSzm9q5gs9jQxGOx 7u0KJgdmjyVLfjJ5/Fx/ld1j1ds+1gDmKC6blNSczLLUIn27BK6MZ1s3MxW8WsRU8ejPWaYG xmN/GLsYOTkkBEwkJu2+DGWLSVy4t56ti5GLQ0jgBKPEryOPoZwljBKH7s9nBqliE7CTuHT6 BRNIQkSgn1HiyNUJTCAJYYFwie9XN7GB2CICERL7GhZD2VESB19tAmrm4GARUJWY9C8VJMwr 4CvRtGMpK8SCy8wSjybdAVvAKRAgcfndOjCbEeik76fWgM1nFhCXuPVkPhPEqQISS/acZ4aw RSVePv7HCmErSSy6/RmqPl+ic9NMVohlghInZz5hmcAoMgvJqFlIymYhKYOI60gs2P2JDcLW lli28DUzjH3mwGMmZPEFjOyrGCWLU4uTctONDPVy03NL9FKLMpOLi/Pz9IpTNzECI+/glt+G OxgnXrM/xCjNwaIkzsswvTNISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUAyPD5vYMW8multqs rBOiB/5smRW2O814rVnqIu3bPMcte5etEnh/Nzg7VPBhclVIb13+7I0rfQP+njT5UxS+x2/X zZR3jlpswnw6K6+kt3xyEnGd+NVn5Wev9k+XDapP9wfl3dX1W3f/bpXdsxUNa/f9sg62/rtl a79NjM/n2ZHWqULcmeHPMpRYijMSDbWYi4oTATdmyk2KAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pBMOy20v8yPQFQua8cq4WsHPkmA
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 15:20:52 -0000

--_000_087A34937E64E74E848732CFF8354B92097A0844ESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

I support option 1 a well
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 25 de marzo de 2014 16:15
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Steve,
Thank you for this summary.
Please see inline.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,

I mean going backwards from where I thought we were after the London meetin=
g.

We are clearly out of sync but hopefully we can fix that.

Here's my understanding of the status of #23 and #55.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to realm-routed-r=
eports (RRR).
this includes agreement to keep the (newly called) realm-routed-rep=
orts
 - Discussions were ongoing as to the need for both realm reports and RRR r=
eports.
I would say "...as to the need for realm reports in addition to rea=
lm-routed-reports" 


#55 status:
  - Agreement on adding Realm reports based on the definition that realm re=
ports apply to all traffic sent to the realm.
This is what I'm missing. The issue has been very briefly discussed=
 under #34 without conclusion. There was no discussion under #55

  - Limited discussion on the interaction between the new realm reports and=
 the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
What was the technical argument?

  - Ben expressed the strongest concern with this plan.  Steve and Ben took=
 action to discuss and come back with a recommendation.

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types - hos=
t and realm, with realm having the new definition.
What was the technical argument?

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and revisit l=
ater is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to supp=
ort realm reports.  Others might have a different opinion.
 There was no comment posted to issue #55, also no proposed solutio=
n, so I cannot see where the consensus came from


Summary:
  - I believe we have three options:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan coming =
out of the London meeting
< Ulrich> There is not even an issue number identifying problems with RRR a=
nd proposing to remove RRR

   3) Support host, RRR and Realm reports
 I support option 1

Regards,

Steve
On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,
I don't think we are going backwards (we may be out of synch though)

Can you please summarize the status of #23 and #55.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve






_______________________________________________

DiME mailing list

DiME@ietf.org

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




--_000_087A34937E64E74E848732CFF8354B92097A0844ESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Dear all,


 <=
/p>

I support option 1 a well=



Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: martes, 25 de marzo de 2014 16:15

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Steve,<=
/p>

Thank you for this summar=
y.


Please see inline.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 2:49 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,



I mean going backwards from where I thought we were after the London meetin=
g.



We are clearly out of sync but hopefully we can fix that.



Here's my understanding of the status of #23 and #55.



Prior to London meeting:



#23 status:

 - Agreement to change the name of existing realm reports to realm-rou=
ted-reports (RRR).


<Ulrich>this includes agreement to keep the (newly called) real=
m-routed-reports</Ulrich>

 - Discussions were ongoing as to the need for both realm reports and =
RRR reports.


<Ulrich>I would say “…as to the need for realm repo=
rts in addition to realm-routed-reports” </Ulrich>






#55 status:

  - Agreement on adding Realm reports based on the definition that rea=
lm reports apply to all traffic sent to the realm.


<Ulrich>This is what I’m missing. The issue has been very=
 briefly discussed under #34 without conclusion. There was no discussion
 under #55</Ulrich>




  - Limited discussion on the interaction between the new realm report=
s and the existing host and RRR reports.



After London meeting:



#23 status:

  - Tentative agreement in London meeting to remove RRR reports.


<Ulrich>What was the technical argument?</Ulrich>




  - Ben expressed the strongest concern with this plan.  Steve and Ben took action to discuss and come back with a recomme=
ndation. 




#55 status:

  - No change



Summary:

  - Tentative consensus reached to move forward with two report types =
- host and realm, with realm having the new definition.

<Ulrich>What was the technical argu=
ment?</Ulrich>



Current status:



#23 status:

 - Change the name to RRR

 - Whether or not to remove RRR and revisit later or keep RRR and revi=
sit later is an open issue.



#55 status:

  - My opinion is that we have at least rough consensus on the need to=
 support realm reports.  Others might have a different opinion.=



<Ulrich> There was no comment posted to issue #55, also no prop=
osed solution, so I cannot see where the consensus came from</Ulrich>=







Summary:

  - I believe we have three options:



   1) Support host and RRR reports

   2) Support host and Realm reports -- This was the tentative pl=
an coming out of the London meeting


< Ulrich> There is not even an issue number identifying problem=
s with RRR and proposing to remove RRR</Ulrich>




   3) Support host, RRR and Realm reports


<Ulrich> I support option 1</Ulrich>



Regards,



Steve




On 3/25/14 6:44 AM, Wiehe, Ulrich =
(NSN - DE/Munich) wrote:






Steve,


I don’t think we ar=
e going backwards (we may be out of synch though)<=
o:p>


 


Can you please summarize =
the status of #23 and #55.


 


Ulrich


 


 






From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 7:38 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ok,=
 we are going backwards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I do not agre=
e.


 =



We should still have the =
option



3) support report type 0 =
(this is called host report) and support of report type 1 (this has been ca=
lled relam report but people argued it should better be
 called realm routed request report).


 


Whether or not we need in=
 addition to type 0 and type 1 (or as a replacement of type 1) a realm-no-m=
atter-whether-destination-host-is present-or-not report
   is an open issue (see #55).


There are a lot of open q=
uestions  with regard to #55 and I have not seen a conclusion.<=
span lang=3D"DE">


Where I have seen a concl=
usion is issue #34 and that is inline with option 3).


 


Unless we conclude on #55=
, or decide to re-open #34, option 3) is what should go in the -02 draft.


 


 


Ulrich


 






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan =
wrote:






Ulr=
ich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I don’t know what h=
append in London.


Can you please summarize =
the technical reasons that led to the London agreement.



E-mail discussions prior =
to London have clearly directed towards a report type that requests throttl=
ing of realm routed request messages (i.e. not containing
 a destination host) rather than a report type that requests throttling of =
messages routed towards a realm (no matter whether they contain a destinati=
on host or not).   

 


Ulrich


 






From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 
















_______________________________________________=



DiME mailing list


DiME@ietf.org


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




 




 




 






--_000_087A34937E64E74E848732CFF8354B92097A0844ESESSMB101erics_--


From nobody Tue Mar 25 08:27:37 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 0F2EC1A016D for ; Tue, 25 Mar 2014 08:27:17 -0700 (PDT)
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 8EanoqFDHZFs for ; Tue, 25 Mar 2014 08:27:07 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9281A00D9 for ; Tue, 25 Mar 2014 08:27:06 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 2FFF73B4267; Tue, 25 Mar 2014 16:27:04 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 1517018006E; Tue, 25 Mar 2014 16:27:04 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Tue, 25 Mar 2014 16:27:03 +0100
From: 
To: Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" , ext Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRRecscXj4P/C40GW6f1v1eWv+5rr96eAgAQ/IICAACZMgIAAKEkAgAEey4CAACLtgIAAF+UAgAABqACAABEhsA==
Date: Tue, 25 Mar 2014 15:27:02 +0000
Message-ID: <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097A0844@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.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51AC99PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.51216
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Qk9GeO9qV8PukfHzlq6BOWdRVsk
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 15:27:17 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51AC99PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Maria Cruz, All,

In the previous mail, you wrote:

That is, we have two reports, host and realm.
Host applies when Destination_host is present, and then it takes precedence=
 over Realm. If both are present, only Host is applied.
Realm applies when only Destination_realm is present.

And I agree with this statement. But I'm not sure that this is the case dis=
cussed by Ulrich.

Whatever the name of the realm report type, is there an agreement on the de=
scription given above by Maria Cruz and discussed in London?

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 mars 2014 16:21
=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports

Dear all,

I support option 1 a well
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 25 de marzo de 2014 16:15
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Steve,
Thank you for this summary.
Please see inline.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,

I mean going backwards from where I thought we were after the London meetin=
g.

We are clearly out of sync but hopefully we can fix that.

Here's my understanding of the status of #23 and #55.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to realm-routed-r=
eports (RRR).
this includes agreement to keep the (newly called) realm-routed-rep=
orts
 - Discussions were ongoing as to the need for both realm reports and RRR r=
eports.
I would say "...as to the need for realm reports in addition to rea=
lm-routed-reports" 


#55 status:
  - Agreement on adding Realm reports based on the definition that realm re=
ports apply to all traffic sent to the realm.
This is what I'm missing. The issue has been very briefly discussed=
 under #34 without conclusion. There was no discussion under #55

  - Limited discussion on the interaction between the new realm reports and=
 the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
What was the technical argument?

  - Ben expressed the strongest concern with this plan.  Steve and Ben took=
 action to discuss and come back with a recommendation.

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types - hos=
t and realm, with realm having the new definition.
What was the technical argument?

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and revisit l=
ater is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to supp=
ort realm reports.  Others might have a different opinion.
 There was no comment posted to issue #55, also no proposed solutio=
n, so I cannot see where the consensus came from


Summary:
  - I believe we have three options:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan coming =
out of the London meeting
< Ulrich> There is not even an issue number identifying problems with RRR a=
nd proposing to remove RRR

   3) Support host, RRR and Realm reports
 I support option 1

Regards,

Steve
On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,
I don't think we are going backwards (we may be out of synch though)

Can you please summarize the status of #23 and #55.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve





_______________________________________________

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_6B7134B31289DC4FAF731D844122B36E51AC99PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Maria Cruz, All,<=
/o:p>


 <=
/p>

In the pre=
vious mail, you wrote:


 =
;


That is, we have two reports, host and realm.



Host applies when Destination_host is present, and th=
en it takes precedence over Realm. If both are present, only
 Host is applied.


Realm applies when only Destination_realm is present.=



 =
;


And I agre=
e with this statement. But I'm not sure that this is the case discussed by =
Ulrich.


 =
;


Whatever t=
he name of the realm report type, is there an agreement on the description =
given above by Maria Cruz and discussed in London?


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 25 mars 2014 16:21

=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@=
ietf.org

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


Dear all,<=
o:p>


 =
;


I support =
option 1 a well


Cheers


/MCruz


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: martes, 25 de marzo de 2014 16:15

To: ext Steve Donovan; dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Steve,


Thank you =
for this summary.


Please see=
 inline.


 =
;


Ulrich


 =
;






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 2:49 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,



I mean going backwards from where I thought we were after the London meetin=
g.



We are clearly out of sync but hopefully we can fix that.



Here's my understanding of the status of #23 and #55.



Prior to London meeting:



#23 status:

 - Agreement to change the name of existing realm reports to realm-rou=
ted-reports (RRR).=



<Ulrich>this includes agreement to keep the (new=
ly called) realm-routed-reports</Ulrich><=
br>
 - Discussions were ongoing as to the need for both realm reports and =
RRR reports.=



<Ulrich>I would say “…as to the need=
 for realm reports in addition to realm-routed-reports” </Ulrich&g=
t;


=




#55 status:

  - Agreement on adding Realm reports based on the definition that rea=
lm reports apply to all traffic sent to the realm.


<Ulrich>This is what I’m missing. The issu=
e has been very briefly discussed under #34 without conclusion. There was
 no discussion under #55</Ulrich>


=


  - Limited discussion on the interaction between the new realm report=
s and the existing host and RRR reports.



After London meeting:



#23 status:

  - Tentative agreement in London meeting to remove RRR reports.


<Ulrich>What was the technical argument?</Ulr=
ich>


=


  - Ben expressed the strongest concern with this plan.  <=
span lang=3D"DE">Steve and Ben took action to discuss and come back with a =
recommendation. 




#55 status:

  - No change



Summary:

  - Tentative consensus reached to move forward with two report types =
- host and realm, with realm having the new definition.

<Ulrich>What was the=
 technical argument?</Ulrich>




Current status:



#23 status:

 - Change the name to RRR

 - Whether or not to remove RRR and revisit later or keep RRR and revi=
sit later is an open issue.



#55 status:

  - My opinion is that we have at least rough consensus on the need to=
 support realm reports.  Others might have a different opinion.=



<Ulrich> There was no comment posted to issue #5=
5, also no proposed solution, so I cannot see where the consensus
 came from</Ulrich>


=




Summary:

  - I believe we have three options:



   1) Support host and RRR reports

   2) Support host and Realm reports -- This was the tentative pl=
an coming out of the London meeting


< Ulrich> There is not even an issue number iden=
tifying problems with RRR and proposing to remove RRR</Ulrich>


=


   3) Support host, RRR and Realm reports


<Ulrich> I support option 1</Ulrich><=
/o:p>


=


Regards,



Steve=





On 3/25/14 6:44 AM, Wiehe, Ulrich =
(NSN - DE/Munich) wrote:






Steve,


I don̵=
7;t think we are going backwards (we may be out of synch though)


 


Can you pl=
ease summarize the status of #23 and #55.


 


Ulrich


 


 






From:=
 ext Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 7:38 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ok,=
 we are going backwards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I do not agre=
e.


 =



We should =
still have the option



3) support=
 report type 0 (this is called host report) and support of report type 1 (t=
his has been called relam report but people argued it should
 better be called realm routed request report).


 


Whether or=
 not we need in addition to type 0 and type 1 (or as a replacement of type =
1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There are =
a lot of open questions  with regard to #55 and I have not seen a conc=
lusion.


Where I ha=
ve seen a conclusion is issue #34 and that is inline with option 3).=



 


Unless we =
conclude on #55, or decide to re-open #34, option 3) is what should go in t=
he -02 draft.


 


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan =
wrote:






Ulr=
ich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I don̵=
7;t know what happend in London.=



Can you pl=
ease summarize the technical reasons that led to the London agreement.



E-mail dis=
cussions prior to London have clearly directed towards a report type that r=
equests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   <=
/o:p>


 


Ulrich


 






From:=
 DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 















_______________________________________________=



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_6B7134B31289DC4FAF731D844122B36E51AC99PEXCVZYM13corpora_--


From nobody Tue Mar 25 08:56: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 5A84B1A016D for ; Tue, 25 Mar 2014 08:56:13 -0700 (PDT)
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 wGHfe0oJzGV5 for ; Tue, 25 Mar 2014 08:56:11 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCE21A0144 for ; Tue, 25 Mar 2014 08:56:11 -0700 (PDT)
X-AuditID: c1b4fb38-b7f418e000001099-58-5331a719b32e
Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 95.A6.04249.917A1335; Tue, 25 Mar 2014 16:56:09 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 16:56:08 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] DOIC Default Algorithm Specification
Thread-Index: AQHPQg1mSrntxLF47UmNCQBgXGvw6JrrxgcAgAXFv4CAACWoAIAAT93Q
Date: Tue, 25 Mar 2014 15:56:08 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097A087C@ESESSMB101.ericsson.se>
References: <4857132E-EB7E-4844-B9F4-81DD209E0705@nostrum.com> <5750EB10-9E07-4CD7-A122-CD5DDBD73003@gmail.com>  <5331721A.5080502@usdonovans.com>
In-Reply-To: <5331721A.5080502@usdonovans.com>
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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyM+Jvja7kcsNggzV31Czm9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Mnb8OslYsFK84viPP+wNjH+Euhg5OSQETCR+ Puhgh7DFJC7cW8/WxcjFISRwhFFixrR2RpCEkMASRom+2bUgNpuAncSl0y+YQGwRAV+J452n WUBsYQELiWczZ0LFLSUeTn3KDGG7SfTseQG2gEVAVWLe7hNgcV6g3m9XrkEte8EosW7tBDaQ BKeAnsTR13/AbEagi76fWgM2lFlAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSSx6PZnqHo9 iRtTp7BB2NoSyxa+hlosKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxi5ChOLU7KTTcy2MQI jIaDW35b7GC8/NfmEKM0B4uSOO/Ht85BQgLpiSWp2ampBalF8UWlOanFhxiZODilGhgL783b 7BXDkqdYvMssI22GbOIGe9P01WyXp3DcnKD0t6Xtqbmp5+FHh3ImLdNVU98ZskJrudH7T/7d +7J/r73R2dTwmmeWbHNF3pGFW6IXeC8JnPDNoFQk2tLkm1rh8pUb0hZ0OXSaqSiadtQEPbi3 QOVJk/Lf53dnJx5OUOVoOPfUd2L6kfdKLMUZiYZazEXFiQCPNYk8VAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jV9xjsPfdjSmGfPhZlXeyRyVGbI
Subject: Re: [Dime] DOIC Default Algorithm Specification
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, 25 Mar 2014 15:56:13 -0000

Agreed

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 25 de marzo de 2014 13:10
To: dime@ietf.org
Subject: Re: [Dime] DOIC Default Algorithm Specification

JJ,

I agree, when we do this, we will try to minimize impact to the draft,=20
but there will be changes in the overall structure.  It will definitely=20
be done in a way that does not change any of the normative requirements=20
in the draft.

This will likely be the primary focus of the -03 version of the draft.

Regards,

Steve

On 3/25/14, 4:02 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi
>
> I agree with Ben to differentiate general statements which are algorithm =
independent from the ones particular to the default algorithm, otherwise it=
 may be a source of ambiguities/ misinterpretations . Now is this statement=
 grouping into a referenced section easy? I do not know. I hope this will n=
ot have a too large impact on the draft.
>
> Best regards
>
> JJacques
>
>
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
> Envoy=E9 : vendredi 21 mars 2014 18:46
> =C0 : Ben Campbell
> Cc : dime@ietf.org list
> Objet : Re: [Dime] DOIC Default Algorithm Specification
>
>
>
>
> On Mar 18, 2014, at 2:18 AM, Ben Campbell  wrote:
>
>> Hi,
>>
>> In re-reading dime-ovli, I noticed that the procedures for the "default"=
 abatement algorithm are spread through several parts of the text. That's g=
oing to make life difficult down the road for a couple of reasons:
>>
>> 1) There's no easily referenced section that fully defines the algorithm=
. That will be a problem for other docs that want to talk about the algorit=
hm (e.g. 3GPP specs), or even other sections in dime-ovli that want to ment=
ion the default algorithm by reference.
>>
>> 2) It makes extensibility harder, as it will be more difficult to define=
 new algorithms, if they need to modify behavior that is spread throughout =
dime-ovli, rather than simply supersede a specific section of dime-ovli.
>>
>> I propose that we move all algorithm-specific behavior to its own sectio=
n, and have any other sections that need to talk about the default algorith=
m reference that section rather than attempt to describe the behavior.
> That would work for me.
>
> - Jouni
>
>
>> Thanks!
>>
>> Ben.
>> _______________________________________________
>> 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


From nobody Tue Mar 25 09:16: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 6255D1A01C9 for ; Tue, 25 Mar 2014 09:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 w8G6k696aIiU for ; Tue, 25 Mar 2014 09:16:33 -0700 (PDT)
Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE471A01BA for ; Tue, 25 Mar 2014 09:16:31 -0700 (PDT)
X-AuditID: c1b4fb31-b7f888e000000826-37-5331abde8eab
Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 45.CA.02086.EDBA1335; Tue, 25 Mar 2014 17:16:30 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0387.000; Tue, 25 Mar 2014 17:16:29 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , Jouni Korhonen , "Wiehe, Ulrich (NSN - DE/Munich)" 
Thread-Topic: [Dime] DOIC Overview of Operation
Thread-Index: AQHPR1+JOeFTP8g7b0SWJgbqQrMSo5rwJ+4AgAHTMcA=
Date: Tue, 25 Mar 2014 16:16:29 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097A08AA@ESESSMB101.ericsson.se>
References: <3B8C74F7-ED9F-45CB-8115-E44E1EF29654@nostrum.com> <532C3D99.30809@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C9869@DEMUMBX014.nsn-intra.net> <4971B712-2F1F-4388-AE76-CB640F8DEB46@gmail.com> <533030F0.3060902@usdonovans.com>
In-Reply-To: <533030F0.3060902@usdonovans.com>
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: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097A08AAESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGfG3RvfeasNgg0szFSzm9q5gs9i/roHJ YkMTj8W6tyuYHFg8ds66y+6xZMlPJo+f66+ye6x628cawBLFZZOSmpNZllqkb5fAlTHp5V+2 gjVdjBUP7z5kbWDcUdbFyMkhIWAi0bfiESOELSZx4d56ti5GLg4hgROMEt82zmSFcJYwSrw+ +pkNpIpNwE7i0ukXTCAJEYHJjBJLL/0ESzALaEhc2tIMNkpYQE/ixPuLzCC2iIC+xOIFL1kh bCuJCUvPgdWwCKhKvDv+kAXE5hXwldjY9pwZYttfRokzV78AbeDg4AQa1PstF6SGEei876fW MEHsEpe49WQ+E8TZAhJL9pxnhrBFJV4+/scKYStJLLr9Gao+X2JWz2ZWiF2CEidnPmGZwCg6 C8moWUjKZiEpg4jrSCzY/YkNwtaWWLbwNTOMfebAYyZk8QWM7KsYJYtTi5Ny040M9XLTc0v0 Uosyk4uL8/P0ilM3MQJj9OCW34Y7GCdesz/EKM3BoiTOyzC9M0hIID2xJDU7NbUgtSi+qDQn tfgQIxMHp1QD4wyDfIa37Uu2x077+oThgfrVTwGcu7c1Tr+xMa/P/JRClLDtxGK7cP7gWL8K Y99M4++K3Gd01QXXr/hbuO/ktY5uzk1PlRVVTlkZqf3T1Oae05uY5Sih+X32jS2fvsZ6/G2b xy/b9dXgk+PVPxV7F56bPmGPY7RcnIsXU/HWiIKg0mTjjfvtlViKMxINtZiLihMBrMBWUZ8C AAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/0Qnclz66LEnM6FRkxuAYokbujGI
Cc: "dime@ietf.org list" 
Subject: Re: [Dime] DOIC Overview of Operation
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, 25 Mar 2014 16:16:36 -0000

--_000_087A34937E64E74E848732CFF8354B92097A08AAESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

One more comment below for clarification.
It is fine to continue with then on .02 though.
Cheers


   The Diameter Overload Information Conveyance (DOIC) mechanism allows

   Diameter nodes to request other nodes to perform overload abatement

   actions, that is, actions to reduce the load offered to the

   overloaded node.



   A Diameter node that supports DOIC is known as a "DOIC endpoint".

   Any Diameter node can act as a DOIC endpoint, including clients,

   servers, and agents.  DOIC endpoints are further divided into

   "Reporting Nodes" and "Reacting Nodes."  A reporting node requests

   overload abatement by sending an Overload Report (OLR) to one or more

   reacting nodes.



   A reacting node consumes OLRs, and performs whatever actions are

   needed to fulfill the requests.  A Reporting node may report overload

   on its own behalf, or on behalf of other (typically upstream) nodes.

   Likewise, a reacting node may perform overload abatement on its own

   behalf, or on behalf of other (typically downstream) nodes.



   A node's role as a DOIC endpoint is independent of its Diameter role.

   For example, Diameter relay and proxy agents may act as DOIC

   endpoints, even though they are not endpoints in the Diameter sense.

   Since Diameter enables bi-directional applications, where Diameter

   servers can send requests towards Diameter clients, a given Diameter

   node can simultaneously act as a reporting node and reacting node.



   Likewise, an relay or proxy agent may act as a reacting node from the

   perspective of upstream nodes, and a reporting node from the

   perspective of downstream nodes.



   DOIC endpoints do not generate new messages to carry DOIC related

   information.  Rather, they "piggyback" DOIC information over existing

   Diameter messages by inserting new AVPs into existing Diameter

   requests and responses.  Nodes indicate support for DOIC, and any

   needed DOIC parameters by inserting an OC_Supported_Features AVP

   (Section 4.1) into existing requests and responses.  Reporting nodes

   send OLRs by inserting OC-OLR AVPs.  (Section 4.3)



   A given OLR applies to the Diameter realm and application of the

   Diameter message that carries it.  If a reporting node supports more

   than one realm and/or application, it reports independently for each

   combination of realm and application.  Similarly, OC-Feature-Vector

   AVPs apply to the realm and application of the enclosing message.

   This implies that a node may support DOIC for one application and/or

   realm, but not another, and may indicate different DOIC parameters

   for each application and realm for which it supports DOIC.



   Reacting nodes perform overload abatement according to an agreed-upon

   abatement algorithm.  An abatement algorithm defines the meaning of

   the parameters of an OLR, and the procedures required for overload

   abatement.  This document specifies a single must-support algorithm,

   namely the "loss" algorithm [ref?].  Future specifications may

   introduce new algorithms.



   Overload conditions may vary in scope.  For example, a single

   Diameter node may be overloaded, in which case reacting nodes may

   reasonably attempt to send throttled requests to other destinations

   or via other agents.  On the other hand, an entire Diameter realm may

   be overloaded, in which case such attempts would do harm.  DOIC OLRs

   have a concept of "report type" (Section 4.6), where the type defines

   such behaviors.  Report types are extensible.  This document defines

   report types for overload of a specific server, and for overload of

   an entire realm.



   While a reporting node sends OLRs to "adjacent" reacting nodes, nodes

   that are "adjacent" for DOIC purposes may not be adjacent from a

   Diameter, or transport, perspective.

[MCruz] Using the term "adjacent" is kind of misleading, even if you later =
explained precisely that.

Above paragraph could be replaced by "Reacting and reporting nodes are not =
necessarily adjacent nodes"



For example, one or more

   Diameter agents that do not support DOIC may exist between a given

   pair of reporting and reacting nodes, as long as those agents pass

   unknown AVPs through unmolested.  The report types described in this

   document can safely pass through non-supporting agents.  This may not

   be true for report types defined in future specifications.  Documents

   that introduce new report types MUST describe any limitations on

   their use across non-supporting agents.




--_000_087A34937E64E74E848732CFF8354B92097A08AAESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

 <=
/p>

One more comment below fo=
r clarification.


It is fine to continue wi=
th then on .02 though.


Cheers<=
/p>

 <=
/p>





   The Diameter Overload Information Co=
nveyance (DOIC) mechanism allows


   Diameter nodes to request other node=
s to perform overload abatement


   actions, that is, actions to reduce =
the load offered to the


   overloaded node.


 


   A Diameter node that supports DOIC i=
s known as a "DOIC endpoint".


   Any Diameter node can act as a DOIC =
endpoint, including clients,


   servers, and agents.  DOIC endp=
oints are further divided into


   "Reporting Nodes" and &quo=
t;Reacting Nodes."  A reporting node requests


   overload abatement by sending an Ove=
rload Report (OLR) to one or more


   reacting nodes.


 


   A reacting node consumes OLRs, and p=
erforms whatever actions are


   needed to fulfill the requests. =
; A Reporting node may report overload


   on its own behalf, or on behalf of o=
ther (typically upstream) nodes.


   Likewise, a reacting node may perfor=
m overload abatement on its own


   behalf, or on behalf of other (typic=
ally downstream) nodes.


 


   A node's role as a DOIC endpoint is =
independent of its Diameter role.


   For example, Diameter relay and prox=
y agents may act as DOIC


   endpoints, even though they are not =
endpoints in the Diameter sense.


   Since Diameter enables bi-directiona=
l applications, where Diameter


   servers can send requests towards Di=
ameter clients, a given Diameter


   node can simultaneously act as a rep=
orting node and reacting node.


 


   Likewise, an relay or proxy agent ma=
y act as a reacting node from the


   perspective of upstream nodes, and a=
 reporting node from the


   perspective of downstream nodes.


 


   DOIC endpoints do not generate new m=
essages to carry DOIC related


   information.  Rather, they &quo=
t;piggyback" DOIC information over existing


   Diameter messages by inserting new A=
VPs into existing Diameter


   requests and responses.  Nodes =
indicate support for DOIC, and any


   needed DOIC parameters by inserting =
an OC_Supported_Features AVP


   (Section 4.1) into existing requests=
 and responses.  Reporting nodes


   send OLRs by inserting OC-OLR AVPs.&=
nbsp; (Section 4.3)


 


   A given OLR applies to the Diameter =
realm and application of the


   Diameter message that carries it.&nb=
sp; If a reporting node supports more


   than one realm and/or application, i=
t reports independently for each


   combination of realm and application=
.  Similarly, OC-Feature-Vector


   AVPs apply to the realm and applicat=
ion of the enclosing message.


   This implies that a node may support=
 DOIC for one application and/or


   realm, but not another, and may indi=
cate different DOIC parameters


   for each application and realm for w=
hich it supports DOIC.


 


   Reacting nodes perform overload abat=
ement according to an agreed-upon


   abatement algorithm.  An abatem=
ent algorithm defines the meaning of


   the parameters of an OLR, and the pr=
ocedures required for overload


   abatement.  This document speci=
fies a single must-support algorithm,


   namely the "loss" algorith=
m [ref?].  Future specifications may


   introduce new algorithms.=



 


   Overload conditions may vary in scop=
e.  For example, a single


   Diameter node may be overloaded, in =
which case reacting nodes may


   reasonably attempt to send throttled=
 requests to other destinations


   or via other agents.  On the ot=
her hand, an entire Diameter realm may


   be overloaded, in which case such at=
tempts would do harm.  DOIC OLRs


   have a concept of "report type&=
quot; (Section 4.6), where the type defines


   such behaviors.  Report types a=
re extensible.  This document defines


   report types for overload of a speci=
fic server, and for overload of


   an entire realm.


 


   While a reporting node sends OLRs to=
 "adjacent"
reacting nodes, nodes


   that are "adjacent" for DO=
IC purposes may not be adjacent from a


   Diameter, or transport, perspective.=
  


[MCruz] Using the t=
erm “adjacent” is kind of misleading, even if you later explain=
ed precisely that.


Above paragraph cou=
ld be replaced by “Reacting and reporting nodes are not necessaril=
y adjacent nodes”


 


For example, one or more


   Diameter agents that do not support =
DOIC may exist between a given


   pair of reporting and reacting nodes=
, as long as those agents pass


   unknown AVPs through unmolested.&nbs=
p; The report types described in this


   document can safely pass through non=
-supporting agents.  This may not


   be true for report types defined in =
future specifications.  Documents


   that introduce new report types MUST=
 describe any limitations on


   their use across non-supporting agen=
ts.


 


 










--_000_087A34937E64E74E848732CFF8354B92097A08AAESESSMB101erics_--


From nobody Tue Mar 25 12:14:35 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 138D71A01DC for ; Tue, 25 Mar 2014 12:14:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 haIYK2iCb_Ta for ; Tue, 25 Mar 2014 12:14:07 -0700 (PDT)
Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 41B021A0171 for ; Tue, 25 Mar 2014 12:14:07 -0700 (PDT)
Received: by mail-la0-f48.google.com with SMTP id gf5so729886lab.35 for ; Tue, 25 Mar 2014 12:14:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=Wpnxp22wB+YBAibOGVIX9mME/W1duQhBFzfmS6XGo/g=; b=pTWThaUeCqFg2OQvj3qcbmn0nSD7prj4HnHB3ZfSmvtAePp8yK10+2zqt91XZ7aDp4 PCaJ1mtIsaJaFu9r2C3LKiMRE4LwfT2QIL9LaiKkyf8JH1zXBu22W9wwQLWowNsfCvEB cXt26gt9NWjdBlmUJyIeKPphVQMquCvrB/hQOyi97YG2034ynPekSXXNpUXqf/heZzuo IK4y3dkkGQhp4tpCM+MHfRd6e4ha3Tct1R+BDtNzfwsNOjbzN+ua+fvCIzF34UP4hfG2 +XK5tdxZG/yRBPzl5fqYbzXuVv+psxU7zW0QNU+WdgnY6XgQt0te9am4ABms1pLyyoNR oHLA==
X-Received: by 10.112.41.227 with SMTP id i3mr2158337lbl.41.1395774845093; Tue, 25 Mar 2014 12:14:05 -0700 (PDT)
Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id jh4sm12367912lbb.26.2014.03.25.12.14.03 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 25 Mar 2014 12:14:04 -0700 (PDT)
From: Jouni Korhonen 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <50A35097-81C9-4BC5-B484-3B7D2B8C9CFC@gmail.com>
Date: Tue, 25 Mar 2014 21:14:07 +0200
To: "dime@ietf.org list" 
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9PhUe4CB3dVU5i6SV2c4yufRQkQ
Subject: [Dime] IETF #89 meeting minutes
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, 25 Mar 2014 19:14:09 -0000

Folks,

For some reason the minutes were not uploaded (blame sun
spots or orientation of planets). Here they go, sorry
for the lag.

http://www.ietf.org/proceedings/89/minutes/minutes-89-dime

- Jouni

ps: and thanks to Jean for excellent notes again!


From nobody Tue Mar 25 13:46:10 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 6F2601A0215 for ; Tue, 25 Mar 2014 13:46:06 -0700 (PDT)
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 YHO_w3Eeh_Mo for ; Tue, 25 Mar 2014 13:46:00 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 595B41A0225 for ; Tue, 25 Mar 2014 13:46:00 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:59346 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSUPZ-0003et-Hp; Tue, 25 Mar 2014 09:41:20 -0700
Message-ID: <5331B195.9020402@usdonovans.com>
Date: Tue, 25 Mar 2014 11:40:53 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: lionel.morand@orange.com,  Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------010206070107030704060206"
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/oALznxKvYf26-9Xc2yg45Mt4k-M
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 20:46:06 -0000

This is a multi-part message in MIME format.
--------------010206070107030704060206
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Consensus is obviously a fleeting and temporary thing.

Let us make sure that we are precise in our definitions of the report
types we are discussing.

Host report - Applies when the destination-host AVP is present in the
request.
Realm-Routed-Request (RRR) - Applies when there is no destination-host
AVP in the request.
Realm - Applies to 100% of requests sent to the realm.

These are the definitions used in our discussions in London and in
various places in our email discussions. 

Can we please agree to use these definitions going forward so we are all
talking about the same thing.

Regards,

Steve

On 3/25/14 10:27 AM, lionel.morand@orange.com wrote:
>
> Hi Maria Cruz, All,
>
>  
>
> In the previous mail, you wrote:
>
>  
>
> /That is, we have two reports, host and realm. /
>
> /Host applies when Destination_host is present, and then it takes
> precedence over Realm. If both are present, only Host is applied./
>
> /Realm applies when only Destination_realm is present./
>
>  
>
> And I agree with this statement. But I'm not sure that this is the
> case discussed by Ulrich.
>
>  
>
> Whatever the name of the realm report type, is there an agreement on
> the description given above by Maria Cruz and discussed in London?
>
>  
>
> Regards,
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria Cruz
> Bartolome
> *Envoyé :* mardi 25 mars 2014 16:21
> *À :* Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
> *Objet :* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Dear all,
>
>  
>
> I support option 1 a well
>
> Cheers
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Wiehe,
> Ulrich (NSN - DE/Munich)
> *Sent:* martes, 25 de marzo de 2014 16:15
> *To:* ext Steve Donovan; dime@ietf.org
> *Subject:* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Steve,
>
> Thank you for this summary.
>
> Please see inline.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Tuesday, March 25, 2014 2:49 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> 
> *Subject:* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Ulrich,
>
> I mean going backwards from where I thought we were after the London
> meeting.
>
> We are clearly out of sync but hopefully we can fix that.
>
> Here's my understanding of the status of #23 and #55.
>
> Prior to London meeting:
>
> #23 status:
>  - Agreement to change the name of existing realm reports to
> realm-routed-reports (RRR).
>
> this includes agreement to keep the (newly called)
> realm-routed-reports
>  - Discussions were ongoing as to the need for both realm reports and
> RRR reports.
>
> I would say "...as to the need for realm reports in addition
> to realm-routed-reports" 
>
>
>
> #55 status:
>   - Agreement on adding Realm reports based on the definition that
> realm reports apply to all traffic sent to the realm.
>
> This is what I'm missing. The issue has been very briefly
> discussed under #34 without conclusion. There was no discussion under
> #55*//*
>
>
>   - Limited discussion on the interaction between the new realm
> reports and the existing host and RRR reports.
>
> After London meeting:
>
> #23 status:
>   - Tentative agreement in London meeting to remove RRR reports.
>
> What was the technical argument?
>
>
>   - Ben expressed the strongest concern with this plan.  Steve and Ben
> took action to discuss and come back with a recommendation. 
>
> #55 status:
>   - No change
>
> Summary:
>   - Tentative consensus reached to move forward with two report types
> - host and realm, with realm having the new definition.
> What was the technical argument?
>
>
> Current status:
>
> #23 status:
>  - Change the name to RRR
>  - Whether or not to remove RRR and revisit later or keep RRR and
> revisit later is an open issue.
>
> #55 status:
>   - My opinion is that we have at least rough consensus on the need to
> support realm reports.  Others might have a different opinion.
>
>  There was no comment posted to issue #55, also no proposed
> solution, so I cannot see where the consensus came from
>
>
>
> Summary:
>   - I believe we have three options:
>
>    1) Support host and RRR reports
>    2) Support host and Realm reports -- This was the tentative plan
> coming out of the London meeting
>
> < Ulrich> There is not even an issue number identifying problems with
> RRR and proposing to remove RRR
>
>
>    3) Support host, RRR and Realm reports
>
>  I support option 1
>
>
> Regards,
>
> Steve
>
> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>     I don't think we are going backwards (we may be out of synch though)
>
>      
>
>     Can you please summarize the status of #23 and #55.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>     *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Monday, March 24, 2014 7:38 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>     
>     *Subject:* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Ok, we are going backwards on this one.
>
>     I did not include option three because we had moved past that
>     option in our discussions, both on the list (I thought), and in
>     the meeting.
>
>     I believe that we had come to rough consensus on the need for a
>     realm report and the only remaining issue was whether we also
>     included the RRR report type.
>
>     At this point, the only option is to leave all of the issues
>     related to the report types open and attempt to resolve them in
>     the -03 draft.
>
>     Steve
>
>     On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Steve,
>
>          
>
>         I do not agree.
>
>          
>
>         We should still have the option
>
>         3) support report type 0 (this is called host report) and
>         support of report type 1 (this has been called relam report
>         but people argued it should better be called realm routed
>         request report).
>
>          
>
>         Whether or not we need in addition to type 0 and type 1 (or as
>         a replacement of type 1) a
>         realm-no-matter-whether-destination-host-is present-or-not
>         report   is an open issue (see #55).
>
>         There are a lot of open questions  with regard to #55 and I
>         have not seen a conclusion.
>
>         Where I have seen a conclusion is issue #34 and that is inline
>         with option 3).
>
>          
>
>         Unless we conclude on #55, or decide to re-open #34, option 3)
>         is what should go in the -02 draft.
>
>          
>
>          
>
>         Ulrich
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>         Steve Donovan
>         *Sent:* Monday, March 24, 2014 2:57 PM
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Resolution on action to discuss the need
>         for Realm-Routed-Reports
>
>          
>
>         Ulrich,
>         All,
>
>         We have two options for the -02 draft.
>
>         1) Support Host and Realm as proposed below, removing RRR reports.
>         2) Support Host, Realm and RRR reports.
>
>         The default plan is to go with option 1 in the -02 draft, as
>         that was the proposal that came out of the meeting in London. 
>         RRR reports can be added back in if and when we are convinced
>         of the need. 
>
>         If there are strong objections to this then I will update the
>         -02 draft to reflect all three report types.
>
>         I plan to make these updates Wednesday morning, Dallas, Texas
>         time.
>
>         Either way I do not expect we will have agreed to wording on
>         the interaction between the report types when a reacting node
>         has multiple report types, all of which apply to individual
>         requests.  This will need to be addressed in the -03 draft.
>
>         Regards,
>
>         Steve
>
>         On 3/21/14 4:05 PM, Steve Donovan wrote:
>
>             Ulrich,
>
>             The discussion should be captured in the minutes to the
>             meeting.  I wasn't able to find them posted yet.
>
>             Jouni, Lionel, what is the status of the minutes for the
>             meeting?
>
>             My reading of emails prior to the London meeting is
>             different from yours.  I believe we had come to the
>             conclusion that we needed host and realm (with the
>             definition of realm as outlined below).  We were still
>             discussing the need for Realm-Routed-Request reports.
>
>             Regards,
>
>             Steve
>
>             On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>                 Steve,
>
>                  
>
>                 I don't know what happend in London.
>
>                 Can you please summarize the technical reasons that
>                 led to the London agreement.
>
>                 E-mail discussions prior to London have clearly
>                 directed towards a report type that requests
>                 throttling of realm routed request messages (i.e. not
>                 containing a destination host) rather than a report
>                 type that requests throttling of messages routed
>                 towards a realm (no matter whether they contain a
>                 destination host or not).   
>
>                  
>
>                 Ulrich
>
>                  
>
>                 *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf
>                 Of *ext Steve Donovan
>                 *Sent:* Friday, March 21, 2014 3:33 PM
>                 *To:* dime@ietf.org 
>                 *Subject:* [Dime] Resolution on action to discuss the
>                 need for Realm-Routed-Reports
>
>                  
>
>                 All,
>
>                 Ben and I took the action item to discuss the need for
>                 the Realm-Routed-Reports (RRR) report type.
>
>                 As you may recall, the consensus coming out of the
>                 DIME WG meeting in London was to support two report types:
>
>                 - Host -- Impacting requests with a Destination-Host
>                 AVP matching the host in the overload report (with the
>                 host implicitly determined from the Origin-Host AVP of
>                 the answer message carrying the overload report).
>
>                 - Realm -- Impacting 100% of the requests with a
>                 Destination-Realm AVP matching the realm in the
>                 overload report (with the realm implicitly determine
>                 from the Origin-Realm of the answer message carrying
>                 the overload report).
>
>                 The action Ben and I took was to come back with an
>                 opinion on whether RRR reports should also be supported.
>
>                 My summary of the discussion is that we recommend to
>                 NOT include RRR reports in the current version of the
>                 base DOIC draft. 
>
>                 We still have some concerns with the granularity of
>                 control enabled by having just the two report types
>                 but the analysis of whether RRR reports are still
>                 needed can occur independent of the base DOIC draft. 
>                 If there is a determination that RRRs are needed in
>                 time to include in the base draft then it can be
>                 considered at that time.
>
>                 Based on this, I propose the following
>
>                 - Resolution to issue #23 is to remove RRR reports
>                 from the document.
>                 - Resolution to issue #55 is to add Realm reports
>                 (actually to redefine them per the above definition).
>                 - Resolution to issue #57 is that it no longer applies
>                 (as it deals with RRRs).
>
>                 There is also need for text describing the interaction
>                 between host and the realm reports.  I don't expect we
>                 will have consensus on this wording prior to the -02
>                 draft being submitted.  To this end, I'll open a new
>                 issue to deal with the need for wording on the
>                 interaction.
>
>                 Regards,
>
>                 Steve
>
>
>
>
>
>             _______________________________________________
>
>             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.


--------------010206070107030704060206
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Consensus is obviously a
      fleeting and temporary thing.

      

      Let us make sure that we are precise in our definitions of the
      report types we are discussing.

      

      Host report - Applies when the destination-host AVP is present in
      the request.

      Realm-Routed-Request (RRR) - Applies when there is no
      destination-host AVP in the request.

      Realm - Applies to 100% of requests sent to the realm.

      

      These are the definitions used in our discussions in London and in
      various places in our email discussions.  

      

      Can we please agree to use these definitions going forward so we
      are all talking about the same thing.

      

      Regards,

      

      Steve

      

    
    
On 3/25/14 10:27 AM,
      lionel.morand@orange.com wrote:

    

    

      
      
      
      

        
Hi
            Maria Cruz, All,

        
 

        
In the previous mail, you wrote:

        
 

        
That is, we have two reports, host and realm.
              

        
Host applies when Destination_host is
              present, and then it takes precedence over Realm. If both
              are present, only Host is applied.

        
Realm applies when only Destination_realm is
              present.

        
 

        
And I agree with this statement. But I'm not
            sure that this is the case discussed by Ulrich.

        
 

        
Whatever the name of the realm report type, is
            there an agreement on the description given above by Maria
            Cruz and discussed in London?

        
 

        
Regards,

        
 

        
Lionel

        
 

        

          

            
De :
                DiME [mailto:dime-bounces@ietf.org]
                De la part de Maria Cruz Bartolome

                Envoyé : mardi 25 mars 2014 16:21

                À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve
                Donovan; dime@ietf.org

                Objet : Re: [Dime] Resolution on action to
                discuss the need for Realm-Routed-Reports

          

        

        
 

        
Dear all,

        
 

        
I support option 1 a well

        
Cheers

        
/MCruz

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

                Sent: martes, 25 de marzo de 2014 16:15

                To: ext Steve Donovan; dime@ietf.org

                Subject: Re: [Dime] Resolution on action to
                discuss the need for Realm-Routed-Reports

          

        

        
 

        
Steve,

        
Thank you for this summary.

        
Please see inline.

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                

                Sent: Tuesday, March 25, 2014 2:49 PM

                To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

                Subject: Re: [Dime] Resolution on action to
                discuss the need for Realm-Routed-Reports

          

        

        
 

        
Ulrich,

            

            I mean going backwards from where I thought we were after
            the London meeting.

            

            We are clearly out of sync but hopefully we can fix that.

            

            Here's my understanding of the status of #23 and #55.

            

          Prior to London meeting:

            

            #23 status:

             - Agreement to change the name of existing realm reports to
            realm-routed-reports (RRR).

        
<Ulrich>this includes agreement to keep
            the (newly called) realm-routed-reports</Ulrich>

             - Discussions were ongoing as to the need for both realm
            reports and RRR reports.

        
<Ulrich>I would say “…as to the need for
            realm reports in addition to realm-routed-reports”
            </Ulrich>

        


            

            #55 status:

              - Agreement on adding Realm reports based on the
            definition that realm reports apply to all traffic sent to
            the realm.

        
<Ulrich>This is what I’m missing. The
            issue has been very briefly discussed under #34 without
            conclusion. There was no discussion under #55</Ulrich>

        


              - Limited discussion on the interaction between the new
            realm reports and the existing host and RRR reports.

            

          After London meeting:

            

            #23 status:

              - Tentative agreement in London meeting to remove RRR
            reports.

        
<Ulrich>What was the technical
            argument?</Ulrich>

        


              - Ben expressed the strongest concern with this plan.  Steve and Ben took action to discuss and come back
            with a recommendation. 
            

            

            #55 status:

              - No change

            

            Summary:

              - Tentative consensus reached to move forward with two
            report types - host and realm, with realm having the new
            definition.

          <Ulrich>What was the technical
            argument?</Ulrich>

        


            Current status:

            

            #23 status:

             - Change the name to RRR

             - Whether or not to remove RRR and revisit later or keep
            RRR and revisit later is an open issue.

            

            #55 status:

              - My opinion is that we have at least rough consensus on
            the need to support realm reports.  Others might have a
            different opinion.

        
<Ulrich> There was no comment posted to
            issue #55, also no proposed solution, so I cannot see where
            the consensus came from</Ulrich>

        


            

            Summary:

              - I believe we have three options:

            

               1) Support host and RRR reports

               2) Support host and Realm reports -- This was the
            tentative plan coming out of the London meeting

        
< Ulrich> There is not even an issue
            number identifying problems with RRR and proposing to remove
            RRR</Ulrich>

        


               3) Support host, RRR and Realm reports

        
<Ulrich> I support option
            1</Ulrich>

        


            Regards,

            

            Steve

        

          
On 3/25/14 6:44 AM,
              Wiehe, Ulrich (NSN - DE/Munich) wrote:

        

        

          
Steve,

          
I don’t think we are going backwards (we may
              be out of synch though)

          
 

          
Can you please summarize the status of #23
              and #55.

          
 

          
Ulrich

          
 

          
 

          

            

              
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Sent: Monday, March 24, 2014 7:38 PM

                  To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

                  Subject: Re: [Dime] Resolution on action to
                  discuss the need for Realm-Routed-Reports

            

          

          
 

          
Ok, we are going backwards on this one.

              

              I did not include option three because we had moved past
              that option in our discussions, both on the list (I
              thought), and in the meeting.
              

              

              I believe that we had come to rough consensus on the need
              for a realm report and the only remaining issue was
              whether we also included the RRR report type.

              

              At this point, the only option is to leave all of the
              issues related to the report types open and attempt to
              resolve them in the -03 draft.

              

              Steve

          

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

          

          

            
Steve,

            
 

            
I do not agree.

            
 

            
We should still have the option
              

            
3) support report type 0 (this is called
                host report) and support of report type 1 (this has been
                called relam report but people argued it should better
                be called realm routed request report).

            
 

            
Whether or not we need in addition to type
                0 and type 1 (or as a replacement of type 1) a
                realm-no-matter-whether-destination-host-is
                present-or-not report   is an open issue (see #55).

            
There are a lot of open questions  with
                regard to #55 and I have not seen a conclusion.

            
Where I have seen a conclusion is issue #34
                and that is inline with option 3).

            
 

            
Unless we conclude on #55, or decide to
                re-open #34, option 3) is what should go in the -02
                draft.

            
 

            
 

            
Ulrich

            
 

            

              

                
From: DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of ext Steve Donovan

                    Sent: Monday, March 24, 2014 2:57 PM

                    To: dime@ietf.org

                    Subject: Re: [Dime] Resolution on action to
                    discuss the need for Realm-Routed-Reports

              

            

            
 

            
Ulrich,

                All,

                

                We have two options for the -02 draft.

                

                1) Support Host and Realm as proposed below, removing
                RRR reports.

                2) Support Host, Realm and RRR reports.

                

                The default plan is to go with option 1 in the -02
                draft, as that was the proposal that came out of the
                meeting in London.  RRR reports can be added back in if
                and when we are convinced of the need. 
                

                

                If there are strong objections to this then I will
                update the -02 draft to reflect all three report types.

                

                I plan to make these updates Wednesday morning, Dallas,
                Texas time.

                

                Either way I do not expect we will have agreed to
                wording on the interaction between the report types when
                a reacting node has multiple report types, all of which
                apply to individual requests.  This will need to be
                addressed in the -03 draft.

                

                Regards,

                

                Steve

            

              
On 3/21/14 4:05 PM,
                  Steve Donovan wrote:

            

            

              
Ulrich,

                  

                  The discussion should be captured in the minutes to
                  the meeting.  I wasn't able to find them posted yet.

                  

                  Jouni, Lionel, what is the status of the minutes for
                  the meeting?

                  

                  My reading of emails prior to the London meeting is
                  different from yours.  I believe we had come to the
                  conclusion that we needed host and realm (with the
                  definition of realm as outlined below).  We were still
                  discussing the need for Realm-Routed-Request reports.

                  

                  Regards,

                  

                  Steve

              

                
On 3/21/14 10:09
                    AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

              

              

                
Steve,

                
 

                
I don’t know what happend in London.

                
Can you please summarize the technical
                    reasons that led to the London agreement.
                  

                
E-mail discussions prior to London have
                    clearly directed towards a report type that requests
                    throttling of realm routed request messages (i.e.
                    not containing a destination host) rather than a
                    report type that requests throttling of messages
                    routed towards a realm (no matter whether they
                    contain a destination host or not).   

                
 

                
Ulrich

                
 

                

                  

                    
From: DiME [mailto:dime-bounces@ietf.org]
                        On Behalf Of ext Steve Donovan

                        Sent: Friday, March 21, 2014 3:33 PM

                        To: dime@ietf.org

                        Subject: [Dime] Resolution on action to
                        discuss the need for Realm-Routed-Reports

                  

                

                
 

                
All,

                    

                    Ben and I took the action item to discuss the need
                    for the Realm-Routed-Reports (RRR) report type.

                    

                    As you may recall, the consensus coming out of the
                    DIME WG meeting in London was to support two report
                    types:

                    

                    - Host -- Impacting requests with a Destination-Host
                    AVP matching the host in the overload report (with
                    the host implicitly determined from the Origin-Host
                    AVP of the answer message carrying the overload
                    report).

                    

                    - Realm -- Impacting 100% of the requests with a
                    Destination-Realm AVP matching the realm in the
                    overload report (with the realm implicitly determine
                    from the Origin-Realm of the answer message carrying
                    the overload report).

                    

                    The action Ben and I took was to come back with an
                    opinion on whether RRR reports should also be
                    supported.

                    

                    My summary of the discussion is that we recommend to
                    NOT include RRR reports in the current version of
                    the base DOIC draft. 
                    

                    

                    We still have some concerns with the granularity of
                    control enabled by having just the two report types
                    but the analysis of whether RRR reports are still
                    needed can occur independent of the base DOIC
                    draft.  If there is a determination that RRRs are
                    needed in time to include in the base draft then it
                    can be considered at that time.

                    

                    Based on this, I propose the following 

                    

                    - Resolution to issue #23 is to remove RRR reports
                    from the document.

                    - Resolution to issue #55 is to add Realm reports
                    (actually to redefine them per the above
                    definition).

                    - Resolution to issue #57 is that it no longer
                    applies (as it deals with RRRs).

                    

                    There is also need for text describing the
                    interaction between host and the realm reports.  I
                    don't expect we will have consensus on this wording
                    prior to the -02 draft being submitted.  To this
                    end, I'll open a new issue to deal with the need for
                    wording on the interaction.

                    

                    Regards,

                    

                    Steve 

              

              


                  

                  

                  

                  

              
_______________________________________________

              
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.


    

    

  


--------------010206070107030704060206--


From nobody Tue Mar 25 13:55: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 A27C91A0245 for ; Tue, 25 Mar 2014 13:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 9dxkaCaZB6ny for ; Tue, 25 Mar 2014 13:55:14 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 644B41A0248 for ; Tue, 25 Mar 2014 13:55:14 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60272 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSYNK-0007fg-R4 for dime@ietf.org; Tue, 25 Mar 2014 13:55:12 -0700
Message-ID: <5331ED2E.4030507@usdonovans.com>
Date: Tue, 25 Mar 2014 15:55:10 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------060306090203070507030901"
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/yiMT0jRX89rzmjI541RW8zdJklQ
Subject: [Dime] Issue #23 - Proposed resolution
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, 25 Mar 2014 20:55:15 -0000

This is a multi-part message in MIME format.
--------------060306090203070507030901
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

Given that we do not have consensus on removing Realm-Routed-Request
reports, I propose that we resolve issue 23 by renaming what is called
Realm reports in the -01 draft to Realm-Routed-Reports in the -02 draft.

I will update the issue with the text changes when I make them, but I
will do nothing but change the name and make the wording consistent in
that Realm-Routed-Reports apply to requests sent to the realm that do
not have a Destination-Host AVP.

Regards,

Steve

--------------060306090203070507030901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      Given that we do not have consensus on removing
      Realm-Routed-Request reports, I propose that we resolve issue 23
      by renaming what is called Realm reports in the -01 draft to
      Realm-Routed-Reports in the -02 draft.

      

      I will update the issue with the text changes when I make them,
      but I will do nothing but change the name and make the wording
      consistent in that Realm-Routed-Reports apply to requests sent to
      the realm that do not have a Destination-Host AVP.

      

      Regards,

      

      Steve

    
  


--------------060306090203070507030901--


From nobody Tue Mar 25 14:10: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 02A661A022A for ; Tue, 25 Mar 2014 14:10:29 -0700 (PDT)
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 3DfOOtNfsAaG for ; Tue, 25 Mar 2014 14:10:25 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 154161A0212 for ; Tue, 25 Mar 2014 14:10:25 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60414 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSYc0-0002Se-Gq for dime@ietf.org; Tue, 25 Mar 2014 14:10:23 -0700
Message-ID: <5331F0BC.5080207@usdonovans.com>
Date: Tue, 25 Mar 2014 16:10:20 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> <533081C6.9080103@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D205C@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000906020209040509080401"
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/FannO51F1AMvu_ZAFkjr8NPVqDg
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 21:10:29 -0000

This is a multi-part message in MIME format.
--------------000906020209040509080401
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

Ulrich straightened me out on the need to keep the state around until it
expires.  As such, I don't believe there is the need for per reacting
node support in the reporting node.

Regards,

Steve

On 3/25/14 4:24 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi Ulrich Steve
>
>  
>
> From the Ulrich use case about deletion of OCS, which is for me
> valid,  I understand that the reporting node has to ensure that all
> its clients received its updated  OLR with validity time 0,  so with
> the hope this does not create  an "OCS status" per client. Steve
> statement applies when there is a per client handling of  the OLR in
> the reporting node (this is another discussion point). The fact to
> globally handle the clients has also some consequences even if there
> is an interest for it.
>
>  
>
> Best regards.
>
>  
>
> JJacques  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Wiehe,
> Ulrich (NSN - DE/Munich)
> *Envoyé :* mardi 25 mars 2014 10:08
> *À :* ext Steve Donovan; dime@ietf.org
> *Objet :* Re: [Dime] issue #56 proposed conclusion
>
>  
>
> Steve,
>
>  
>
> please see inline.
>
>  
>
> Ulrich
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, March 24, 2014 8:05 PM
> *To:* dime@ietf.org 
> *Subject:* Re: [Dime] issue #56 proposed conclusion
>
>  
>
> Ulrich,
>
> I have a few comments inline (towards the end of your proposal).
>
> Steve
>
> On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Dear all,
>
>      
>
>     I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
>      
>
>     I'm fine with not abbreviating "Overload Control State".
>
>      
>
>     I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
>      
>
>     Ulrich
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) 
>
>     Sent: Thursday, March 20, 2014 2:08 PM
>
>     To: dime@ietf.org 
>
>     Subject: issue #56 proposed conclusion
>
>      
>
>     #56: Bad Description of Overload Control State
>
>      
>
>      
>
>     Dear all,
>
>      
>
>     I have received comments from Steve, MCruz and Jouni.
>
>      
>
>     I believe all comments are covered by the following proposed text:
>
>      
>
>      
>
>      
>
>         5.5.1.  Overload Control State (OCS)
>
>      
>
>         5.5.1.1   Overload Control States for reacting nodes
>
>      
>
>         A reacting node 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 towards
>
>           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 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
>
>         following information:
>
>         - Sequence number (as reveived in OC-OLR)
>
>         - Time of expiry  (deviated from validity duration as received in OC-OLR
>
>           and time of reception)
>
>         - Selected Abatement Algorithm (as received in OC-Supported-Features)
>
>         - Algorithm specific input data (as received within OC-OLR, e.g.
>
>           Reduction Percentage for Loss)
>
>      
>
>        
>
>         5.5.1.2   Overload Control States for reporting nodes
>
>      
>
>         A reporting node maintains per supported Diameter application and per
>
>         supported (and eventually selected) Abatement Algorithm an Overload
>
>         Control State. 
>
>      
>
>         An Overload Control State may be identified by the pair of Application-Id
>
>         and supported Abatement Algorithm.
>
>      
>
>         The Overload Control State for a given pair of Application and Abatement
>
>         Algorithm could include the information:
>
>         - Sequence number
>
>         - Validity Duration and Expiry Time
>
>         - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>      
>
>         
>
>         5.5.1.3  Maintaining Overload Control States
>
>      
>
>         Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>
>         an answer message of application app-id containing an Orig-Host of host-id and a
>
>         host-type OC-OLR AVP unless such host-type OCS already exists.
>
>      
>
>         Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>
>         an answer message of application app-id containing an Orig-Realm of realm-id and a
>
>         realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>      
>
>         Reacting nodes delete an OCS when it expires (i.e. when current time
>
>         minus reception time is greater than validity duration).
>
>      
>
>         Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>
>         receiving an answer message of application app-id containing an Orig-Host of
>
>         host-id and a host-type OC-OLR AVP with a sequence number higher than the
>
>         stored sequence number.
>
>      
>
>         Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>
>         receiving an answer message of application app-id containing an Orig-Realm of
>
>         realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>
>         stored sequence number.
>
>      
>
>         Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>
>         request of application app-id containing an OC-Supported-Features AVP
>
>         indicating support of the Abatement Algorithm Alg (which the reporting
>
>         node selects) while being overloaded, unless such OCS already exists.
>
> SRD> I would think the reporting node would create the OCS when it
> determines it needs a reduction, independent when it receives requests
> from various reacting nodes. 
>  when not receiving requests, there is no need for reduction;
> the need of reduction is determined when a request is received.
>
> Furthermore: If the reporting node determines that it needs a
> reduction independently from a received request, which Algorithm would
> it select? 
>
>  
>  
>     Reporting nodes delete an OCS when it expires.
>
> SRD> Or when it explicitly sends an OLR with validity duration of zero.
>
>  no. Let me give an example:
>
> Server S has an OCS identified by the pair (Application x, Loss) with
> the content: Sequence number =5, duration= 30 sec/expiry time=
> 9:45:59, percentage =10%.
>
> At 9:45:30 Client C1 sends an application x request to S and gets back
> an OLR indicating 10% for 30 sec.
>
> At 9.45:57 Client C2 send an application x request to S and gets back
> an OLR indicating 10% for 30sec.
>
> At 9:45:58 S decides that it is no longer overloaded. It therefore
> updates the OCS to contain: sequence number=6, duration = 0sec/expiry
> time= 9:46:30, percentage =0%.
>
> At 9:45:59 C1 sends an application x request to S and gets back the
> explicit OLR with validity duration of zero. S must not delet the OCS
> at this time.
>
> At 9:46:01 C2 sends an application x request to S and (because the OCS
> was not deleted in the previous step) gets back the explicit OLR with
> validity duration of zero. If the OCS was deleted in the previous step
> C2 would continue throttling until 9:46:27.
>
>  
>
>  
>  
>     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>     need to modify the requested amount of application app-id traffic reduction.
>  
> 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


--------------000906020209040509080401
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      Ulrich straightened me out on the need to keep the state around
      until it expires.  As such, I don't believe there is the need for
      per reacting node support in the reporting node.

      

      Regards,

      

      Steve

      

    
    
On 3/25/14 4:24 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi
            Ulrich Steve

        
 

        
From
            the Ulrich use case about deletion of OCS, which is for me
            valid,  I understand that the reporting node has to ensure
            that all its clients received its updated  OLR with validity
            time 0,  so with the hope this does not create  an “OCS
            status” per client. Steve statement applies when there is a
            per client handling of  the OLR in the reporting node (this
            is another discussion point). The fact to globally handle
            the clients has also some consequences even if there is an
            interest for it.

        
 

        
Best regards.

        
 

        
JJacques  

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Wiehe, Ulrich (NSN - DE/Munich)

                Envoyé : mardi 25 mars 2014 10:08

                À : ext Steve Donovan; dime@ietf.org

                Objet : Re: [Dime] issue #56 proposed conclusion

          

        

        
 

        
Steve,

        
 

        
please see inline.

        
 

        
Ulrich

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Monday, March 24, 2014 8:05 PM

                To: dime@ietf.org

                Subject: Re: [Dime] issue #56 proposed conclusion

          

        

        
 

        
Ulrich,

            

            I have a few comments inline (towards the end of your
            proposal).

            

            Steve

        

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

        

        

          
Dear all,

          
 

          
I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

          
 

          
I'm fine with not abbreviating "Overload Control State".

          
 

          
I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

          
 

          
Ulrich

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) 

          
Sent: Thursday, March 20, 2014 2:08 PM

          
To: dime@ietf.org

          
Subject: issue #56 proposed conclusion

          
 

          
#56: Bad Description of Overload Control State

          
 

          
 

          
Dear all,

          
 

          
I have received comments from Steve, MCruz and Jouni.

          
 

          
I believe all comments are covered by the following proposed text:

          
 

          
 

          
 

          
    5.5.1.  Overload Control State (OCS)

          
 

          
    5.5.1.1   Overload Control States for reacting nodes

          
 

          
    A reacting node 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 towards

          
      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 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

          
    following information:

          
    - Sequence number (as reveived in OC-OLR)

          
    - Time of expiry  (deviated from validity duration as received in OC-OLR

          
      and time of reception)

          
    - Selected Abatement Algorithm (as received in OC-Supported-Features)

          
    - Algorithm specific input data (as received within OC-OLR, e.g.

          
      Reduction Percentage for Loss)

          
 

          
   

          
    5.5.1.2   Overload Control States for reporting nodes

          
 

          
    A reporting node maintains per supported Diameter application and per

          
    supported (and eventually selected) Abatement Algorithm an Overload

          
    Control State. 

          
 

          
    An Overload Control State may be identified by the pair of Application-Id

          
    and supported Abatement Algorithm.

          
 

          
    The Overload Control State for a given pair of Application and Abatement

          
    Algorithm could include the information:

          
    - Sequence number

          
    - Validity Duration and Expiry Time

          
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

          
 

          
    

          
    5.5.1.3  Maintaining Overload Control States

          
 

          
    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving

          
    an answer message of application app-id containing an Orig-Host of host-id and a

          
    host-type OC-OLR AVP unless such host-type OCS already exists.

          
 

          
    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving

          
    an answer message of application app-id containing an Orig-Realm of realm-id and a

          
    realm-type OC-OLR AVP unless such realm type OCS already exists.

          
 

          
    Reacting nodes delete an OCS when it expires (i.e. when current time

          
    minus reception time is greater than validity duration).

          
 

          
    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when

          
    receiving an answer message of application app-id containing an Orig-Host of

          
    host-id and a host-type OC-OLR AVP with a sequence number higher than the

          
    stored sequence number.

          
 

          
    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when

          
    receiving an answer message of application app-id containing an Orig-Realm of

          
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the

          
    stored sequence number.

          
 

          
    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a

          
    request of application app-id containing an OC-Supported-Features AVP

          
    indicating support of the Abatement Algorithm Alg (which the reporting

          
    node selects) while being overloaded, unless such OCS already exists.

        

        
SRD> I would think the reporting node
          would create the OCS when it determines it needs a reduction,
          independent when it receives requests from various reacting
          nodes. 
          

          <Ulrich> when not receiving
            requests, there is no need for reduction; the need of
            reduction is determined when a request is received.

        
Furthermore: If
            the reporting node determines that it needs a reduction
            independently from a received request, which Algorithm would
            it select? </Ulrich>

        
 

        
 

        
    Reporting nodes delete an OCS when it expires.

        
SRD> Or when it
            explicitly sends an OLR with validity duration of zero.

        
<Ulrich>
            no. Let me give an example:

        
Server
            S has an OCS identified by the pair (Application x, Loss)
            with the content: Sequence number =5, duration= 30
            sec/expiry time= 9:45:59, percentage =10%.

        
At
            9:45:30 Client C1 sends an application x request to S and
            gets back an OLR indicating 10% for 30 sec.

        
At
            9.45:57 Client C2 send an application x request to S and
            gets back an OLR indicating 10% for 30sec.

        
At
            9:45:58 S decides that it is no longer overloaded. It
            therefore updates the OCS to contain: sequence number=6,
            duration = 0sec/expiry time= 9:46:30, percentage =0%.

        
At
            9:45:59 C1 sends an application x request to S and gets back
            the explicit OLR with validity duration of zero. S must not
            delet the OCS at this time.

        
At
            9:46:01 C2 sends an application x request to S and (because
            the OCS was not deleted in the previous step) gets back the
            explicit OLR with validity duration of zero. If the OCS was
            deleted in the previous step C2 would continue throttling
            until 9:46:27.</Ulrich>

        
 

        
 

        
 

        
    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the

        
    need to modify the requested amount of application app-id traffic reduction.

        
 

        
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


    

    

  


--------------000906020209040509080401--


From nobody Tue Mar 25 14:11:40 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 ED4611A0207 for ; Tue, 25 Mar 2014 14:11:37 -0700 (PDT)
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 wHn2Xlw6KbJs for ; Tue, 25 Mar 2014 14:11:35 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5C81A00BE for ; Tue, 25 Mar 2014 14:11:35 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60417 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSYd9-0003sk-5j; Tue, 25 Mar 2014 14:11:33 -0700
Message-ID: <5331F103.6050006@usdonovans.com>
Date: Tue, 25 Mar 2014 16:11:31 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> <53308244.5010305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D206F@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D206F@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------060702020707080409090407"
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/YYjIPbMcu4uT-9q-qhXguaBdsk4
Subject: Re: [Dime] issue #56 proposed 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, 25 Mar 2014 21:11:38 -0000

This is a multi-part message in MIME format.
--------------060702020707080409090407
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

I plan to incorporate Ulrich's text in the -02 draft.

Ulrich, can you please copy the proposed text into the issue and close
the ticket.

Thanks,

Steve

On 3/25/14 4:08 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Also fine with me.
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, March 24, 2014 8:07 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] issue #56 proposed conclusion
>
>  
>
> Ulrich,
>
> Acronym overlap is unavoidable.  If we add OCS in the abbreviations
> section then we should be ok.
>
> Steve
>
> On 3/24/14 12:23 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Dear all,
>
>      
>
>     I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
>      
>
>     I'm fine with not abbreviating "Overload Control State".
>
>      
>
>     I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
>      
>
>     Ulrich
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich) 
>
>     Sent: Thursday, March 20, 2014 2:08 PM
>
>     To: dime@ietf.org 
>
>     Subject: issue #56 proposed conclusion
>
>      
>
>     #56: Bad Description of Overload Control State
>
>      
>
>      
>
>     Dear all,
>
>      
>
>     I have received comments from Steve, MCruz and Jouni.
>
>      
>
>     I believe all comments are covered by the following proposed text:
>
>      
>
>      
>
>      
>
>         5.5.1.  Overload Control State (OCS)
>
>      
>
>         5.5.1.1   Overload Control States for reacting nodes
>
>      
>
>         A reacting node 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 towards
>
>           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 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
>
>         following information:
>
>         - Sequence number (as reveived in OC-OLR)
>
>         - Time of expiry  (deviated from validity duration as received in OC-OLR
>
>           and time of reception)
>
>         - Selected Abatement Algorithm (as received in OC-Supported-Features)
>
>         - Algorithm specific input data (as received within OC-OLR, e.g.
>
>           Reduction Percentage for Loss)
>
>      
>
>        
>
>         5.5.1.2   Overload Control States for reporting nodes
>
>      
>
>         A reporting node maintains per supported Diameter application and per
>
>         supported (and eventually selected) Abatement Algorithm an Overload
>
>         Control State. 
>
>      
>
>         An Overload Control State may be identified by the pair of Application-Id
>
>         and supported Abatement Algorithm.
>
>      
>
>         The Overload Control State for a given pair of Application and Abatement
>
>         Algorithm could include the information:
>
>         - Sequence number
>
>         - Validity Duration and Expiry Time
>
>         - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>      
>
>         
>
>         5.5.1.3  Maintaining Overload Control States
>
>      
>
>         Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>
>         an answer message of application app-id containing an Orig-Host of host-id and a
>
>         host-type OC-OLR AVP unless such host-type OCS already exists.
>
>      
>
>         Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>
>         an answer message of application app-id containing an Orig-Realm of realm-id and a
>
>         realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>      
>
>         Reacting nodes delete an OCS when it expires (i.e. when current time
>
>         minus reception time is greater than validity duration).
>
>      
>
>         Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>
>         receiving an answer message of application app-id containing an Orig-Host of
>
>         host-id and a host-type OC-OLR AVP with a sequence number higher than the
>
>         stored sequence number.
>
>      
>
>         Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>
>         receiving an answer message of application app-id containing an Orig-Realm of
>
>         realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>
>         stored sequence number.
>
>      
>
>         Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>
>         request of application app-id containing an OC-Supported-Features AVP
>
>         indicating support of the Abatement Algorithm Alg (which the reporting
>
>         node selects) while being overloaded, unless such OCS already exists.
>
>      
>
>         Reporting nodes delete an OCS when it expires.
>
>      
>
>         Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>
>         need to modify the requested amount of application app-id traffic reduction.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>      
>
>  
>


--------------060702020707080409090407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    All,

      

      I plan to incorporate Ulrich's text in the -02 draft.

      

      Ulrich, can you please copy the proposed text into the issue and
      close the ticket.

      

      Thanks,

      

      Steve

      

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

    

    

      
      
      
      

        
Also
            fine with me.

        
Ulrich

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Monday, March 24, 2014 8:07 PM

                To: dime@ietf.org

                Subject: Re: [Dime] issue #56 proposed conclusion

          

        

        
 

        
Ulrich,

          

          Acronym overlap is unavoidable.  If we add OCS in the
          abbreviations section then we should be ok.

          

          Steve

        

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

        

        

          
Dear all,

          
 

          
I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

          
 

          
I'm fine with not abbreviating "Overload Control State".

          
 

          
I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

          
 

          
Ulrich

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich) 

          
Sent: Thursday, March 20, 2014 2:08 PM

          
To: dime@ietf.org

          
Subject: issue #56 proposed conclusion

          
 

          
#56: Bad Description of Overload Control State

          
 

          
 

          
Dear all,

          
 

          
I have received comments from Steve, MCruz and Jouni.

          
 

          
I believe all comments are covered by the following proposed text:

          
 

          
 

          
 

          
    5.5.1.  Overload Control State (OCS)

          
 

          
    5.5.1.1   Overload Control States for reacting nodes

          
 

          
    A reacting node 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 towards

          
      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 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

          
    following information:

          
    - Sequence number (as reveived in OC-OLR)

          
    - Time of expiry  (deviated from validity duration as received in OC-OLR

          
      and time of reception)

          
    - Selected Abatement Algorithm (as received in OC-Supported-Features)

          
    - Algorithm specific input data (as received within OC-OLR, e.g.

          
      Reduction Percentage for Loss)

          
 

          
   

          
    5.5.1.2   Overload Control States for reporting nodes

          
 

          
    A reporting node maintains per supported Diameter application and per

          
    supported (and eventually selected) Abatement Algorithm an Overload

          
    Control State. 

          
 

          
    An Overload Control State may be identified by the pair of Application-Id

          
    and supported Abatement Algorithm.

          
 

          
    The Overload Control State for a given pair of Application and Abatement

          
    Algorithm could include the information:

          
    - Sequence number

          
    - Validity Duration and Expiry Time

          
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

          
 

          
    

          
    5.5.1.3  Maintaining Overload Control States

          
 

          
    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving

          
    an answer message of application app-id containing an Orig-Host of host-id and a

          
    host-type OC-OLR AVP unless such host-type OCS already exists.

          
 

          
    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving

          
    an answer message of application app-id containing an Orig-Realm of realm-id and a

          
    realm-type OC-OLR AVP unless such realm type OCS already exists.

          
 

          
    Reacting nodes delete an OCS when it expires (i.e. when current time

          
    minus reception time is greater than validity duration).

          
 

          
    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when

          
    receiving an answer message of application app-id containing an Orig-Host of

          
    host-id and a host-type OC-OLR AVP with a sequence number higher than the

          
    stored sequence number.

          
 

          
    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when

          
    receiving an answer message of application app-id containing an Orig-Realm of

          
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the

          
    stored sequence number.

          
 

          
    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a

          
    request of application app-id containing an OC-Supported-Features AVP

          
    indicating support of the Abatement Algorithm Alg (which the reporting

          
    node selects) while being overloaded, unless such OCS already exists.

          
 

          
    Reporting nodes delete an OCS when it expires.

          
 

          
    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the

          
    need to modify the requested amount of application app-id traffic reduction.

          
 

          
Ulrich

          
 

          
 

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

          
 

        

        
 

      

    

    

  


--------------060702020707080409090407--


From nobody Tue Mar 25 14:19:56 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 28BBF1A0256 for ; Tue, 25 Mar 2014 14:19:53 -0700 (PDT)
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 rF5LG1VwtIg2 for ; Tue, 25 Mar 2014 14:19:49 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 214F61A024E for ; Tue, 25 Mar 2014 14:19:49 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60439 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSYl7-00061H-Jm; Tue, 25 Mar 2014 14:19:46 -0700
Message-ID: <5331F2F1.6000301@usdonovans.com>
Date: Tue, 25 Mar 2014 16:19:45 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net> <53309E4F.7050509@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D20E8@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D20E8@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------070903090900050406010105"
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/FrflLbBv7qDxi1BHIGHDcAxbpTE
Subject: Re: [Dime] Issue#31 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, 25 Mar 2014 21:19:53 -0000

This is a multi-part message in MIME format.
--------------070903090900050406010105
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Please see inline.

Steve

On 3/25/14 5:21 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> I think we can easily extend the proposed text for #56 to cover these
> points:
>
>  
>
>  
>
>     5.5.1.  Overload Control State (OCS)
>
>  
>
>     5.5.1.1   Overload Control States for reacting nodes
>
>  
>
>     A reacting node 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
> towards
>
>       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 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
>
>     following information:
>
>     - Sequence number (as reveived in OC-OLR)
>
>     - Time of expiry  (deviated from validity duration as received in
> OC-OLR
>
>       and time of reception)
>
>     - Selected Abatement Algorithm (as received in OC-Supported-Features)
>
>     - Algorithm specific input data (as received within OC-OLR, e.g.
>
>       Reduction Percentage for Loss)
>
>  
>
>   
>
>     5.5.1.2   Overload Control States for reporting nodes
>
>  
>
>     A reporting node maintains per supported Diameter application and per
>
>     supported (and eventually selected) Abatement Algorithm an Overload
>
>     Control State.
>
>  
>
>     An Overload Control State may be identified by the pair of
> Application-Id
>
>     and supported Abatement Algorithm.
>
>  
>
>     The Overload Control State for a given pair of Application and
> Abatement
>
>     Algorithm could include the information:
>
>     - Sequence number
>
>     - Validity Duration and Expiry Time
>
>     - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>     Overload Control States for reporting nodes containing a validity
> duration of 0 sec. should
>
>     not expire before any previously sent (stale) OLR has timed out at
> any reacting node.
>
SRD> I would actually model this differently.  I would have the
following overload state in the reporting node:

- Overload condition status - active or clear (clear meaning that a
previous overload condition has ended)
- Sequence number
- Validity duration to be sent in reports
- Expiration times (time that the state can be removed after the
overload condition clears)
- Application specific data

Then the logic is to send an OLR anytime there is an active overload
condition.  If the status is active then the validity duration is set to
the value in the state object.  If the status is clear then the validity
duration sent is zero.

That said, I'm ok with using your wording in the -02 draft and we can
change it in -03 if needed.
>
>    
>
>     5.5.1.3  Maintaining Overload Control States
>
>  
>
>     Reacting nodes create a host-type OCS identified by OCS-Id =
> (app-id,host-id) when receiving
>
>     an answer message of application app-id containing an Orig-Host of
> host-id and a
>
>     host-type OC-OLR AVP unless such host-type OCS already exists.
>
>  
>
>     Reacting nodes create a realm-type OCS identified by OCS-Id =
> (app-id,realm-id) when receiving
>
>     an answer message of application app-id containing an Orig-Realm
> of realm-id and a
>
>     realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>  
>
>     Reacting nodes delete an OCS when it expires (i.e. when current time
>
>     minus reception time is greater than validity duration).
>
>  
>
>     Reacting nodes update the host-type OCS identified by OCS-Id =
> (app-id,host-id) when
>
>     receiving an answer message of application app-id containing an
> Orig-Host of
>
>     host-id and a host-type OC-OLR AVP with a sequence number higher
> than the
>
>     stored sequence number.
>
>  
>
>     Reacting nodes update the realm-type OCS identified by OCS-Id =
> (app-id,realm-id) when
>
>     receiving an answer message of application app-id containing an
> Orig-Realm of
>
>     realm-id and a realm-type OC-OLR AVP with a sequence number higher
> than the
>
>     stored sequence number.
>
>  
>
>     Reacting nodes do not delete an OCS when receiving an answer
> message that does not
>
>     contain an OC-OLR AVP (i.e. absence of OLR means "no change").
>
SRD> Agreed
>
>  
>
>     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg)
> when receiving a
>
>     request of application app-id containing an OC-Supported-Features AVP
>
>     indicating support of the Abatement Algorithm Alg (which the reporting
>
>     node selects) while being overloaded, unless such OCS already exists.
>
>  
>
>     Reporting nodes delete an OCS when it expires.
>
>  
>
>     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg)
> when they detect the
>
>     need to modify the requested amount of application app-id traffic
> reduction.
>
>  
>
>  
>
>  
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Monday, March 24, 2014 10:06 PM
> *To:* dime@ietf.org
> *Subject:* Re: [Dime] Issue#31 status
>
>  
>
> All,
>
> Can someone boil down the various proposed wording for this issue into
> what we want to have in the -02 draft.
>
> Thanks,
>
> Steve
>
> On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     #31: Sending OC-Ongoing-Throttling-Info AVP in request messages
>     that survived a throttling
>
>      
>
>     Dear all,
>
>      
>
>     I did not receive much support for the proposal to define an
>     OC-Ongoing-Throttling-Info AVP in request messages that survived a
>     throttlting.
>
>      
>
>     However, we seem to agree on some principles:
>
>      
>
>     Missing OLR in answer means "no change"; it does not mean "no
>     overload/no throttling requested"
>
>      
>
>     Reporting nodes SHOULD include OLR in every answer that it sends
>     in response to a request message which indicated OLR_DEFAULT_ALGO
>     support unless the reporting node has very good reasons not to do
>     so. Exact wording is not yet agreed.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>      
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     DiME@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>  
>


--------------070903090900050406010105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Please see inline.

      

      Steve

      

    
    
On 3/25/14 5:21 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
 

        
I think we can easily extend the proposed text
            for #56 to cover these points:

        
 

        
 

        
    5.5.1.  Overload
            Control State (OCS)

        
 

        
    5.5.1.1  
            Overload Control States for reacting nodes

        
 

        
    A reacting node
            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 towards

        
      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 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

        
    following
            information:

        
    - Sequence number
            (as reveived in OC-OLR)

        
    - Time of expiry 
            (deviated from validity duration as received in OC-OLR

        
      and time of
            reception)

        
    - Selected
            Abatement Algorithm (as received in OC-Supported-Features)

        
    - Algorithm
            specific input data (as received within OC-OLR, e.g.

        
      Reduction
            Percentage for Loss)

        
 

        
   

        
    5.5.1.2  
            Overload Control States for reporting nodes

        
 

        
    A reporting node
            maintains per supported Diameter application and per

        
    supported (and
            eventually selected) Abatement Algorithm an Overload

        
    Control
          State. 

        
 

        
    An Overload
            Control State may be identified by the pair of
            Application-Id

        
    and supported
            Abatement Algorithm.

        
 

        
    The Overload
            Control State for a given pair of Application and Abatement

        
    Algorithm could
            include the information:

        
    - Sequence number

        
    - Validity
            Duration and Expiry Time

        
    - Algorithm
            specific input data (e.g. Reduction Percentage for Loss)

        
    Overload Control States for reporting
              nodes containing a validity duration of 0 sec. should

        
  
             not expire before any previously sent (stale) OLR has timed
            out at any reacting node.

      

    

    SRD> I would actually model this differently.  I would have the
    following overload state in the reporting node:

    

    - Overload condition status - active or clear (clear meaning that a
    previous overload condition has ended)

    - Sequence number

    - Validity duration to be sent in reports

    - Expiration times (time that the state can be removed after the
    overload condition clears)

    - Application specific data

    

    Then the logic is to send an OLR anytime there is an active overload
    condition.  If the status is active then the validity duration is
    set to the value in the state object.  If the status is clear then
    the validity duration sent is zero.

    

    That said, I'm ok with using your wording in the -02 draft and we
    can change it in -03 if needed.

    

      

        

        
    

        
    5.5.1.3 
            Maintaining Overload Control States

        
 

        
    Reacting nodes
            create a host-type OCS identified by OCS-Id =
            (app-id,host-id) when receiving

        
    an answer message
            of application app-id containing an Orig-Host of host-id and
            a

        
    host-type OC-OLR
            AVP unless such host-type OCS already exists.

        
 

        
    Reacting nodes
            create a realm-type OCS identified by OCS-Id =
            (app-id,realm-id) when receiving

        
    an answer message
            of application app-id containing an Orig-Realm of realm-id
            and a

        
    realm-type OC-OLR
            AVP unless such realm type OCS already exists.

        
 

        
    Reacting nodes
            delete an OCS when it expires (i.e. when current time

        
    minus reception
            time is greater than validity duration).

        
 

        
    Reacting nodes
            update the host-type OCS identified by OCS-Id =
            (app-id,host-id) when

        
    receiving an
            answer message of application app-id containing an Orig-Host
            of

        
    host-id and a
            host-type OC-OLR AVP with a sequence number higher than the

        
    stored sequence
            number.

        
 

        
    Reacting nodes
            update the realm-type OCS identified by OCS-Id =
            (app-id,realm-id) when

        
    receiving an
            answer message of application app-id containing an
            Orig-Realm of

        
    realm-id and a
            realm-type OC-OLR AVP with a sequence number higher than the

        
    stored sequence
            number.

        
 

        
    Reacting nodes do not delete an OCS when
              receiving an answer message that does not

        
  
             contain an OC-OLR AVP (i.e. absence of OLR means “no
            change”).

      

    

    SRD> Agreed

    

      

        

        
 

        
    Reporting nodes
            create an OCS identified by OCS-Id = (app-id,Alg) when
            receiving a

        
    request of
            application app-id containing an OC-Supported-Features AVP

        
    indicating
            support of the Abatement Algorithm Alg (which the reporting

        
    node selects)
            while being overloaded, unless such OCS already exists.

        
 

        
    Reporting nodes
            delete an OCS when it expires.

        
 

        
    Reporting nodes
            update the OCS identified by OCS-Id = (app-id,Alg) when they
            detect the

        
    need to modify
            the requested amount of application app-id traffic
            reduction.

        
 

        
 

        
 

        

          

            
From: DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of ext Steve Donovan

                Sent: Monday, March 24, 2014 10:06 PM

                To: dime@ietf.org

                Subject: Re: [Dime] Issue#31 status

          

        

        
 

        
All,

          

          Can someone boil down the various proposed wording for this
          issue into what we want to have in the -02 draft.

          

          Thanks,

          

          Steve

        

          
On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          

            
#31:
                Sending OC-Ongoing-Throttling-Info AVP in request
                messages that survived a throttling

          

          

            
 

          

          

            
Dear
                all,

          

          

            
 

          

          

            
I
                did not receive much support for the proposal to define
                an OC-Ongoing-Throttling-Info AVP in request messages
                that survived a throttlting.

          

          

            
 

          

          

            
However,
                we seem to agree on some principles:

          

          

            
 

          

          

            
Missing
                OLR in answer means “no change”; it does not mean “no
                overload/no throttling requested”

          

          

            
 

          

          

            
Reporting
                nodes SHOULD include OLR in every answer that it sends
                in response to a request message which indicated
              OLR_DEFAULT_ALGO 
              support
                unless the reporting node has very good reasons not to
                do so. Exact wording is not yet agreed.
                

          

          

            
 

          

          

            
Ulrich

          

          

            
 

          

          

            
 

          

          

            
 

          

          


            

            

            

          
_______________________________________________

          
DiME mailing list

          
DiME@ietf.org

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

        

        
 

      

    

    

  


--------------070903090900050406010105--


From nobody Tue Mar 25 14:59:22 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 9FC741A0236 for ; Tue, 25 Mar 2014 14:59:19 -0700 (PDT)
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 zmcFdXThUW8D for ; Tue, 25 Mar 2014 14:59:15 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E92A1A0230 for ; Tue, 25 Mar 2014 14:59:15 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:60523 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSZNF-00060K-Q6; Tue, 25 Mar 2014 14:59:12 -0700
Message-ID: <5331FC2E.9090307@usdonovans.com>
Date: Tue, 25 Mar 2014 16:59:10 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net>
Content-Type: multipart/alternative; boundary="------------010806070506090109010704"
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/S9HVyTWHF6_Y0j742olX9exilG0
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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, 25 Mar 2014 21:59:19 -0000

This is a multi-part message in MIME format.
--------------010806070506090109010704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ulrich,

Please see inline.

Steve

On 3/25/14 10:14 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
> Thank you for this summary.
>
> Please see inline.
>
>  
>
> Ulrich
>
>  
>
> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Tuesday, March 25, 2014 2:49 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
> *Subject:* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Ulrich,
>
> I mean going backwards from where I thought we were after the London
> meeting.
>
> We are clearly out of sync but hopefully we can fix that.
>
> Here's my understanding of the status of #23 and #55.
>
> Prior to London meeting:
>
> #23 status:
>  - Agreement to change the name of existing realm reports to
> realm-routed-reports (RRR).
>
> this includes agreement to keep the (newly called)
> realm-routed-reports
>
SRD> At the time, yes.  This changed in the London meeting and appears
to be changing back now.
>
>  - Discussions were ongoing as to the need for both realm reports and
> RRR reports.
>
> I would say "...as to the need for realm reports in addition
> to realm-routed-reports" 
>
SRD> Ok, I would say it as I typed it.
>
>
>
> #55 status:
>   - Agreement on adding Realm reports based on the definition that
> realm reports apply to all traffic sent to the realm.
>
> This is what I'm missing. The issue has been very briefly
> discussed under #34 without conclusion. There was no discussion under
> #55
>
SRD> There was quite a bit of discussion as part of multiple issues.  I
agree there was no discussion tagged with issue #55, but many of these
issues overlap. 
>
> *//*
>
>
>   - Limited discussion on the interaction between the new realm
> reports and the existing host and RRR reports.
>
> After London meeting:
>
> #23 status:
>   - Tentative agreement in London meeting to remove RRR reports.
>
> What was the technical argument?
>
SRD> My concern with RRR reports is that they don't provide a consistent
and predictable mechanism for controlling traffic sent to the realm.  If
we support Realm reports that control all traffic sent to the Realm,
then I see limited value in also supporting RRR reports. 
>
>
>   - Ben expressed the strongest concern with this plan.  Steve and Ben
> took action to discuss and come back with a recommendation. 
>
> #55 status:
>   - No change
>
> Summary:
>   - Tentative consensus reached to move forward with two report types
> - host and realm, with realm having the new definition.
> What was the technical argument?
>
SRD>  There is also a requirement in RFC 7068 to be able to control the
amount of traffic sent to the realm.  The primary use case for Realm
reports is inter domain cases where one domain wants to throttle traffic
coming from another domain without exposing the identity of servers in
the domain.
>
>
> Current status:
>
> #23 status:
>  - Change the name to RRR
>  - Whether or not to remove RRR and revisit later or keep RRR and
> revisit later is an open issue.
>
> #55 status:
>   - My opinion is that we have at least rough consensus on the need to
> support realm reports.  Others might have a different opinion.
>
>  There was no comment posted to issue #55, also no proposed
> solution, so I cannot see where the consensus came from
>
SRD> This was discussed, just not in a thread tagged #55.  There was
also significant discussion in the thread on issues #23, #34 adn #57.
>
>
>
> Summary:
>   - I believe we have three options:
>
>    1) Support host and RRR reports
>    2) Support host and Realm reports -- This was the tentative plan
> coming out of the London meeting
>
> < Ulrich> There is not even an issue number identifying problems with
> RRR and proposing to remove RRR
>
SRD> That doesn't mean there aren't issues. :-)
>
>
>    3) Support host, RRR and Realm reports
>
>  I support option 1
>
SRD> Option 1 is the only option I don't support. 
>
>
> Regards,
>
> Steve
>
> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>     Steve,
>
>     I don't think we are going backwards (we may be out of synch though)
>
>      
>
>     Can you please summarize the status of #23 and #55.
>
>      
>
>     Ulrich
>
>      
>
>      
>
>     *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Monday, March 24, 2014 7:38 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>     
>     *Subject:* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Ok, we are going backwards on this one.
>
>     I did not include option three because we had moved past that
>     option in our discussions, both on the list (I thought), and in
>     the meeting.
>
>     I believe that we had come to rough consensus on the need for a
>     realm report and the only remaining issue was whether we also
>     included the RRR report type.
>
>     At this point, the only option is to leave all of the issues
>     related to the report types open and attempt to resolve them in
>     the -03 draft.
>
>     Steve
>
>     On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Steve,
>
>          
>
>         I do not agree.
>
>          
>
>         We should still have the option
>
>         3) support report type 0 (this is called host report) and
>         support of report type 1 (this has been called relam report
>         but people argued it should better be called realm routed
>         request report).
>
>          
>
>         Whether or not we need in addition to type 0 and type 1 (or as
>         a replacement of type 1) a
>         realm-no-matter-whether-destination-host-is present-or-not
>         report   is an open issue (see #55).
>
>         There are a lot of open questions  with regard to #55 and I
>         have not seen a conclusion.
>
>         Where I have seen a conclusion is issue #34 and that is inline
>         with option 3).
>
>          
>
>         Unless we conclude on #55, or decide to re-open #34, option 3)
>         is what should go in the -02 draft.
>
>          
>
>          
>
>         Ulrich
>
>          
>
>         *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>         Steve Donovan
>         *Sent:* Monday, March 24, 2014 2:57 PM
>         *To:* dime@ietf.org 
>         *Subject:* Re: [Dime] Resolution on action to discuss the need
>         for Realm-Routed-Reports
>
>          
>
>         Ulrich,
>         All,
>
>         We have two options for the -02 draft.
>
>         1) Support Host and Realm as proposed below, removing RRR reports.
>         2) Support Host, Realm and RRR reports.
>
>         The default plan is to go with option 1 in the -02 draft, as
>         that was the proposal that came out of the meeting in London. 
>         RRR reports can be added back in if and when we are convinced
>         of the need. 
>
>         If there are strong objections to this then I will update the
>         -02 draft to reflect all three report types.
>
>         I plan to make these updates Wednesday morning, Dallas, Texas
>         time.
>
>         Either way I do not expect we will have agreed to wording on
>         the interaction between the report types when a reacting node
>         has multiple report types, all of which apply to individual
>         requests.  This will need to be addressed in the -03 draft.
>
>         Regards,
>
>         Steve
>
>         On 3/21/14 4:05 PM, Steve Donovan wrote:
>
>             Ulrich,
>
>             The discussion should be captured in the minutes to the
>             meeting.  I wasn't able to find them posted yet.
>
>             Jouni, Lionel, what is the status of the minutes for the
>             meeting?
>
>             My reading of emails prior to the London meeting is
>             different from yours.  I believe we had come to the
>             conclusion that we needed host and realm (with the
>             definition of realm as outlined below).  We were still
>             discussing the need for Realm-Routed-Request reports.
>
>             Regards,
>
>             Steve
>
>             On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>                 Steve,
>
>                  
>
>                 I don't know what happend in London.
>
>                 Can you please summarize the technical reasons that
>                 led to the London agreement.
>
>                 E-mail discussions prior to London have clearly
>                 directed towards a report type that requests
>                 throttling of realm routed request messages (i.e. not
>                 containing a destination host) rather than a report
>                 type that requests throttling of messages routed
>                 towards a realm (no matter whether they contain a
>                 destination host or not).   
>
>                  
>
>                 Ulrich
>
>                  
>
>                 *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf
>                 Of *ext Steve Donovan
>                 *Sent:* Friday, March 21, 2014 3:33 PM
>                 *To:* dime@ietf.org 
>                 *Subject:* [Dime] Resolution on action to discuss the
>                 need for Realm-Routed-Reports
>
>                  
>
>                 All,
>
>                 Ben and I took the action item to discuss the need for
>                 the Realm-Routed-Reports (RRR) report type.
>
>                 As you may recall, the consensus coming out of the
>                 DIME WG meeting in London was to support two report types:
>
>                 - Host -- Impacting requests with a Destination-Host
>                 AVP matching the host in the overload report (with the
>                 host implicitly determined from the Origin-Host AVP of
>                 the answer message carrying the overload report).
>
>                 - Realm -- Impacting 100% of the requests with a
>                 Destination-Realm AVP matching the realm in the
>                 overload report (with the realm implicitly determine
>                 from the Origin-Realm of the answer message carrying
>                 the overload report).
>
>                 The action Ben and I took was to come back with an
>                 opinion on whether RRR reports should also be supported.
>
>                 My summary of the discussion is that we recommend to
>                 NOT include RRR reports in the current version of the
>                 base DOIC draft. 
>
>                 We still have some concerns with the granularity of
>                 control enabled by having just the two report types
>                 but the analysis of whether RRR reports are still
>                 needed can occur independent of the base DOIC draft. 
>                 If there is a determination that RRRs are needed in
>                 time to include in the base draft then it can be
>                 considered at that time.
>
>                 Based on this, I propose the following
>
>                 - Resolution to issue #23 is to remove RRR reports
>                 from the document.
>                 - Resolution to issue #55 is to add Realm reports
>                 (actually to redefine them per the above definition).
>                 - Resolution to issue #57 is that it no longer applies
>                 (as it deals with RRRs).
>
>                 There is also need for text describing the interaction
>                 between host and the realm reports.  I don't expect we
>                 will have consensus on this wording prior to the -02
>                 draft being submitted.  To this end, I'll open a new
>                 issue to deal with the need for wording on the
>                 interaction.
>
>                 Regards,
>
>                 Steve
>
>
>
>
>
>
>
>             _______________________________________________
>
>             DiME mailing list
>
>             DiME@ietf.org 
>
>             https://www.ietf.org/mailman/listinfo/dime
>
>          
>
>      
>
>  
>


--------------010806070506090109010704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Ulrich,

      

      Please see inline.

      

      Steve

      

    
    
On 3/25/14 10:14 AM, Wiehe, Ulrich (NSN
      - DE/Munich) wrote:

    

    

      
      
      
      

        
Steve,

        
Thank you for this summary.

        
Please see inline.

        
 

        
Ulrich

        
 

        

          

            
From: ext Steve Donovan
                [mailto:srdonovan@usdonovans.com]
                

                Sent: Tuesday, March 25, 2014 2:49 PM

                To: Wiehe, Ulrich (NSN - DE/Munich);
                dime@ietf.org

                Subject: Re: [Dime] Resolution on action to
                discuss the need for Realm-Routed-Reports

          

        

        
 

        
Ulrich,

          

          I mean going backwards from where I thought we were after the
          London meeting.

          

          We are clearly out of sync but hopefully we can fix that.

          

          Here's my understanding of the status of #23 and #55.

          

          Prior to London meeting:

            

            #23 status:

             - Agreement to change the name of existing realm reports to
            realm-routed-reports (RRR).

        
<Ulrich>this includes agreement to keep
            the (newly called) realm-routed-reports</Ulrich>

          

      

    

    SRD> At the time, yes.  This changed in the London meeting and
    appears to be changing back now.

    

      

        

             - Discussions were ongoing as to the need for both realm
            reports and RRR reports.

        
<Ulrich>I would say “…as to the need for
            realm reports in addition to realm-routed-reports”
            </Ulrich>

      

    

    SRD> Ok, I would say it as I typed it.

    

      

        

        


            

            #55 status:

              - Agreement on adding Realm reports based on the
            definition that realm reports apply to all traffic sent to
            the realm.

        
<Ulrich>This is what I’m missing. The
            issue has been very briefly discussed under #34 without
            conclusion. There was no discussion under #55</Ulrich>

      

    

    SRD> There was quite a bit of discussion as part of multiple
    issues.  I agree there was no discussion tagged with issue #55, but
    many of these issues overlap.  

    

      

        

        


              - Limited discussion on the interaction between the new
            realm reports and the existing host and RRR reports.

            

          After London meeting:

          

          #23 status:

            - Tentative agreement in London meeting to remove RRR
          reports.

        
<Ulrich>What was the technical
            argument?</Ulrich>

      

    

    SRD> My concern with RRR reports is that they don't provide a
    consistent and predictable mechanism for controlling traffic sent to
    the realm.  If we support Realm reports that control all traffic
    sent to the Realm, then I see limited value in also supporting RRR
    reports.  

    

      

        

        


              - Ben expressed the strongest concern with this plan.  Steve
          and Ben took action to discuss and come back with a
          recommendation. 
          

          

          #55 status:

            - No change

          

          Summary:

            - Tentative consensus reached to move forward with two
          report types - host and realm, with realm having the new
          definition.

          <Ulrich>What was the technical
            argument?</Ulrich>

      

    

    SRD>  There is also a requirement in RFC 7068 to be able to
    control the amount of traffic sent to the realm.  The primary use
    case for Realm reports is inter domain cases where one domain wants
    to throttle traffic coming from another domain without exposing the
    identity of servers in the domain.

    

      

        

        


          Current status:

          

          #23 status:

           - Change the name to RRR

           - Whether or not to remove RRR and revisit later or keep RRR
          and revisit later is an open issue.

          

          #55 status:

            - My opinion is that we have at least rough consensus on the
          need to support realm reports.  Others might have a different
          opinion.

        
<Ulrich> There was no comment posted to
            issue #55, also no proposed solution, so I cannot see where
            the consensus came from</Ulrich>

      

    

    SRD> This was discussed, just not in a thread tagged #55.  There
    was also significant discussion in the thread on issues #23, #34 adn
    #57. 

    

      

        

        


            

            Summary:

              - I believe we have three options:

            

               1) Support host and RRR reports

               2) Support host and Realm reports -- This was the
            tentative plan coming out of the London meeting

        
< Ulrich> There is not even an issue
            number identifying problems with RRR and proposing to remove
            RRR</Ulrich>

      

    

    SRD> That doesn't mean there aren't issues. :-)

    

      

        

        


               3) Support host, RRR and Realm reports

            

          

        
<Ulrich> I support option
            1</Ulrich>

      

    

    SRD> Option 1 is the only option I don't support.  

    

      

        

        


            Regards,

            

            Steve

            

          

        

          
On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN -
            DE/Munich) wrote:

        

        

          
Steve,

          
I don’t think we are going backwards (we may
              be out of synch though)

          
 

          
Can you please summarize the status of #23
              and #55.

          
 

          
Ulrich

          
 

          
 

          

            

              
From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                  

                  Sent: Monday, March 24, 2014 7:38 PM

                  To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

                  Subject: Re: [Dime] Resolution on action to
                  discuss the need for Realm-Routed-Reports

            

          

          
 

          
Ok, we are
            going backwards on this one.

            

            I did not include option three because we had moved past
            that option in our discussions, both on the list (I
            thought), and in the meeting.
            

            

            I believe that we had come to rough consensus on the need
            for a realm report and the only remaining issue was whether
            we also included the RRR report type.

            

            At this point, the only option is to leave all of the issues
            related to the report types open and attempt to resolve them
            in the -03 draft.

            

            Steve

          

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

          

          

            
Steve,

            
 

            
I
                do not agree.

            
 

            
We should still have the option
              

            
3) support report type 0 (this is called
                host report) and support of report type 1 (this has been
                called relam report but people argued it should better
                be called realm routed request report).

            
 

            
Whether or not we need in addition to type
                0 and type 1 (or as a replacement of type 1) a
                realm-no-matter-whether-destination-host-is
                present-or-not report   is an open issue (see #55).

            
There are a lot of open questions  with
                regard to #55 and I have not seen a conclusion.

            
Where I have seen a conclusion is issue #34
                and that is inline with option 3).

            
 

            
Unless we conclude on #55, or decide to
                re-open #34, option 3) is what should go in the -02
                draft.

            
 

            
 

            
Ulrich

            
 

            

              

                
From: DiME [mailto:dime-bounces@ietf.org]
                    On Behalf Of ext Steve Donovan

                    Sent: Monday, March 24, 2014 2:57 PM

                    To: dime@ietf.org

                    Subject: Re: [Dime] Resolution on action to
                    discuss the need for Realm-Routed-Reports

              

            

            
 

            
Ulrich,

              All,

              

              We have two options for the -02 draft.

              

              1) Support Host and Realm as proposed below, removing RRR
              reports.

              2) Support Host, Realm and RRR reports.

              

              The default plan is to go with option 1 in the -02 draft,
              as that was the proposal that came out of the meeting in
              London.  RRR reports can be added back in if and when we
              are convinced of the need. 
              

              

              If there are strong objections to this then I will update
              the -02 draft to reflect all three report types.

              

              I plan to make these updates Wednesday morning, Dallas,
              Texas time.

              

              Either way I do not expect we will have agreed to wording
              on the interaction between the report types when a
              reacting node has multiple report types, all of which
              apply to individual requests.  This will need to be
              addressed in the -03 draft.

              

              Regards,

              

              Steve

            

              
On 3/21/14 4:05 PM, Steve Donovan
                wrote:

            

            

              
Ulrich,

                

                The discussion should be captured in the minutes to the
                meeting.  I wasn't able to find them posted yet.

                

                Jouni, Lionel, what is the status of the minutes for the
                meeting?

                

                My reading of emails prior to the London meeting is
                different from yours.  I believe we had come to the
                conclusion that we needed host and realm (with the
                definition of realm as outlined below).  We were still
                discussing the need for Realm-Routed-Request reports.

                

                Regards,

                

                Steve

              

                
On 3/21/14 10:09 AM, Wiehe, Ulrich
                  (NSN - DE/Munich) wrote:

              

              

                
Steve,

                
 

                
I don’t know what happend in London.

                
Can you please summarize the technical
                    reasons that led to the London agreement.
                  

                
E-mail discussions prior to London have
                    clearly directed towards a report type that requests
                    throttling of realm routed request messages (i.e.
                    not containing a destination host) rather than a
                    report type that requests throttling of messages
                    routed towards a realm (no matter whether they
                    contain a destination host or not).   

                
 

                
Ulrich

                
 

                

                  

                    
From: DiME [mailto:dime-bounces@ietf.org]
                        On Behalf Of ext Steve Donovan

                        Sent: Friday, March 21, 2014 3:33 PM

                        To: dime@ietf.org

                        Subject: [Dime] Resolution on action to
                        discuss the need for Realm-Routed-Reports

                  

                

                
 

                
All,

                  

                  Ben and I took the action item to discuss the need for
                  the Realm-Routed-Reports (RRR) report type.

                  

                  As you may recall, the consensus coming out of the
                  DIME WG meeting in London was to support two report
                  types:

                  

                  - Host -- Impacting requests with a Destination-Host
                  AVP matching the host in the overload report (with the
                  host implicitly determined from the Origin-Host AVP of
                  the answer message carrying the overload report).

                  

                  - Realm -- Impacting 100% of the requests with a
                  Destination-Realm AVP matching the realm in the
                  overload report (with the realm implicitly determine
                  from the Origin-Realm of the answer message carrying
                  the overload report).

                  

                  The action Ben and I took was to come back with an
                  opinion on whether RRR reports should also be
                  supported.

                  

                  My summary of the discussion is that we recommend to
                  NOT include RRR reports in the current version of the
                  base DOIC draft. 
                  

                  

                  We still have some concerns with the granularity of
                  control enabled by having just the two report types
                  but the analysis of whether RRR reports are still
                  needed can occur independent of the base DOIC draft. 
                  If there is a determination that RRRs are needed in
                  time to include in the base draft then it can be
                  considered at that time.

                  

                  Based on this, I propose the following 

                  

                  - Resolution to issue #23 is to remove RRR reports
                  from the document.

                  - Resolution to issue #55 is to add Realm reports
                  (actually to redefine them per the above definition).

                  - Resolution to issue #57 is that it no longer applies
                  (as it deals with RRRs).

                  

                  There is also need for text describing the interaction
                  between host and the realm reports.  I don't expect we
                  will have consensus on this wording prior to the -02
                  draft being submitted.  To this end, I'll open a new
                  issue to deal with the need for wording on the
                  interaction.

                  

                  Regards,

                  

                  Steve 

              

              


                

                

                

                

                

                

              
_______________________________________________

              
DiME mailing list

              
DiME@ietf.org

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

            

            
 

          

          
 

        

        
 

      

    

    

  


--------------010806070506090109010704--


From nobody Tue Mar 25 16:08:49 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 4FB461A026E for ; Tue, 25 Mar 2014 16:08:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Rhv9wNfkBk90 for ; Tue, 25 Mar 2014 16:08:42 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6673C1A0256 for ; Tue, 25 Mar 2014 16:08:42 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2PN8a5C092501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Mar 2014 18:08:37 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
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: <087A34937E64E74E848732CFF8354B92097731E9@ESESSMB101.ericsson.se>
Date: Tue, 25 Mar 2014 18:08:36 -0500
X-Mao-Original-Outgoing-Id: 417481716.041246-b0900e7ca4be2014115cb2f007a67ae7
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.97c5ce599fb219f1e97cb7300a394f91@trac.tools.ietf.org> <52F9070A.8080608@usdonovans.com> <6150_1392053497_52F90CF9_6150_15734_1_6B7134B31289DC4FAF731D844122B36E497E5B@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B92097731E9@ESESSMB101.ericsson.se>
To: Maria Cruz Bartolome 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9eVXOL8q010WxiCbftpfDJMgAiw
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #43: Overstated guidance on	session-ending	requests.
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, 25 Mar 2014 23:08:45 -0000

Sorry for dropping this one.=20

I don't agree.

To recap:

The opening of 3.1.4 says :

>    The request classes identified in Section 3.1.3
>  have implications on
>    decisions about which requests should be throttled first.  The
>    following list of request treatment regarding throttling is =
provided
>    as guidelines for application designers when implementing the
>    Diameter overload control mechanism described in this document.
>    Exact behavior regarding throttling must be defined per =
application.
>=20
>=20

The paragraph to which I objected said:

> Session terminating requests should be throttled less aggressively in
>       order to gracefully terminate sessions, allow clean-up of the
>       related resources (e.g. session state) and get rid of the need =
for
>       other intra-session requests, reducing the session management
>       impact on the overloaded entity.  The default handling of other
>       intra-session requests might be to treat them equally when =
making
>       throttling decisions.  There might also be application level
>       considerations whether some request types are favored over =
others.



When taken together, that says to me that we offer non-normative =
guidance that applications should throttle session terminating requests =
less aggressively, but that applications would define the exact =
behavior. I see nothing about local policy here.

The change that would make me happy would be to adjust the end =
disclaimer to say " The exact behavior ... is a matter of local policy, =
unless specifically defined for the application."

... and to change the first sentence of the second quote to say "As an =
example, session terminating requests might be throttled less =
aggressively..."




On Feb 11, 2014, at 3:21 PM, Maria Cruz Bartolome =
 wrote:

> Agreed
> =20
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of =
lionel.morand@orange.com
> Sent: lunes, 10 de febrero de 2014 18:32
> To: Steve Donovan; dime@ietf.org; =
draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
> Subject: Re: [Dime] [dime] #43: Overstated guidance on session-ending =
requests.
> =20
> Hi Steve, Ben,
> =20
> I agree with Steve that we have the text in introduction is clear =
enough to avoid ambiguity.
> =20
> Regards,
> =20
> Lionel
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : lundi 10 f=E9vrier 2014 18:06
> =C0 : dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; =
ben@nostrum.com
> Objet : Re: [Dime] [dime] #43: Overstated guidance on session-ending =
requests.
> =20
> Section 3.1.4 is not normative and says:
> The following list of request treatment regarding throttling is =
provided
> as guidelines for application designers when implementing the
> Diameter overload control mechanism described in this document.
> Exact behavior regarding throttling must be defined per application.
> Do you think we need further clarification that application designers =
should reflect that local policy applies?
>=20
> Steve
>=20
> On 2/7/14 3:34 PM, dime issue tracker wrote:
> #43: Overstated guidance on session-ending requests.
> =20
>  In section 3.1.4, under "Intra-Session Requests" indicates that =
session
>  ending requests should be throttled less aggressively. While I agree
>  that's a good idea in general, I think that's a mater of local =
policy, and
>  not up to DOIC to specify.
> =20
>  It would be better to indicate that prioritization under overload is =
up to
>  local policy, and list prioritizing of session-ending requests as an
>  example of a potential local policy.
> =20
> =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.
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Mar 25 16:16: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 41D5E1A01C6 for ; Tue, 25 Mar 2014 16:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Xx3Jcxc9dcgo for ; Tue, 25 Mar 2014 16:16:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E1C1A0248 for ; Tue, 25 Mar 2014 16:16:52 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2PNGnrL093175 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Mar 2014 18:16:50 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
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: <533097D1.3090803@usdonovans.com>
Date: Tue, 25 Mar 2014 18:16:49 -0500
X-Mao-Original-Outgoing-Id: 417482209.103132-a592080972284749d783a3bed4dec29a
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/fLE6x5xu570doOTbMpLJ2LqNwq0
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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, 25 Mar 2014 23:16:56 -0000

I do not agree. While this fixes a related problem of using a zero =
validity-duration to signal the end of an overload condition, it still =
implies that one SHOULD NOT let a report "just expire". As I've argued =
before, I believe there are time when it is just as good, if not better, =
to let an overload condition expire naturally.

Here's a quote of my argument to that effect from further down the =
thread:

> I think it's reasonable to say that a reporting node should terminate =
an overload condition in a timely manner. But if it's about to expire =
anyway, then expiration might be just as timely as an explicit report.=20=

>=20
> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.

So, here's a different proposal for your first paragraph:

   "When a reporting node has recovered from overload, it SHOULD =
invalidate any existing overload reports in a timely matter. This can be =
achieved by sending an updated overload report (meaning the OLR contains =
a new sequence number) with the OC-Validity-Duration AVP value set to =
zero ("0"). If the overload report is about to expire naturally, the =
reporting node MAY choose to simply let it do so."


On Mar 24, 2014, at 3:38 PM, Steve Donovan  =
wrote:

> Here's some proposed wording that will hopefully let us close this =
issue:
>=20
> Regards,
>=20
> Steve
>=20
> -----
>=20
> Section 4.5., paragraph 3 -=20
>=20
> Current -02 wording:
>=20
> As a general guidance for implementations it is RECOMMENDED never to
>    let any overload report to timeout.  Following to this rule, an
>    overload endpoint should explicitly signal the end of overload
>    condition and not rely on the expiration of the validity time of =
the
>    overload report in the reacting node.  This is achieved by sending =
an
>    updated overload report (meaning it must contain a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
> Proposed wording:
>=20
>    A reporting node SHOULD explicitly signal the end of overload
>    condition in a timely manner.  This is achieved by sending an
>    updated overload report (meaning the OLR contains a new sequence
>    number) with the OC-Validity-Duration AVP value set to zero ("0").
>=20
>   A reacting node MUST invalidate and remove an overload report that
>   expires without an explicit overload report containing an =
OC-Validity-Duration
>   value set to zero ("0").
>=20
>=20
> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>> Fine with me.
>>=20
>> - Jouni
>>=20
>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome=20
>> 
>>  wrote:
>>=20
>>=20
>>> Ben, Nirav,
>>>=20
>>> I follow same argumentation.
>>> Regards
>>> /MCruz
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Nirav Salot (nsalot)
>>> Sent: martes, 11 de febrero de 2014 11:23
>>> To: Ben Campbell; Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting =
overload reports expire
>>>=20
>>> Ben,
>>>=20
>>> I resonate with your thinking below.
>>>=20
>>> Regards,
>>> Nirav.
>>>=20
>>> -----Original Message-----
>>> From: DiME [
>>> mailto:dime-bounces@ietf.org
>>> ] On Behalf Of Ben Campbell
>>> Sent: Monday, February 10, 2014 9:54 PM
>>> To: Jouni Korhonen
>>> Cc:=20
>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>=20
>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting =
overload reports expire
>>>=20
>>>=20
>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen=20
>>> 
>>>  wrote:
>>>=20
>>>=20
>>>> My reasoning for explicit termination was that knowing the=20
>>>> implementation folks they will let overload conditions expire =
unless advised otherwise.
>>>> And having unnecessary stuff hanging around waiting for a cleanup =
is=20
>>>> not a good thing in general. But I am open here for other options..
>>>>=20
>>>>=20
>>> I think it's reasonable to say that a reporting node should =
terminate an overload condition in a timely manner. But if it's about to =
expire anyway, then expiration might be just as timely as an explicit =
report.=20
>>>=20
>>> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>>=20
>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>> _______________________________________________
>> DiME mailing list
>>=20
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Tue Mar 25 16:52: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 1EE7B1A0259 for ; Tue, 25 Mar 2014 16:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] 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 Y5Q1n91QmxxA for ; Tue, 25 Mar 2014 16:51:59 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6561A021E for ; Tue, 25 Mar 2014 16:51:58 -0700 (PDT)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id c9612335.0.1920279.00-2365.5377232.nbfkord-smmo06.seg.att.com (envelope-from );  Tue, 25 Mar 2014 23:51:57 +0000 (UTC)
X-MXL-Hash: 5332169d2cba091d-f21debf50cafd76fe5b0f94230d994faf0c12dd7
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s2PNpu8A013896; Tue, 25 Mar 2014 19:51:56 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s2PNpnTa013848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Mar 2014 19:51:52 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 25 Mar 2014 23:51:41 GMT
Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0174.001; Tue, 25 Mar 2014 19:51:41 -0400
From: "DOLLY, MARTIN C" 
To: Ben Campbell 
Thread-Topic: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
Thread-Index: AQHPSIBMt0fDkcbCrUWGV1ADOW2pqZryeVVY
Date: Tue, 25 Mar 2014 23:51:41 +0000
Message-ID: <4CAA0308-08B6-4F7D-9A51-7A4AAA833404@att.com>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=eY6Kic4H c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=LrBFAd3DcSIA:10 a=ofMgfj31e3cA:10 a=BLceEmwcHowA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=Z80JlwQ0AAAA:8 a=yakATiurA]
X-AnalysisOut: [AAA:8 a=0FD05c-RAAAA:8 a=48vgC7mUAAAA:8 a=pGLkceISAAAA:8 a]
X-AnalysisOut: [=iWO5QD6-H_qhiD_E6h0A:9 a=CjuIK1q_8ugA:10 a=qM39cor4HRgA:1]
X-AnalysisOut: [0 a=Hz7IrDYlS0cA:10 a=0MAqpqVwYqEA:10 a=BMZHtSBzE-QA:10 a=]
X-AnalysisOut: [f7GxY0FH8QIA:10 a=lZB815dzVvQA:10 a=MSl-tDqOz04A:10 a=tqwV]
X-AnalysisOut: [kdtsOKSkepFu:21 a=fabrLpjNNEN_gIKe:21]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: 
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XXbCh0CPQmOgDX05QhnvZW5h6TU
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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, 25 Mar 2014 23:52:02 -0000

Why, sorry but please repeat or I go with I believe consensus

Thanks

Martin Dolly
Lead Member of Technical Staff
Core Network & Gov't/Regulatory Standards =20
AT&T Standards and Industry Alliances
+1-609-903-3360
md3135@att.com

> On Mar 25, 2014, at 7:17 PM, "Ben Campbell"  wrote:
>=20
> I do not agree. While this fixes a related problem of using a zero validi=
ty-duration to signal the end of an overload condition, it still implies th=
at one SHOULD NOT let a report "just expire". As I've argued before, I beli=
eve there are time when it is just as good, if not better, to let an overlo=
ad condition expire naturally.
>=20
> Here's a quote of my argument to that effect from further down the thread=
:
>=20
>> I think it's reasonable to say that a reporting node should terminate an=
 overload condition in a timely manner. But if it's about to expire anyway,=
 then expiration might be just as timely as an explicit report.=20
>>=20
>> And of course, the definition of "timely" is somewhat a matter of policy=
. For example, I can imagine an deployment that had a large number of clien=
ts using fairly short validity durations, and _never_ explicitly signaling =
an end to an overload condition. This adds a bit of a "slow-start" to the r=
ecovery, since different clients will expire the overload condition at diff=
erent times, and the load will ramp up gradually. I don't see anything wron=
g with that. Of course, it wouldn't work if one chose long validity duratio=
ns, or if the signaling of overload to different clients happened in close =
synchronization.
>=20
> So, here's a different proposal for your first paragraph:
>=20
>   "When a reporting node has recovered from overload, it SHOULD invalidat=
e any existing overload reports in a timely matter. This can be achieved by=
 sending an updated overload report (meaning the OLR contains a new sequenc=
e number) with the OC-Validity-Duration AVP value set to zero ("0"). If the=
 overload report is about to expire naturally, the reporting node MAY choos=
e to simply let it do so."
>=20
>=20
>> On Mar 24, 2014, at 3:38 PM, Steve Donovan  wr=
ote:
>>=20
>> Here's some proposed wording that will hopefully let us close this issue=
:
>>=20
>> Regards,
>>=20
>> Steve
>>=20
>> -----
>>=20
>> Section 4.5., paragraph 3 -=20
>>=20
>> Current -02 wording:
>>=20
>> As a general guidance for implementations it is RECOMMENDED never to
>>   let any overload report to timeout.  Following to this rule, an
>>   overload endpoint should explicitly signal the end of overload
>>   condition and not rely on the expiration of the validity time of the
>>   overload report in the reacting node.  This is achieved by sending an
>>   updated overload report (meaning it must contain a new sequence
>>   number) with the OC-Validity-Duration AVP value set to zero ("0").
>>=20
>> Proposed wording:
>>=20
>>   A reporting node SHOULD explicitly signal the end of overload
>>   condition in a timely manner.  This is achieved by sending an
>>   updated overload report (meaning the OLR contains a new sequence
>>   number) with the OC-Validity-Duration AVP value set to zero ("0").
>>=20
>>  A reacting node MUST invalidate and remove an overload report that
>>  expires without an explicit overload report containing an OC-Validity-D=
uration
>>  value set to zero ("0").
>>=20
>>=20
>>> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>>> Fine with me.
>>>=20
>>> - Jouni
>>>=20
>>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome=20
>>> 
>>> wrote:
>>>=20
>>>=20
>>>> Ben, Nirav,
>>>>=20
>>>> I follow same argumentation.
>>>> Regards
>>>> /MCruz
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of Nirav Salot (nsalot)
>>>> Sent: martes, 11 de febrero de 2014 11:23
>>>> To: Ben Campbell; Jouni Korhonen
>>>> Cc:=20
>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting ov=
erload reports expire
>>>>=20
>>>> Ben,
>>>>=20
>>>> I resonate with your thinking below.
>>>>=20
>>>> Regards,
>>>> Nirav.
>>>>=20
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of Ben Campbell
>>>> Sent: Monday, February 10, 2014 9:54 PM
>>>> To: Jouni Korhonen
>>>> Cc:=20
>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>=20
>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting ov=
erload reports expire
>>>>=20
>>>>=20
>>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen=20
>>>> 
>>>> wrote:
>>>>=20
>>>>=20
>>>>> My reasoning for explicit termination was that knowing the=20
>>>>> implementation folks they will let overload conditions expire unless =
advised otherwise.
>>>>> And having unnecessary stuff hanging around waiting for a cleanup is=
=20
>>>>> not a good thing in general. But I am open here for other options..
>>>> I think it's reasonable to say that a reporting node should terminate =
an overload condition in a timely manner. But if it's about to expire anywa=
y, then expiration might be just as timely as an explicit report.=20
>>>>=20
>>>> And of course, the definition of "timely" is somewhat a matter of poli=
cy. For example, I can imagine an deployment that had a large number of cli=
ents using fairly short validity durations, and _never_ explicitly signalin=
g an end to an overload condition. This adds a bit of a "slow-start" to the=
 recovery, since different clients will expire the overload condition at di=
fferent times, and the load will ramp up gradually. I don't see anything wr=
ong with that. Of course, it wouldn't work if one chose long validity durat=
ions, or if the signaling of overload to different clients happened in clos=
e synchronization.
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>> _______________________________________________
>>> DiME mailing list
>>>=20
>>> 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 Tue Mar 25 17:37:49 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 3F6761A026C for ; Tue, 25 Mar 2014 17:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 fbRUnXMYwKHY for ; Tue, 25 Mar 2014 17:37:43 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id D24581A0263 for ; Tue, 25 Mar 2014 17:37:42 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2Q0baEn099630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 25 Mar 2014 19:37:37 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <4CAA0308-08B6-4F7D-9A51-7A4AAA833404@att.com>
Date: Tue, 25 Mar 2014 19:37:35 -0500
X-Mao-Original-Outgoing-Id: 417487055.641266-4e74abae78c1927c252ff41f6c0f7875
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.com>,  <4CAA0308-08B6-4F7D-9A51-7A4AAA833404@att.com>
To: MARTIN C DOLLY 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/C928J718clvhG6i2AKm31qvZekI
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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: Wed, 26 Mar 2014 00:37:46 -0000

A reporting node has two ways of ending a reported overload condition. =
It can forcefully expire the report, by sending an updated report with a =
zero expiration time. Or it can let the report expire by not updating =
it.

This is analogous to how SIP handles registrations and subscriptions. =
You can remove one by sending a new REGISTER or SUBSCRIBE with =
expires=3D0.  Or if the registration or subscription is close to ending =
anyway, you can let it expire.

The "consensus" position says that you SHOULD do the first. That implies =
you SHOULD NOT do the second. My position is that we don't need that =
restriction; either choice is okay as long as it happens in a timely =
manner. In fact there may be times where sending an updated report does =
nothing but add unneeded messages.

I will go further to say that a normative preference for one or the =
other violates RFC 2119 guidance for normative language, in that the =
SHOULD is not necessary for interoperability, because both strategies =
work. And neither approach does damage, as long as it is timely.

Now, I agree that the reporting node SHOULD ensure that the overload =
report is invalidated in a timely manner. I just don't think we need to =
prefer one method of doing that over another.


On Mar 25, 2014, at 6:51 PM, DOLLY, MARTIN C  wrote:

> Why, sorry but please repeat or I go with I believe consensus
>=20
> Thanks
>=20
> Martin Dolly
> Lead Member of Technical Staff
> Core Network & Gov't/Regulatory Standards =20
> AT&T Standards and Industry Alliances
> +1-609-903-3360
> md3135@att.com
>=20
>> On Mar 25, 2014, at 7:17 PM, "Ben Campbell"  wrote:
>>=20
>> I do not agree. While this fixes a related problem of using a zero =
validity-duration to signal the end of an overload condition, it still =
implies that one SHOULD NOT let a report "just expire". As I've argued =
before, I believe there are time when it is just as good, if not better, =
to let an overload condition expire naturally.
>>=20
>> Here's a quote of my argument to that effect from further down the =
thread:
>>=20
>>> I think it's reasonable to say that a reporting node should =
terminate an overload condition in a timely manner. But if it's about to =
expire anyway, then expiration might be just as timely as an explicit =
report.=20
>>>=20
>>> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.
>>=20
>> So, here's a different proposal for your first paragraph:
>>=20
>>  "When a reporting node has recovered from overload, it SHOULD =
invalidate any existing overload reports in a timely matter. This can be =
achieved by sending an updated overload report (meaning the OLR contains =
a new sequence number) with the OC-Validity-Duration AVP value set to =
zero ("0"). If the overload report is about to expire naturally, the =
reporting node MAY choose to simply let it do so."
>>=20
>>=20
>>> On Mar 24, 2014, at 3:38 PM, Steve Donovan =
 wrote:
>>>=20
>>> Here's some proposed wording that will hopefully let us close this =
issue:
>>>=20
>>> Regards,
>>>=20
>>> Steve
>>>=20
>>> -----
>>>=20
>>> Section 4.5., paragraph 3 -=20
>>>=20
>>> Current -02 wording:
>>>=20
>>> As a general guidance for implementations it is RECOMMENDED never to
>>>  let any overload report to timeout.  Following to this rule, an
>>>  overload endpoint should explicitly signal the end of overload
>>>  condition and not rely on the expiration of the validity time of =
the
>>>  overload report in the reacting node.  This is achieved by sending =
an
>>>  updated overload report (meaning it must contain a new sequence
>>>  number) with the OC-Validity-Duration AVP value set to zero ("0").
>>>=20
>>> Proposed wording:
>>>=20
>>>  A reporting node SHOULD explicitly signal the end of overload
>>>  condition in a timely manner.  This is achieved by sending an
>>>  updated overload report (meaning the OLR contains a new sequence
>>>  number) with the OC-Validity-Duration AVP value set to zero ("0").
>>>=20
>>> A reacting node MUST invalidate and remove an overload report that
>>> expires without an explicit overload report containing an =
OC-Validity-Duration
>>> value set to zero ("0").
>>>=20
>>>=20
>>>> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>>>> Fine with me.
>>>>=20
>>>> - Jouni
>>>>=20
>>>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome=20
>>>> 
>>>> wrote:
>>>>=20
>>>>=20
>>>>> Ben, Nirav,
>>>>>=20
>>>>> I follow same argumentation.
>>>>> Regards
>>>>> /MCruz
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of Nirav Salot (nsalot)
>>>>> Sent: martes, 11 de febrero de 2014 11:23
>>>>> To: Ben Campbell; Jouni Korhonen
>>>>> Cc:=20
>>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not =
letting overload reports expire
>>>>>=20
>>>>> Ben,
>>>>>=20
>>>>> I resonate with your thinking below.
>>>>>=20
>>>>> Regards,
>>>>> Nirav.
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of Ben Campbell
>>>>> Sent: Monday, February 10, 2014 9:54 PM
>>>>> To: Jouni Korhonen
>>>>> Cc:=20
>>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not =
letting overload reports expire
>>>>>=20
>>>>>=20
>>>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen=20
>>>>> 
>>>>> wrote:
>>>>>=20
>>>>>=20
>>>>>> My reasoning for explicit termination was that knowing the=20
>>>>>> implementation folks they will let overload conditions expire =
unless advised otherwise.
>>>>>> And having unnecessary stuff hanging around waiting for a cleanup =
is=20
>>>>>> not a good thing in general. But I am open here for other =
options..
>>>>> I think it's reasonable to say that a reporting node should =
terminate an overload condition in a timely manner. But if it's about to =
expire anyway, then expiration might be just as timely as an explicit =
report.=20
>>>>>=20
>>>>> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> 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 Tue Mar 25 18:57:24 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 30D321A0069 for ; Tue, 25 Mar 2014 18:57:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.279
X-Spam-Level: 
X-Spam-Status: No, score=0.279 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 MaLOc17L093V for ; Tue, 25 Mar 2014 18:57:19 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 96D361A005F for ; Tue, 25 Mar 2014 18:57:19 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50144 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSd5Z-0005Nf-UG; Tue, 25 Mar 2014 18:57:17 -0700
Message-ID: <533233F6.9080406@usdonovans.com>
Date: Tue, 25 Mar 2014 20:57:10 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Ben Campbell 
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.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/cYHxrFqc4QpCFyStqgV2WYBz62w
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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: Wed, 26 Mar 2014 01:57:21 -0000

I'm ok with Ben's suggested wording.

Steve

On 3/25/14, 6:16 PM, Ben Campbell wrote:
> I do not agree. While this fixes a related problem of using a zero validity-duration to signal the end of an overload condition, it still implies that one SHOULD NOT let a report "just expire". As I've argued before, I believe there are time when it is just as good, if not better, to let an overload condition expire naturally.
>
> Here's a quote of my argument to that effect from further down the thread:
>
>> I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report.
>>
>> And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.
> So, here's a different proposal for your first paragraph:
>
>     "When a reporting node has recovered from overload, it SHOULD invalidate any existing overload reports in a timely matter. This can be achieved by sending an updated overload report (meaning the OLR contains a new sequence number) with the OC-Validity-Duration AVP value set to zero ("0"). If the overload report is about to expire naturally, the reporting node MAY choose to simply let it do so."
>
>
> On Mar 24, 2014, at 3:38 PM, Steve Donovan  wrote:
>
>> Here's some proposed wording that will hopefully let us close this issue:
>>
>> Regards,
>>
>> Steve
>>
>> -----
>>
>> Section 4.5., paragraph 3 -
>>
>> Current -02 wording:
>>
>> As a general guidance for implementations it is RECOMMENDED never to
>>     let any overload report to timeout.  Following to this rule, an
>>     overload endpoint should explicitly signal the end of overload
>>     condition and not rely on the expiration of the validity time of the
>>     overload report in the reacting node.  This is achieved by sending an
>>     updated overload report (meaning it must contain a new sequence
>>     number) with the OC-Validity-Duration AVP value set to zero ("0").
>>
>> Proposed wording:
>>
>>     A reporting node SHOULD explicitly signal the end of overload
>>     condition in a timely manner.  This is achieved by sending an
>>     updated overload report (meaning the OLR contains a new sequence
>>     number) with the OC-Validity-Duration AVP value set to zero ("0").
>>
>>    A reacting node MUST invalidate and remove an overload report that
>>    expires without an explicit overload report containing an OC-Validity-Duration
>>    value set to zero ("0").
>>
>>
>> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>>> Fine with me.
>>>
>>> - Jouni
>>>
>>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome
>>> 
>>>   wrote:
>>>
>>>
>>>> Ben, Nirav,
>>>>
>>>> I follow same argumentation.
>>>> Regards
>>>> /MCruz
>>>>
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of Nirav Salot (nsalot)
>>>> Sent: martes, 11 de febrero de 2014 11:23
>>>> To: Ben Campbell; Jouni Korhonen
>>>> Cc:
>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>
>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>>>>
>>>> Ben,
>>>>
>>>> I resonate with your thinking below.
>>>>
>>>> Regards,
>>>> Nirav.
>>>>
>>>> -----Original Message-----
>>>> From: DiME [
>>>> mailto:dime-bounces@ietf.org
>>>> ] On Behalf Of Ben Campbell
>>>> Sent: Monday, February 10, 2014 9:54 PM
>>>> To: Jouni Korhonen
>>>> Cc:
>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>
>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting overload reports expire
>>>>
>>>>
>>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen
>>>> 
>>>>   wrote:
>>>>
>>>>
>>>>> My reasoning for explicit termination was that knowing the
>>>>> implementation folks they will let overload conditions expire unless advised otherwise.
>>>>> And having unnecessary stuff hanging around waiting for a cleanup is
>>>>> not a good thing in general. But I am open here for other options..
>>>>>
>>>>>
>>>> I think it's reasonable to say that a reporting node should terminate an overload condition in a timely manner. But if it's about to expire anyway, then expiration might be just as timely as an explicit report.
>>>>
>>>> And of course, the definition of "timely" is somewhat a matter of policy. For example, I can imagine an deployment that had a large number of clients using fairly short validity durations, and _never_ explicitly signaling an end to an overload condition. This adds a bit of a "slow-start" to the recovery, since different clients will expire the overload condition at different times, and the load will ramp up gradually. I don't see anything wrong with that. Of course, it wouldn't work if one chose long validity durations, or if the signaling of overload to different clients happened in close synchronization.
>>>>
>>>> _______________________________________________
>>>> 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
>


From nobody Tue Mar 25 21:14: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 745961A00A9 for ; Tue, 25 Mar 2014 21:14:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5wpGfXDfIFrx for ; Tue, 25 Mar 2014 21:13:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 400B71A0083 for ; Tue, 25 Mar 2014 21:13:52 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCL02581; Wed, 26 Mar 2014 04:13:50 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 04:13:25 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 04:13:49 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Wed, 26 Mar 2014 12:13:41 +0800
From: "Shishufeng (Susan)" 
To: Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGA=
Date: Wed, 26 Mar 2014 04:13:40 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>
In-Reply-To: <533178CD.9030707@usdonovans.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3E4C3SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/qE6X7LQHCt1rTk84Udc8mI0pm20
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 04:14:00 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E4C3SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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









--_000_26C84DFD55BC3040A45BF70926E55F2587C3E4C3SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Stev=
e,


 =
;


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 =
;


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 =
;


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 Steve Donovan [mail=
to:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and r=
eached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


 


Lets have it explicit then. Use '<' and '>'=
 to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> =
wrote:


 




I'm ok with either direction but generally lean t=
oward being explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
o:p>




Hello,


I think the agreement tendency is the contrary: O=
C-Report-Type is not required, while default value is Host. i.e. it will re=
main as it is now in the draft.


This may be of some advantage for some applicatio=
ns that may only use Host, as long as they may never generate Realm reports=
.


If there is consensus on this, I will go with thi=
s.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan=



Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


All,


 


Do we have consensus that the OC-Report-Type AVP =
is required?


 


If so then one change would be as indicated in th=
e syntax definition proposed by Lionel.  We would also remove wording =
on the default value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?&n=
bsp; 


 


I presonally don't see this as critical but we ca=
n add this requirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if i=
t has a default 


value and the receiver knows exactly how to proce=
ed when the AVP is 


not present?


 


If a node does not include it when it should, the=
 implementation is 


broken. Wouldn't a broken node be able to put wro=
ng report type into 


the AVP even if the AVP is mandatory?<=
/span>


 


Anyway, if it is my statement keeping issue #54 s=
till open, consider 


it resolved from my side. I am OK making the OC-R=
eport-Type AVP as 


required/mandatory AVP. Should we also consider i=
t having a fixed 


position just after the OC-Sequence-Number AVP as=
 well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolom=
e <maria.cruz.barto=
lome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend t=
o prefer to make it mandatory, since I think this is less error-prone, sinc=
e the only node that knows the requested Report-Type is the reporting, if f=
or any reason a reporting is omitting it (since it is optional), it will be=
 always interpreted as HOST, but this type may be wrong.<=
/pre>

 


I think DEFAULT values should never be error-pron=
e, but used in "general cases", as a simplification, like e.g. a =
default for the Validity-Duration. Default Validity-Duration will never be =
an "error", it could be not the best value (compared with another=
 value perfectly tuned to reporting node overload situation) but never the =
use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell<=
/span>


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


I actually prefer making it mandatory. The cost o=
f adding it is trivial--even more so for a reporting node that only support=
s the default. The value of having it is less opportunity for interop error=
s.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro=
te:


 


 


Agree that it is a small optimization, which I pu=
t there because at 


the beginning there seemed to be a lot of worry o=
n every extra AVP 


;-)


 


I prefer having the AVP optional but with a defau=
lt value just like 


it is now. We have the same for the reduction per=
centage and the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not p=
resent the OLR is of type Host, which was fine for me and keeps my preferen=
ce. 


We may have  deployments where Realm OLR is =
not used, or where statistically the HOST type is the most frequent, so to =
have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I =
agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lione=
l.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolom=
e@ericsson.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" i=
nstead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  [ OC-Report-Type ]


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  { OC-Report-Type }


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:=
26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP=
 is 0 (i.e. the host  


report).


 


This AVP is always required, right? Then, I think=
 it is more precise that  we define this AVP as mandatory.<=
/span>


 


--


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


Reporter:  maria.cruz.bartolome@ericsson.com  | &nbs=
p;    Owner:  MCruz


  Type:  defect    =
             &n=
bsp;           |&nbs=
p; Bartolom=E9


Priority:  major    &nbs=
p;            &=
nbsp;            |&n=
bsp;    Status:  new


Component:  draft-docdt-dime-ovli  =
;            | =
 Milestone:


Severity:  Active WG Document  &nb=
sp;            =
  |    Version:  1.0


        &=
nbsp;           &nbs=
p;             =
          |   K=
eywords:


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket=
/54>


dime &=
lt;http://tools.ietf.org/wg/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 et=
re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me=
ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law; they shoul=
d 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 fo=
r 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

 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


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



 


 


 




 




 






--_000_26C84DFD55BC3040A45BF70926E55F2587C3E4C3SZXEMA512MBXchi_--


From nobody Tue Mar 25 23:34: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 3B0551A029D for ; Tue, 25 Mar 2014 23:34:52 -0700 (PDT)
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 SWUAIHG5y4aC for ; Tue, 25 Mar 2014 23:34:46 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id D3CCB1A01DD for ; Tue, 25 Mar 2014 23:34:45 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4D66E2AC2FA; Wed, 26 Mar 2014 07:34:41 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1EDF915807E; Wed, 26 Mar 2014 07:34:41 +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; Wed, 26 Mar 2014 07:34:40 +0100
From: 
To: Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" , Steve Donovan 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRRecscXj4P/C40GW6f1v1eWv+5rr96eAgAQ/IICAACZMgIAAKEkAgAEey4CAACLtgIAAF+UAgAABqACAABEhsIAABUSAgAD5udM=
Date: Wed, 26 Mar 2014 06:34:39 +0000
Message-ID: <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5331B195.9020402@usdonovans.com>
In-Reply-To: <5331B195.9020402@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_anlyh92po3ps3dth8oijm8v11395815673766emailandroidcom_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.233016
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/lHjV0mS2__dwK7UvyzxacUZbe2Y
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Wed, 26 Mar 2014 06:34:52 -0000

--_000_anlyh92po3ps3dth8oijm8v11395815673766emailandroidcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Steve,

In London, we ended up with the following proposal:

- ONLY two report types
- "Host" that applies when destination-host is present in the request.
- "Realm" that applies to any request sent to a realm, except when a destin=
ation-host is present in the request AND a "Host" applies for this destinat=
ion-host.

About renaming "Realm" as "Realm-Routed-Request", no strong issue as soon a=
s the principle above are kept.

The need for realm-based type that would apply to any request (even if a "H=
ost" exists for a destination-host in the request) was challenged and not r=
etained. Ben was supposed to lock you in a room and to convince you that th=
is last report type was not needed.

Lionel

Envoy=E9 depuis mon Sony Xperia SP d'Orange

Steve Donovan  a =E9crit :



Consensus is obviously a fleeting and temporary thing.

Let us make sure that we are precise in our definitions of the report types=
 we are discussing.

Host report - Applies when the destination-host AVP is present in the reque=
st.
Realm-Routed-Request (RRR) - Applies when there is no destination-host AVP =
in the request.
Realm - Applies to 100% of requests sent to the realm.

These are the definitions used in our discussions in London and in various =
places in our email discussions.

Can we please agree to use these definitions going forward so we are all ta=
lking about the same thing.

Regards,

Steve

On 3/25/14 10:27 AM, lionel.morand@orange.com wrote:
Hi Maria Cruz, All,

In the previous mail, you wrote:

That is, we have two reports, host and realm.
Host applies when Destination_host is present, and then it takes precedence=
 over Realm. If both are present, only Host is applied.
Realm applies when only Destination_realm is present.

And I agree with this statement. But I'm not sure that this is the case dis=
cussed by Ulrich.

Whatever the name of the realm report type, is there an agreement on the de=
scription given above by Maria Cruz and discussed in London?

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 mars 2014 16:21
=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports

Dear all,

I support option 1 a well
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 25 de marzo de 2014 16:15
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Steve,
Thank you for this summary.
Please see inline.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,

I mean going backwards from where I thought we were after the London meetin=
g.

We are clearly out of sync but hopefully we can fix that.

Here's my understanding of the status of #23 and #55.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to realm-routed-r=
eports (RRR).
this includes agreement to keep the (newly called) realm-routed-rep=
orts
 - Discussions were ongoing as to the need for both realm reports and RRR r=
eports.
I would say =93=85as to the need for realm reports in addition to r=
ealm-routed-reports=94 


#55 status:
  - Agreement on adding Realm reports based on the definition that realm re=
ports apply to all traffic sent to the realm.
This is what I=92m missing. The issue has been very briefly discuss=
ed under #34 without conclusion. There was no discussion under #55

  - Limited discussion on the interaction between the new realm reports and=
 the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
What was the technical argument?

  - Ben expressed the strongest concern with this plan.  Steve and Ben took=
 action to discuss and come back with a recommendation.

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types - hos=
t and realm, with realm having the new definition.
What was the technical argument?

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and revisit l=
ater is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to supp=
ort realm reports.  Others might have a different opinion.
 There was no comment posted to issue #55, also no proposed solutio=
n, so I cannot see where the consensus came from


Summary:
  - I believe we have three options:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan coming =
out of the London meeting
< Ulrich> There is not even an issue number identifying problems with RRR a=
nd proposing to remove RRR

   3) Support host, RRR and Realm reports
 I support option 1

Regards,

Steve
On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,
I don=92t think we are going backwards (we may be out of synch though)

Can you please summarize the status of #23 and #55.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don=92t know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve





_______________________________________________

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.



___________________________________________________________________________=
______________________________________________

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_anlyh92po3ps3dth8oijm8v11395815673766emailandroidcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







Hi Steve,

In London, we ended up with the following proposal:

- ONLY two report types
- "Host" that applies when destination-host is present in the req=
uest.
- "Realm" that applies to any request sent to a realm, except whe=
n a destination-host is present in the request AND a "Host" appli=
es for this destination-host.

About renaming "Realm" as "Realm-Routed-Request", no st=
rong issue as soon as the principle above are kept.

The need for realm-based type that would apply to any request (even if a &q=
uot;Host" exists for a destination-host in the request) was challenged=
 and not retained. Ben was supposed to lock you in a room and to convince y=
ou that this last report type was not needed.

Lionel=20

Envoy=E9 depuis mon Sony Xperia SP d'Orange

Steve Donovan <srdonovan@usdonovans.com> a =E9crit :




Consensus is obviously a =
fleeting and temporary thing.



Let us make sure that we are precise in our definitions of the report types=
 we are discussing.



Host report - Applies when the destination-host AVP is present in the reque=
st.

Realm-Routed-Request (RRR) - Applies when there is no destination-host AVP =
in the request.

Realm - Applies to 100% of requests sent to the realm.



These are the definitions used in our discussions in London and in various =
places in our email discussions. 




Can we please agree to use these definitions going forward so we are all ta=
lking about the same thing.



Regards,



Steve





On 3/25/14 10:27 AM, 
lionel.morand@orange.com wrote:








Hi Maria Cruz, All,


 


In the p=
revious mail, you wrote:


 


That is, we have two reports, host and realm.



Host applies when Destination_host is present, and =
then it takes precedence over Realm. If both are present, only
 Host is applied.


Realm applies when only Destination_realm is presen=
t.


 


And I ag=
ree with this statement. But I'm not sure that this is the case discussed b=
y Ulrich.


 


Whatever=
 the name of the realm report type, is there an agreement on the descriptio=
n given above by Maria Cruz and discussed in London?


 


Regards,=



 


Lionel


 






De : DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 25 mars 2014 16:21

=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; 
dime@ietf.org

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


Dear all=
,


 


I suppor=
t option 1 a well


Cheers


/MCruz


 






Fro=
m: DiME [mailto:dim=
e-bounces@ietf.org]
On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: martes, 25 de marzo de 2014 16:15

To: ext Steve Donovan; 
dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Steve,


Thank yo=
u for this summary.


Please s=
ee inline.


 


Ulrich


 






Fro=
m: ext Steve Donov=
an [mailto:srdonovan@usdonovans=
.com]


Sent: Tuesday, March 25, 2014 2:49 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,



I mean going backwards from where I thought we were after the London meetin=
g.



We are clearly out of sync but hopefully we can fix that.



Here's my understanding of the status of #23 and #55.



Prior to London meeting:



#23 status:

 - Agreement to change the name of existing realm reports to realm-rou=
ted-reports (RRR).


<Ulrich>this includes agreement to keep the (n=
ewly called) realm-routed-reports</Ulrich>

 - Discussions were ongoing as to the need for both realm reports and =
RRR reports.


<Ulrich>I would say =93=85as to the need for r=
ealm reports in addition to realm-routed-reports=94 </Ulrich><=
/p>

=




#55 status:

  - Agreement on adding Realm reports based on the definition that rea=
lm reports apply to all traffic sent to the realm.


<Ulrich>This is what I=92m missing. The issue =
has been very briefly discussed under #34 without conclusion. There
 was no discussion under #55</Ulrich>


=


  - Limited discussion on the interaction between the new realm report=
s and the existing host and RRR reports.



After London meeting:



#23 status:

  - Tentative agreement in London meeting to remove RRR reports.


<Ulrich>What was the technical argument?</U=
lrich>


=


  - Ben expressed the strongest concern with this plan.  <=
span lang=3D"DE">Steve and Ben took action to discuss and come back with a =
recommendation. 




#55 status:

  - No change



Summary:

  - Tentative consensus reached to move forward with two report types =
- host and realm, with realm having the new definition.

<Ulrich>What was t=
he technical argument?</Ulrich>




Current status:



#23 status:

 - Change the name to RRR

 - Whether or not to remove RRR and revisit later or keep RRR and revi=
sit later is an open issue.



#55 status:

  - My opinion is that we have at least rough consensus on the need to=
 support realm reports.  Others might have a different opinion.=



<Ulrich> There was no comment posted to issue =
#55, also no proposed solution, so I cannot see where the consensus
 came from</Ulrich>


=




Summary:

  - I believe we have three options:



   1) Support host and RRR reports

   2) Support host and Realm reports -- This was the tentative pl=
an coming out of the London meeting


< Ulrich> There is not even an issue number id=
entifying problems with RRR and proposing to remove RRR</Ulrich>


=


   3) Support host, RRR and Realm reports


<Ulrich> I support option 1</Ulrich>


=


Regards,



Steve




On 3/25/14 6:44 AM, Wiehe, Ulrich =
(NSN - DE/Munich) wrote:






Steve,


I don=92=
t think we are going backwards (we may be out of synch though)


 


Can you =
please summarize the status of #23 and #55.=



 


Ulrich


 


 






Fro=
m: ext Steve Donov=
an [mailto:srdonovan@usdonovans=
.com]


Sent: Monday, March 24, 2014 7:38 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ok,=
 we are going backwards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,


 


I do not ag=
ree.


 


We shoul=
d still have the option



3) suppo=
rt report type 0 (this is called host report) and support of report type 1 =
(this has been called relam report but people argued it should
 better be called realm routed request report).


 


Whether =
or not we need in addition to type 0 and type 1 (or as a replacement of typ=
e 1) a realm-no-matter-whether-destination-host-is present-or-not
 report   is an open issue (see #55).


There ar=
e a lot of open questions  with regard to #55 and I have not seen a co=
nclusion.


Where I =
have seen a conclusion is issue #34 and that is inline with option 3).


 


Unless w=
e conclude on #55, or decide to re-open #34, option 3) is what should go in=
 the -02 draft.


 


 


Ulrich


 






Fro=
m: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan =
wrote:






Ulr=
ich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,


 


I don=92=
t know what happend in London.


Can you =
please summarize the technical reasons that led to the London agreement.



E-mail d=
iscussions prior to London have clearly directed towards a report type that=
 requests throttling of realm routed request messages (i.e.
 not containing a destination host) rather than a report type that requests=
 throttling of messages routed towards a realm (no matter whether they cont=
ain a destination host or not).   


 


Ulrich


 






Fro=
m: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 















_______________________________________________


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.









______________________________________________________________________=
___________________________________________________

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_anlyh92po3ps3dth8oijm8v11395815673766emailandroidcom_--


From nobody Tue Mar 25 23:43:59 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 1F55D1A00F2 for ; Tue, 25 Mar 2014 23:43:56 -0700 (PDT)
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 hY3lMQ-ziiU6 for ; Tue, 25 Mar 2014 23:43:50 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DCF4E1A0203 for ; Tue, 25 Mar 2014 23:43:49 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id A9C8D18C102; Wed, 26 Mar 2014 07:43:47 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 8A3D235C045; Wed, 26 Mar 2014 07:43:47 +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; Wed, 26 Mar 2014 07:43:47 +0100
From: 
To: Steve Donovan , Jouni Korhonen , "Shishufeng (Susan)" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRXfTKav1Yd2xqUyLNClmxsrsL5rvj0+AgACNVgCAATdcAIAAXpSAgAEFQACAADq1WA==
Date: Wed, 26 Mar 2014 06:43:46 +0000
Message-ID: <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_4wjyrmeak04xst2onmes7ybh1395816218573emailandroidcom_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/9eNgR1oxrFtOMsT0_89m6PthmDY
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 06:43:56 -0000

--_000_4wjyrmeak04xst2onmes7ybh1395816218573emailandroidcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

As chair and temporary doc shepherd,

Please stop this thread for now.

As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.

Lionel


"Shishufeng (Susan)"  a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I=92m not familiar with it, while=
 I know the draft is mainly for 3GPP use, that=92s why we 3GPP delegates ar=
e deeply involved in this specific discussion. If most of 3GPP people think=
 it is not so needed I couldn=92t understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let=92s move on with the draft as it i=
s on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That=92s how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.


--_000_4wjyrmeak04xst2onmes7ybh1395816218573emailandroidcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable








As chair and temporary doc shepherd,

Please stop this thread for now.

As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.

Lionel=20


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9cri=
t :








Hello St=
eve,


 


Thanks f=
or clarifying the IETF procedure. I=92m not familiar with it, while I know =
the draft is mainly for 3GPP use, that=92s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn=92t understand why it shall be mandatory.<=
/span>


 


From tec=
hnical point of view, in the case realm based report type is not needed, no=
thing wrong without this AVP, and even better and cleaner.


 


And you =
ever said you have preference but ok with either way forward, i.e., make it=
 mandatory or optional. Then let=92s move on with the draft
 as it is on this point, if you agree. 


 


Best Reg=
ards,


Susan


 






Fro=
m: Steve Donovan [=
mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve=
,


 


As I kno=
w, majority companies expressed preference to keep the AVP as optional and =
keep the texts as they are. You have preference to have it
 explicitly but ok with either way. That=92s how I assumed we reached conse=
nsus.


 


Best Reg=
ards,


Susan


 






Fro=
m: Steve Donovan [=
mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and r=
eached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


 


Lets have it explicit then. Use '<' and '>'=
 to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> =
wrote:


 




I'm ok with either direction but generally lean t=
oward being explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/span>




Hello,


I think the agreement tendency is the contrary: O=
C-Report-Type is not required, while default value is Host. i.e. it will re=
main as it is now in the draft.


This may be of some advantage for some applicatio=
ns that may only use Host, as long as they may never generate Realm reports=
.


If there is consensus on this, I will go with thi=
s.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


All,


 


Do we have consensus that the OC-Report-Type AVP =
is required?


 


If so then one change would be as indicated in th=
e syntax definition proposed by Lionel.  We would also remove wording =
on the default value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?&n=
bsp; 


 


I presonally don't see this as critical but we ca=
n add this requirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:=



 


Hi,


 


How having the AVP could be less error prone if i=
t has a default 


value and the receiver knows exactly how to proce=
ed when the AVP is 


not present?


 


If a node does not include it when it should, the=
 implementation is 


broken. Wouldn't a broken node be able to put wro=
ng report type into 


the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 s=
till open, consider 


it resolved from my side. I am OK making the OC-R=
eport-Type AVP as 


required/mandatory AVP. Should we also consider i=
t having a fixed 


position just after the OC-Sequence-Number AVP as=
 well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolom=
e <maria.cruz.barto=
lome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend t=
o prefer to make it mandatory, since I think this is less error-prone, sinc=
e the only node that knows the requested Report-Type is the reporting, if f=
or any reason a reporting is omitting it (since it is optional), it will be=
 always interpreted as HOST, but this type may be wrong.


 


I think DEFAULT values should never be error-pron=
e, but used in "general cases", as a simplification, like e.g. a =
default for the Validity-Duration. Default Validity-Duration will never be =
an "error", it could be not the best value (compared with another=
 value perfectly tuned to reporting node overload situation) but never the =
use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13=



To: Jouni Korhonen


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


I actually prefer making it mandatory. The cost o=
f adding it is trivial--even more so for a reporting node that only support=
s the default. The value of having it is less opportunity for interop error=
s.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro=
te:


 


 


Agree that it is a small optimization, which I pu=
t there because at 


the beginning there seemed to be a lot of worry o=
n every extra AVP 


;-)


 


I prefer having the AVP optional but with a defau=
lt value just like 


it is now. We have the same for the reduction per=
centage and the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not p=
resent the OLR is of type Host, which was fine for me and keeps my preferen=
ce. 


We may have  deployments where Realm OLR is =
not used, or where statistically the HOST type is the most frequent, so to =
have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I =
agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lione=
l.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolom=
e@ericsson.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" i=
nstead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >

        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  [ OC-Report-Type ]


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >

        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  { OC-Report-Type }


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:=
26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP=
 is 0 (i.e. the host  


report).


 


This AVP is always required, right? Then, I think=
 it is more precise that  we define this AVP as mandatory.


 


--


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


Reporter:  maria.cruz.bartolome@ericsson.com  | &nbs=
p;    Owner:  MCruz


  Type:  defect    =
             &n=
bsp;           |&nbs=
p; Bartolom=E9


Priority:  major    &nbs=
p;            &=
nbsp;            |&n=
bsp;    Status:  new


Component:  draft-docdt-dime-ovli  =
;            | =
 Milestone:


Severity:  Active WG Document  &nb=
sp;            =
  |    Version:  1.0


        &=
nbsp;           &nbs=
p;             =
          |   K=
eywords:


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket=
/54>


dime &=
lt;http://tools.ietf.org/wg/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 et=
re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me=
ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law; they shoul=
d 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 fo=
r 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


 


 




 


_______________________________________________


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_4wjyrmeak04xst2onmes7ybh1395816218573emailandroidcom_--


From nobody Tue Mar 25 23:56: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 251951A0203 for ; Tue, 25 Mar 2014 23:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VofEftyQg1FN for ; Tue, 25 Mar 2014 23:56:12 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A56291A00F2 for ; Tue, 25 Mar 2014 23:56:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEY40053; Wed, 26 Mar 2014 06:56:07 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 06:55:24 +0000
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 06:55:43 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Wed, 26 Mar 2014 14:55:31 +0800
From: "Shishufeng (Susan)" 
To: "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg
Date: Wed, 26 Mar 2014 06:55:31 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com>
In-Reply-To: <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3E57BSZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/KAxYsXmb8HsQFZpYirDp9oK7e1o
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 06:56:19 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E57BSZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E57BSZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Lion=
el,


 =
;


I don̵=
7;t understand it.


 =
;


Please cla=
rify if you care about other people’s comments.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


As chair and temporary doc shepherd,


 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (even if useless in=
 certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9crit :<=
o:p>


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. =



 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and r=
eached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


 


Lets have it explicit then. Use '<' and '>'=
 to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> =
wrote:


 




I'm ok with either direction but generally lean t=
oward being explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
o:p>




Hello,


I think the agreement tendency is the contrary: O=
C-Report-Type is not required, while default value is Host. i.e. it will re=
main as it is now in the draft.


This may be of some advantage for some applicatio=
ns that may only use Host, as long as they may never generate Realm reports=
.


If there is consensus on this, I will go with thi=
s.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan=



Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


All,


 


Do we have consensus that the OC-Report-Type AVP =
is required?


 


If so then one change would be as indicated in th=
e syntax definition proposed by Lionel.  We would also remove wording =
on the default value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?&n=
bsp; 


 


I presonally don't see this as critical but we ca=
n add this requirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if i=
t has a default 


value and the receiver knows exactly how to proce=
ed when the AVP is 


not present?


 


If a node does not include it when it should, the=
 implementation is 


broken. Wouldn't a broken node be able to put wro=
ng report type into 


the AVP even if the AVP is mandatory?<=
/span>


 


Anyway, if it is my statement keeping issue #54 s=
till open, consider 


it resolved from my side. I am OK making the OC-R=
eport-Type AVP as 


required/mandatory AVP. Should we also consider i=
t having a fixed 


position just after the OC-Sequence-Number AVP as=
 well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolom=
e <maria.cruz.barto=
lome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend t=
o prefer to make it mandatory, since I think this is less error-prone, sinc=
e the only node that knows the requested Report-Type is the reporting, if f=
or any reason a reporting is omitting it (since it is optional), it will be=
 always interpreted as HOST, but this type may be wrong.<=
/pre>

 


I think DEFAULT values should never be error-pron=
e, but used in "general cases", as a simplification, like e.g. a =
default for the Validity-Duration. Default Validity-Duration will never be =
an "error", it could be not the best value (compared with another=
 value perfectly tuned to reporting node overload situation) but never the =
use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell<=
/span>


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


I actually prefer making it mandatory. The cost o=
f adding it is trivial--even more so for a reporting node that only support=
s the default. The value of having it is less opportunity for interop error=
s.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro=
te:


 


 


Agree that it is a small optimization, which I pu=
t there because at 


the beginning there seemed to be a lot of worry o=
n every extra AVP 


;-)


 


I prefer having the AVP optional but with a defau=
lt value just like 


it is now. We have the same for the reduction per=
centage and the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not p=
resent the OLR is of type Host, which was fine for me and keeps my preferen=
ce. 


We may have  deployments where Realm OLR is =
not used, or where statistically the HOST type is the most frequent, so to =
have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I =
agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lione=
l.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolom=
e@ericsson.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" i=
nstead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  [ OC-Report-Type ]


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  { OC-Report-Type }


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:=
26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP=
 is 0 (i.e. the host  


report).


 


This AVP is always required, right? Then, I think=
 it is more precise that  we define this AVP as mandatory.<=
/span>


 


--


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


Reporter:  maria.cruz.bartolome@ericsson.com  | &nbs=
p;    Owner:  MCruz


  Type:  defect    =
             &n=
bsp;           |&nbs=
p; Bartolom=E9


Priority:  major    &nbs=
p;            &=
nbsp;            |&n=
bsp;    Status:  new


Component:  draft-docdt-dime-ovli  =
;            | =
 Milestone:


Severity:  Active WG Document  &nb=
sp;            =
  |    Version:  1.0


        &=
nbsp;           &nbs=
p;             =
          |   K=
eywords:


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket=
/54>


dime &=
lt;http://tools.ietf.org/wg/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 et=
re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me=
ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law; they shoul=
d 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 fo=
r 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

 


 




 


_______________________________________________


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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=



Thank you.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3E57BSZXEMA512MBXchi_--


From nobody Wed Mar 26 00:06:04 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 0B0C01A02A9 for ; Wed, 26 Mar 2014 00:06:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1J-tsz1RDi5m for ; Wed, 26 Mar 2014 00:05:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B7BAC1A02A4 for ; Wed, 26 Mar 2014 00:05:51 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCL13408; Wed, 26 Mar 2014 07:05:49 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 07:05:16 +0000
Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 07:05:48 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 26 Mar 2014 15:05:40 +0800
From: "Shishufeng (Susan)" 
To: "Shishufeng (Susan)" , "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVA=
Date: Wed, 26 Mar 2014 07:05:39 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3E5ADSZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/H0xtRq_a4RelqC87P5uvGY3WfvA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 07:06:01 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E5ADSZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E5ADSZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Lion=
el,


 =
;


Further cl=
arification:


 =
;


I don̵=
7;t agree with this, not ok to everyone as you said.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@huawei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,


 


Please stop this thread for now.=



 


As mandatory/required is ok for everyone (even if useless in=
 certain case), let use it for now.<=
/span>


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9crit :<=
/span>


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. =



 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and r=
eached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


 


Lets have it explicit then. Use '<' and '>'=
 to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> =
wrote:


 




I'm ok with either direction but generally lean t=
oward being explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
o:p>




Hello,


I think the agreement tendency is the contrary: O=
C-Report-Type is not required, while default value is Host. i.e. it will re=
main as it is now in the draft.


This may be of some advantage for some applicatio=
ns that may only use Host, as long as they may never generate Realm reports=
.


If there is consensus on this, I will go with thi=
s.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan=



Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


All,


 


Do we have consensus that the OC-Report-Type AVP =
is required?


 


If so then one change would be as indicated in th=
e syntax definition proposed by Lionel.  We would also remove wording =
on the default value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?&n=
bsp; 


 


I presonally don't see this as critical but we ca=
n add this requirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if i=
t has a default 


value and the receiver knows exactly how to proce=
ed when the AVP is 


not present?


 


If a node does not include it when it should, the=
 implementation is 


broken. Wouldn't a broken node be able to put wro=
ng report type into 


the AVP even if the AVP is mandatory?<=
/span>


 


Anyway, if it is my statement keeping issue #54 s=
till open, consider 


it resolved from my side. I am OK making the OC-R=
eport-Type AVP as 


required/mandatory AVP. Should we also consider i=
t having a fixed 


position just after the OC-Sequence-Number AVP as=
 well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolom=
e <maria.cruz.barto=
lome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend t=
o prefer to make it mandatory, since I think this is less error-prone, sinc=
e the only node that knows the requested Report-Type is the reporting, if f=
or any reason a reporting is omitting it (since it is optional), it will be=
 always interpreted as HOST, but this type may be wrong.<=
/pre>

 


I think DEFAULT values should never be error-pron=
e, but used in "general cases", as a simplification, like e.g. a =
default for the Validity-Duration. Default Validity-Duration will never be =
an "error", it could be not the best value (compared with another=
 value perfectly tuned to reporting node overload situation) but never the =
use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell<=
/span>


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


I actually prefer making it mandatory. The cost o=
f adding it is trivial--even more so for a reporting node that only support=
s the default. The value of having it is less opportunity for interop error=
s.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro=
te:


 


 


Agree that it is a small optimization, which I pu=
t there because at 


the beginning there seemed to be a lot of worry o=
n every extra AVP 


;-)


 


I prefer having the AVP optional but with a defau=
lt value just like 


it is now. We have the same for the reduction per=
centage and the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not p=
resent the OLR is of type Host, which was fine for me and keeps my preferen=
ce. 


We may have  deployments where Realm OLR is =
not used, or where statistically the HOST type is the most frequent, so to =
have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I =
agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lione=
l.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolom=
e@ericsson.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" i=
nstead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  [ OC-Report-Type ]


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  { OC-Report-Type }


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:=
26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP=
 is 0 (i.e. the host  


report).


 


This AVP is always required, right? Then, I think=
 it is more precise that  we define this AVP as mandatory.<=
/span>


 


--


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


Reporter:  maria.cruz.bartolome@ericsson.com  | &nbs=
p;    Owner:  MCruz


  Type:  defect    =
             &n=
bsp;           |&nbs=
p; Bartolom=E9


Priority:  major    &nbs=
p;            &=
nbsp;            |&n=
bsp;    Status:  new


Component:  draft-docdt-dime-ovli  =
;            | =
 Milestone:


Severity:  Active WG Document  &nb=
sp;            =
  |    Version:  1.0


        &=
nbsp;           &nbs=
p;             =
          |   K=
eywords:


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket=
/54>


dime &=
lt;http://tools.ietf.org/wg/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 et=
re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me=
ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law; they shoul=
d 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 fo=
r 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

 


 




 


_______________________________________________


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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler=



a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;=



they should not be distributed, used or copied wi=
thout 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 fo=
r messages that have been modified, changed or falsified.=



Thank you.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3E5ADSZXEMA512MBXchi_--


From nobody Wed Mar 26 00:35:34 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 1FDEB1A012D for ; Wed, 26 Mar 2014 00:35:32 -0700 (PDT)
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 Ss6jfcXZX-NS for ; Wed, 26 Mar 2014 00:35:22 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id BB24B1A010B for ; Wed, 26 Mar 2014 00:35:21 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 7953019043D; Wed, 26 Mar 2014 08:35:19 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 4EB05158059; Wed, 26 Mar 2014 08:35:19 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 08:35:19 +0100
From: 
To: "Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRXfTKav1Yd2xqUyLNClmxsrsL5rvj0+AgACNVgCAATdcAIAAXpSAgAEFQACAADq1WP//8oSAgAAC1ICAABOaIA==
Date: Wed, 26 Mar 2014 07:35:18 +0000
Message-ID: <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51C25APEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.233016
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/llhaaj9pXIOCRCVEAeUVH9pJw1c
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 07:35:32 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51C25APEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E51C25APEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Susan,<=
o:p>


 =
;


I do care =
about comments from other but we need to move on.


 =
;


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 =
;


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 =
;


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 =
;


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 =
;


Regards,


 =
;


Lionel.


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@h=
uawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@huawei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,


 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (even if useless in=
 certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9crit :<=
/span>


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and r=
eached consensus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


 


Lets have it explicit then. Use '<' and '>'=
 to make the position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> =
wrote:


 




I'm ok with either direction but generally lean t=
oward being explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/span>




Hello,


I think the agreement tendency is the contrary: O=
C-Report-Type is not required, while default value is Host. i.e. it will re=
main as it is now in the draft.


This may be of some advantage for some applicatio=
ns that may only use Host, as long as they may never generate Realm reports=
.


If there is consensus on this, I will go with thi=
s.


Best regards


/MCruz


 


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


All,


 


Do we have consensus that the OC-Report-Type AVP =
is required?


 


If so then one change would be as indicated in th=
e syntax definition proposed by Lionel.  We would also remove wording =
on the default value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?&n=
bsp; 


 


I presonally don't see this as critical but we ca=
n add this requirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:=



 


Hi,


 


How having the AVP could be less error prone if i=
t has a default 


value and the receiver knows exactly how to proce=
ed when the AVP is 


not present?


 


If a node does not include it when it should, the=
 implementation is 


broken. Wouldn't a broken node be able to put wro=
ng report type into 


the AVP even if the AVP is mandatory?=



 


Anyway, if it is my statement keeping issue #54 s=
till open, consider 


it resolved from my side. I am OK making the OC-R=
eport-Type AVP as 


required/mandatory AVP. Should we also consider i=
t having a fixed 


position just after the OC-Sequence-Number AVP as=
 well since it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolom=
e <maria.cruz.barto=
lome@ericsson.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend t=
o prefer to make it mandatory, since I think this is less error-prone, sinc=
e the only node that knows the requested Report-Type is the reporting, if f=
or any reason a reporting is omitting it (since it is optional), it will be=
 always interpreted as HOST, but this type may be wrong.<=
/pre>

 


I think DEFAULT values should never be error-pron=
e, but used in "general cases", as a simplification, like e.g. a =
default for the Validity-Duration. Default Validity-Duration will never be =
an "error", it could be not the best value (compared with another=
 value perfectly tuned to reporting node overload situation) but never the =
use of a Default value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell=



Sent: viernes, 14 de febrero de 2014 23:13=



To: Jouni Korhonen


Cc: dime@ietf.or=
g


Subject: Re: [Dime] [dime] #54: OC-Report-Type as=
 mandatory AVP


 


I actually prefer making it mandatory. The cost o=
f adding it is trivial--even more so for a reporting node that only support=
s the default. The value of having it is less opportunity for interop error=
s.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wro=
te:


 


 


Agree that it is a small optimization, which I pu=
t there because at 


the beginning there seemed to be a lot of worry o=
n every extra AVP 


;-)


 


I prefer having the AVP optional but with a defau=
lt value just like 


it is now. We have the same for the reduction per=
centage and the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN=
-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not p=
resent the OLR is of type Host, which was fine for me and keeps my preferen=
ce. 


We may have  deployments where Realm OLR is =
not used, or where statistically the HOST type is the most frequent, so to =
have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I =
agree it is a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lione=
l.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolom=
e@ericsson.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" i=
nstead of "mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  [ OC-Report-Type ]


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


        &=
nbsp;  < OC-Sequence-Number >


        &=
nbsp;  { OC-Report-Type }


        &=
nbsp;  [ OC-Reduction-Percentage ]


        &=
nbsp;  [ OC-Validity-Duration ]


         =
* [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue <=
/o:p>


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:=
26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP<=
/o:p>


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP=
 is 0 (i.e. the host  


report).


 


This AVP is always required, right? Then, I think=
 it is more precise that  we define this AVP as mandatory.=



 


--


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


Reporter:  maria.cruz.bartolome@ericsson.com  | &nbs=
p;    Owner:  MCruz


  Type:  defect    =
             &n=
bsp;           |&nbs=
p; Bartolom=E9


Priority:  major    &nbs=
p;            &=
nbsp;            |&n=
bsp;    Status:  new


Component:  draft-docdt-dime-ovli  =
;            | =
 Milestone:


Severity:  Active WG Document  &nb=
sp;            =
  |    Version:  1.0


        &=
nbsp;           &nbs=
p;             =
          |   K=
eywords:


-----------------------------------------------&#=
43;---------------------


-----------------------------------------------&#=
43;---


-----------------------------------------------&#=
43;---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket=
/54>


dime &=
lt;http://tools.ietf.org/wg/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 et=
re diffuses, exploites ou copies sans autorisation. Si vous avez recu ce me=
ssage par erreur, veuillez le signaler a l'expediteur et le detruire ainsi =
que les pieces jointes. Les messages electroniques etant susceptibles d'alt=
eration, Orange decline toute responsabilite si ce message a ete altere, de=
forme ou falsifie. Merci.


 


This message and its attachments may contain conf=
idential or privileged information that may be protected by law; they shoul=
d 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.<=
/o:p>


As emails may be altered, Orange is not liable fo=
r 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


 


 




 


_______________________________________________


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 autor=
isation. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les piece=
s 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 conf=
idential or privileged information that may be protected by law;


they should not be distributed, used or copied wi=
thout authorisation.


If you have received this email in error, please =
notify the sender and delete this message and its attachments.<=
/o:p>


As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=



Thank you.




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E51C25APEXCVZYM13corpora_--


From nobody Wed Mar 26 00:56:15 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 970C01A02D1 for ; Wed, 26 Mar 2014 00:56:13 -0700 (PDT)
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 qMwnEF_bg0TU for ; Wed, 26 Mar 2014 00:56:11 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 226611A02CB for ; Wed, 26 Mar 2014 00:56:10 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2Q7u74C006780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Mar 2014 02:56:08 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2Q7u6vM002371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 08:56:06 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 08:56:06 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAHYCmoAAxWkVQ
Date: Wed, 26 Mar 2014 07:56:06 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2014@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D2014@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/giwFPe23R2tvxeqQ6v-HUr4-l88
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 07:56:13 -0000

Hi Ulrich

I agree with your example: so with an OCS that can be defined per applicati=
on and algorithm.
Nevertheless a remark, I think this OCS exists only when the algorithm has =
been selected. I do not see the case of an OCS with a supported but not sel=
ected algorithm. I may miss something.

So wording in 5.5.1.2 could be:
	A reporting node maintains per supported Diameter application and per
    selected Abatement Algorithm an Overload
    Control State....
=20
This does  not remove my questioning about the per client case: pease see t=
he other mail

Best regards

JJacques


-----Message d'origine-----
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Envoy=E9=A0: mardi 25 mars 2014 09:08
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet=A0: RE: issue #56 proposed conclusion

Hi JJacques,

let me try to give an example:

Client C1 supports algorithms A1 and A2.
Server S supports algorithms A1 and A2.
Client C2 supports only algorithm A1.

C1 sends an application x request indicating support of A1 and A2 to the se=
rver S.
Now S selects one single algorithm (in this example A2) and requests some r=
eduction using A2.  S has a OCS identified by the pair (x,A2).

Now client C2 sends an application x request indicating support of A1 to S.=
=20
Again S selects one single algorithm (in this case A1) and requests some re=
duction using A1. S has an OCS identified by the pair (x,A1).

In summary it is right that S selects one single algorithm out of the set o=
f adveritzed algorithms, but this does not mean that S must only maintain o=
ne OCS.

Best regards
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:08 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: lundi 24 mars 2014 18:24 =C0=A0: Wiehe, Ulrich (=
NSN - DE/Munich); dime@ietf.org Objet=A0: Re: [Dime] issue #56 proposed con=
clusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

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


From nobody Wed Mar 26 00:59:03 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 0AFDC1A02D5 for ; Wed, 26 Mar 2014 00:59:02 -0700 (PDT)
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 BtllYHd4Mn5p for ; Wed, 26 Mar 2014 00:58:59 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 7261D1A02CB for ; Wed, 26 Mar 2014 00:58:59 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2Q7wuRh009204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Mar 2014 02:58:57 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2Q7wtii004600 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 08:58:55 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 08:58:55 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAAWgNwAAcxQhgADDx3RA=
Date: Wed, 26 Mar 2014 07:58:54 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/hLDHD006_ahF-PmnVon6AYXZCSE
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 07:59:02 -0000

Hi Ulrich

1) My point is that the definition of OCS should be sufficiently generic so=
 to apply to various algorithms. The current definition applies to the defa=
ult algorithm, but will need to be extended to support the overload mitigat=
ion for a specific  client.
For other algorithms, I mentioned the rate control as we will work on it. A=
nd in my previous mail example, with all clients and the server supporting =
selecting the rate control, I currently do not see how to not introduce OCS=
 per client somewhere (in the server or in a DA) to be able to run the rate=
 control.

So I propose  to evolve your definition
  =20
A reporting node maintains per supported Diameter application, per
    selected Abatement Algorithm and eventually per client if relevant an O=
verload
    Control State

Such a definition would be more generic and applicable to future algorithms=
. I think the draft should be future proof.


2) I am also questioning, if we have not the need to define an OCS per appl=
ication  per selected algorithm and per realm for a reporting node (eg  in =
the DA that is generating Realm reports for request without destination hos=
ts; realm OCS is only defined for reacting nodes in your proposal. Here aga=
in I would have  the additional question OCS eventually per client   =20


Best regards=20

JJacques=20

-----Message d'origine-----
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Envoy=E9=A0: mardi 25 mars 2014 09:24
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet=A0: RE: issue #56 proposed conclusion

Hi JJacques

Your concern is related to issue #35. For #35 we almost reached the conclus=
ion not to address client specific throttling in the 02-draft.

The latest proposal to solve #35 was to let clients indicate in OC-Supporte=
d-Features that they are clients; agents taking the role of reacting nodes =
on behalf of clients would not indicate  so. Servers must not request clien=
t specific throtting from reacting nodes that did not indicate that they ar=
e clients.
With this (partial) solution of #35 there would not be any impact to my pro=
posal for #56.

Best regards
Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given =
client=20

Your description of state is defined per Application and Abatement, so not =
including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There =
is the rate control algorithm that we will study, and here I am questioning=
 if we will not be driven to have a state per client, as the requested rate=
 will be rather specific to a client, some clients may have a small traffic=
  and others a large traffic, meaning to define a requested rate per client=
 somewhere.=20

So I may again repeat myself that the normal state would be per client in g=
eneral, which does not exclude to group all clients and consider a state co=
mmon to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but=
 it also concern other tickets.

Best regards=20

JJacques  =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9=A0: lundi 24 mars 2014 19:08 =C0=A0: dime@ietf.=
org Objet=A0: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: lundi 24 mars 2014 18:24 =C0=A0: Wiehe, Ulrich (=
NSN - DE/Munich); dime@ietf.org Objet=A0: Re: [Dime] issue #56 proposed con=
clusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

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

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


From nobody Wed Mar 26 01:04: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 A29FB1A02DE for ; Wed, 26 Mar 2014 01:03:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 joXCuDeZbzED for ; Wed, 26 Mar 2014 01:03:51 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 241191A00B0 for ; Wed, 26 Mar 2014 01:03:49 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEY46507; Wed, 26 Mar 2014 08:03:48 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 08:03:14 +0000
Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 08:03:45 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Wed, 26 Mar 2014 16:03:35 +0800
From: "Shishufeng (Susan)" 
To: "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q
Date: Wed, 26 Mar 2014 08:03:34 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3E671SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/xoBUw-7P2fLWGZ4hVk_y0zi-q5o
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 08:03:58 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E671SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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_26C84DFD55BC3040A45BF70926E55F2587C3E671SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Lion=
el,


 =
;


Thanks for=
 your reply.


 =
;


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 =
;


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 =
;


Best Regar=
ds,


Susan=



 =
;


 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,<=
o:p>


 =
;


I do care =
about comments from other but we need to move on.


 =
;


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 =
;


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 =
;


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 =
;


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 =
;


Regards,


 =
;


Lionel.


 =
;






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



As chair and temporary doc shepherd,=



 


Please stop this thread for now. 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 

 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 

 


Best Regards,


Susan


 


 


-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:=





Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.If there is consensus on this, I will go with this.


Best regards


/MCruz


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 


If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?=



 


Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?

 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 


I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----

From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell=



Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 


I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
span lang=3D"FR" style=3D"font-size:10.0pt;font-family:"Courier New&qu=
ot;">


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----

De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 

lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :<=
o:p>


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,


 


I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?


 


So instead of:


 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >


           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >


           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----

De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue <=
/span>


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP<=
/span>


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 


This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.=



 


--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz


  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new


Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>


 


_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime

 


_____________________________________________________________=
________


____________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.<=
/span>


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


 


_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime

_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime

 


_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime

 


_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime

 


_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime

 


_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime

 


 




 


_______________________________________________<=
o:p>


DiME mailing list


DiME@ietf.orghttps:=
//www.ietf.org/mailman/listinfo/dime



 


 


 




 =





 =







_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.<=
/span>


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


________________________________________________________________=
_________________________________________________________=



 


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.


 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3E671SZXEMA512MBXchi_--


From nobody Wed Mar 26 01:26:47 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 3FF9F1A0138 for ; Wed, 26 Mar 2014 01:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 mg9ytaVJ6zU1 for ; Wed, 26 Mar 2014 01:26:42 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE261A0121 for ; Wed, 26 Mar 2014 01:26:42 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2Q8Q5co000349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Mar 2014 08:26:05 GMT
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2Q8Q44d030577 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 09:26:05 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Mar 2014 09:26:04 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Wed, 26 Mar 2014 09:26:04 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAAWgNwAAcxQhgADDx3RAAAVklwA==
Date: Wed, 26 Mar 2014 08:26:04 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@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.112]
Content-Type: text/plain; charset="iso-8859-1"
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: 10739
X-purgate-ID: 151667::1395822365-0000137C-3FDCA1FB/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/zrp_oK5fzrlG_J7-Ae3XuhcZmH0
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 08:26:46 -0000

Hi JJacques,

In order to meet Steve's deadline for the 02-draft I would like to close #5=
6 as proposed by Steve.
This does not mean that we cannot improve text for 03.

Ad 1) I don't think that the definition of OCS is Loss specific. Whether we=
 need client-specific OCS should be discussed under #35. As we have it now =
there is one OCS shared for all reacting nodes with which the same algorith=
m was negotiated.
This of course limits agents taking the role of a reacting node for two cli=
ents C1 and C2 to advertize the same set of algorithm, and reacting nodes t=
o select the algorithm based on the set of advertized algorithm and not bas=
ed on the client.

Ad 2) The current text assumes that a reporting node is located in just one=
 realm. If that is not the case OCSs need to be maintained per realm. We ma=
y want to look at this when working on 03.

Best regards
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Wednesday, March 26, 2014 8:59 AM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

1) My point is that the definition of OCS should be sufficiently generic so=
 to apply to various algorithms. The current definition applies to the defa=
ult algorithm, but will need to be extended to support the overload mitigat=
ion for a specific  client.
For other algorithms, I mentioned the rate control as we will work on it. A=
nd in my previous mail example, with all clients and the server supporting =
selecting the rate control, I currently do not see how to not introduce OCS=
 per client somewhere (in the server or in a DA) to be able to run the rate=
 control.

So I propose  to evolve your definition
  =20
A reporting node maintains per supported Diameter application, per
    selected Abatement Algorithm and eventually per client if relevant an O=
verload
    Control State

Such a definition would be more generic and applicable to future algorithms=
. I think the draft should be future proof.


2) I am also questioning, if we have not the need to define an OCS per appl=
ication  per selected algorithm and per realm for a reporting node (eg  in =
the DA that is generating Realm reports for request without destination hos=
ts; realm OCS is only defined for reacting nodes in your proposal. Here aga=
in I would have  the additional question OCS eventually per client   =20


Best regards=20

JJacques=20

-----Message d'origine-----
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Envoy=E9=A0: mardi 25 mars 2014 09:24
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet=A0: RE: issue #56 proposed conclusion

Hi JJacques

Your concern is related to issue #35. For #35 we almost reached the conclus=
ion not to address client specific throttling in the 02-draft.

The latest proposal to solve #35 was to let clients indicate in OC-Supporte=
d-Features that they are clients; agents taking the role of reacting nodes =
on behalf of clients would not indicate  so. Servers must not request clien=
t specific throtting from reacting nodes that did not indicate that they ar=
e clients.
With this (partial) solution of #35 there would not be any impact to my pro=
posal for #56.

Best regards
Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given =
client=20

Your description of state is defined per Application and Abatement, so not =
including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There =
is the rate control algorithm that we will study, and here I am questioning=
 if we will not be driven to have a state per client, as the requested rate=
 will be rather specific to a client, some clients may have a small traffic=
  and others a large traffic, meaning to define a requested rate per client=
 somewhere.=20

So I may again repeat myself that the normal state would be per client in g=
eneral, which does not exclude to group all clients and consider a state co=
mmon to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but=
 it also concern other tickets.

Best regards=20

JJacques  =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9=A0: lundi 24 mars 2014 19:08 =C0=A0: dime@ietf.=
org Objet=A0: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: lundi 24 mars 2014 18:24 =C0=A0: Wiehe, Ulrich (=
NSN - DE/Munich); dime@ietf.org Objet=A0: Re: [Dime] issue #56 proposed con=
clusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

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

_______________________________________________
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 Wed Mar 26 01:31: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 086E91A0138 for ; Wed, 26 Mar 2014 01:31:52 -0700 (PDT)
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 b1lb2BekWj6S for ; Wed, 26 Mar 2014 01:31:42 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 511111A0121 for ; Wed, 26 Mar 2014 01:31:41 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 3573C2AC6DB; Wed, 26 Mar 2014 09:31:37 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 0F6A718006E; Wed, 26 Mar 2014 09:31:37 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 09:31:36 +0100
From: 
To: "Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRXfTKav1Yd2xqUyLNClmxsrsL5rvj0+AgACNVgCAATdcAIAAXpSAgAEFQACAADq1WP//8oSAgAAC1ICAABOaIP///JUAgAAWOoA=
Date: Wed, 26 Mar 2014 08:31:35 +0000
Message-ID: <11539_1395822697_53329069_11539_6077_1_6B7134B31289DC4FAF731D844122B36E51C523@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51C523PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.173915
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/buhIskIVUMyy4kJMkDppzxkizhE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 08:31:52 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51C523PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Susan,

Except your point of view that I respect, I haven't read anyone saying that=
 they cannot accept to rely on a required AVP. And it is not yet confirmed =
that the AVP will be useless for 3GPP application. S6a does not represent t=
he whole use cases in 3GPP and at least two operators think that they will =
use the concept of Realm-based report in their own network.
And even from your side, I understand that you consider useless in some cas=
es this AVP but you don't really challenge the fact that the presence of th=
is AVP in any report would cause an issue.

Based on this status, my preferred approach is the one proposed below.

Now, if there is strong concern about this AVP we can revert this decision =
but:
1/ there is no reason not to accept this working assumption
2/ moving back this AVP from required to optional will not fundamentally im=
pact the solution.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E51C523PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Susan,


 <=
/p>

Except you=
r point of view that I respect, I haven't read anyone saying that they cann=
ot accept to rely on a required AVP. And it is not yet confirmed
 that the AVP will be useless for 3GPP application. S6a does not represent =
the whole use cases in 3GPP and at least two operators think that they will=
 use the concept of Realm-based report in their own network.


And even f=
rom your side, I understand that you consider useless in some cases this AV=
P but you don't really challenge the fact that the presence
 of this AVP in any report would cause an issue.


 =
;


Based on t=
his status, my preferred approach is the one proposed below.


 =
;


Now, if th=
ere is strong concern about this AVP we can revert this decision but:<=
/o:p>


1/ there i=
s no reason not to accept this working assumption


2/ moving =
back this AVP from required to optional will not fundamentally impact the s=
olution.


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@h=
uawei.com]


Envoy=E9 : mercredi 26 mars 2014 09:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,=



 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/o:p>




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 =



From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:<=
/pre>

 =



Hi,


 =



How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 =



If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 =



Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?


 =



- Jouni


 =



 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 =



 


Hello all,


 =



I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 =



I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 =



Best regards


/MCruz


 =



-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13<=
/pre>

To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 =



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 =



I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 =



- Jouni


 =



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 =



Hi Mcruz


 =



The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
o:p>


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 =



Best regards


 =



JJacques


 =



 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 


lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



Hi Maria Cruz,


 =



I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?


 =



So instead of:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



You would prefer:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



And I'm fine with this proposal.


 =



Cheers,


 =



Lionel


 =



-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



#54: OC-Report-Type as mandatory AVP


 =



Now in chapter 4.6:


 =



 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 =



This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 =



--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz


  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new


Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 =



Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>


 =



_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 =



_____________________________________________________________=
________


____________________________________________________


 =



Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 =



This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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


 =



 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 




 






_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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.




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E51C523PEXCVZYM13corpora_--


From nobody Wed Mar 26 01:47: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 2A5DF1A007A for ; Wed, 26 Mar 2014 01:47:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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 eCJdLGhC__3P for ; Wed, 26 Mar 2014 01:47:07 -0700 (PDT)
Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) by ietfa.amsl.com (Postfix) with ESMTP id 362851A010C for ; Wed, 26 Mar 2014 01:47:07 -0700 (PDT)
Received: by mail-lb0-f169.google.com with SMTP id q8so1236103lbi.14 for ; Wed, 26 Mar 2014 01:47:05 -0700 (PDT)
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=z0Uz+YYtmUBATpwsg2ctI9xajtRmcbxhXuAf7dalGeQ=; b=laiknEQtF8YWe7YNe265myhiSFxM6OoAedaw48g5yBwP58ychC+u1MbvHFOLVeronu QciiTNOkwyzc2NiEheAOs8/gKawmcNcm/IWkxVw1p+K6zfL/juuSk5Li2FAIRD/gHJZd oivLmUVlCwqKnWiu+i9ME5gqzj/qSHjOWunk87+34BH3ltobvtfO/eWLPBBrrr6bUCEk v3ZVdaYBAEeGZ/043xvjJ5I1zaNywbX4UnqURZdQu83BfCOnSN6q+aQ+pbTSuwfipW8v aBM16ZEuUUg6NZAhS6DjoDL2p7drwdYVRy1Lu460fqhq7wjosAK4JNixdI0ICVnp8k6O DSUg==
X-Received: by 10.152.42.196 with SMTP id q4mr53675125lal.14.1395823625247; Wed, 26 Mar 2014 01:47:05 -0700 (PDT)
Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id a7sm470647lbc.9.2014.03.26.01.47.03 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 26 Mar 2014 01:47:04 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen 
In-Reply-To: <533233F6.9080406@usdonovans.com>
Date: Wed, 26 Mar 2014 10:47:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C40B3ED-3B21-4013-9679-98A63DDF56AD@gmail.com>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>  <4B803326-40A9-4E98-AC12-7DDF46BD101B@nostrum.com>  <087A34937E64E74E848732CFF8354B9209772E9C@ESESSMB101.ericsson.se> <58574389-BAEB-49DA-A07E-B6648905C291@gmail.com> <533097D1.3090803@usdonovans.com>  <533233F6.9080406@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/aaxqB62QwLRXbJ6zvGZtk6sb9gY
Cc: Ben Campbell , dime@ietf.org
Subject: Re: [Dime] [dime] #46: Bad normative advice on not letting	overload reports expire
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: Wed, 26 Mar 2014 08:47:10 -0000

+1

On Mar 26, 2014, at 3:57 AM, Steve Donovan  =
wrote:

> I'm ok with Ben's suggested wording.
>=20
> Steve
>=20
> On 3/25/14, 6:16 PM, Ben Campbell wrote:
>> I do not agree. While this fixes a related problem of using a zero =
validity-duration to signal the end of an overload condition, it still =
implies that one SHOULD NOT let a report "just expire". As I've argued =
before, I believe there are time when it is just as good, if not better, =
to let an overload condition expire naturally.
>>=20
>> Here's a quote of my argument to that effect from further down the =
thread:
>>=20
>>> I think it's reasonable to say that a reporting node should =
terminate an overload condition in a timely manner. But if it's about to =
expire anyway, then expiration might be just as timely as an explicit =
report.
>>>=20
>>> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.
>> So, here's a different proposal for your first paragraph:
>>=20
>>    "When a reporting node has recovered from overload, it SHOULD =
invalidate any existing overload reports in a timely matter. This can be =
achieved by sending an updated overload report (meaning the OLR contains =
a new sequence number) with the OC-Validity-Duration AVP value set to =
zero ("0"). If the overload report is about to expire naturally, the =
reporting node MAY choose to simply let it do so."
>>=20
>>=20
>> On Mar 24, 2014, at 3:38 PM, Steve Donovan  =
wrote:
>>=20
>>> Here's some proposed wording that will hopefully let us close this =
issue:
>>>=20
>>> Regards,
>>>=20
>>> Steve
>>>=20
>>> -----
>>>=20
>>> Section 4.5., paragraph 3 -
>>>=20
>>> Current -02 wording:
>>>=20
>>> As a general guidance for implementations it is RECOMMENDED never to
>>>    let any overload report to timeout.  Following to this rule, an
>>>    overload endpoint should explicitly signal the end of overload
>>>    condition and not rely on the expiration of the validity time of =
the
>>>    overload report in the reacting node.  This is achieved by =
sending an
>>>    updated overload report (meaning it must contain a new sequence
>>>    number) with the OC-Validity-Duration AVP value set to zero =
("0").
>>>=20
>>> Proposed wording:
>>>=20
>>>    A reporting node SHOULD explicitly signal the end of overload
>>>    condition in a timely manner.  This is achieved by sending an
>>>    updated overload report (meaning the OLR contains a new sequence
>>>    number) with the OC-Validity-Duration AVP value set to zero =
("0").
>>>=20
>>>   A reacting node MUST invalidate and remove an overload report that
>>>   expires without an explicit overload report containing an =
OC-Validity-Duration
>>>   value set to zero ("0").
>>>=20
>>>=20
>>> On 2/11/14 4:31 PM, Jouni Korhonen wrote:
>>>> Fine with me.
>>>>=20
>>>> - Jouni
>>>>=20
>>>> On Feb 11, 2014, at 12:24 PM, Maria Cruz Bartolome
>>>> 
>>>>  wrote:
>>>>=20
>>>>=20
>>>>> Ben, Nirav,
>>>>>=20
>>>>> I follow same argumentation.
>>>>> Regards
>>>>> /MCruz
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of Nirav Salot (nsalot)
>>>>> Sent: martes, 11 de febrero de 2014 11:23
>>>>> To: Ben Campbell; Jouni Korhonen
>>>>> Cc:
>>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not =
letting overload reports expire
>>>>>=20
>>>>> Ben,
>>>>>=20
>>>>> I resonate with your thinking below.
>>>>>=20
>>>>> Regards,
>>>>> Nirav.
>>>>>=20
>>>>> -----Original Message-----
>>>>> From: DiME [
>>>>> mailto:dime-bounces@ietf.org
>>>>> ] On Behalf Of Ben Campbell
>>>>> Sent: Monday, February 10, 2014 9:54 PM
>>>>> To: Jouni Korhonen
>>>>> Cc:
>>>>> dime@ietf.org list; draft-docdt-dime-ovli@tools.ietf.org
>>>>>=20
>>>>> Subject: Re: [Dime] [dime] #46: Bad normative advice on not =
letting overload reports expire
>>>>>=20
>>>>>=20
>>>>> On Feb 10, 2014, at 5:16 AM, Jouni Korhonen
>>>>> 
>>>>>  wrote:
>>>>>=20
>>>>>=20
>>>>>> My reasoning for explicit termination was that knowing the
>>>>>> implementation folks they will let overload conditions expire =
unless advised otherwise.
>>>>>> And having unnecessary stuff hanging around waiting for a cleanup =
is
>>>>>> not a good thing in general. But I am open here for other =
options..
>>>>>>=20
>>>>>>=20
>>>>> I think it's reasonable to say that a reporting node should =
terminate an overload condition in a timely manner. But if it's about to =
expire anyway, then expiration might be just as timely as an explicit =
report.
>>>>>=20
>>>>> And of course, the definition of "timely" is somewhat a matter of =
policy. For example, I can imagine an deployment that had a large number =
of clients using fairly short validity durations, and _never_ explicitly =
signaling an end to an overload condition. This adds a bit of a =
"slow-start" to the recovery, since different clients will expire the =
overload condition at different times, and the load will ramp up =
gradually. I don't see anything wrong with that. Of course, it wouldn't =
work if one chose long validity durations, or if the signaling of =
overload to different clients happened in close synchronization.
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>>=20
>>>>> DiME@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dime
>>>> _______________________________________________
>>>> DiME mailing list
>>>>=20
>>>> DiME@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dime
>>>>=20
>>>>=20
>>>>=20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dime
>>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Mar 26 01:51: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 A29BA1A02D2 for ; Wed, 26 Mar 2014 01:51:35 -0700 (PDT)
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 IQslB6bsap22 for ; Wed, 26 Mar 2014 01:51:32 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 72E221A0141 for ; Wed, 26 Mar 2014 01:51:32 -0700 (PDT)
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 s2Q8pTeq015377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Mar 2014 03:51:30 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2Q8pSGR004297 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 09:51:28 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 09:51:28 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAAWgNwAAcxQhgADDx3RAAAVklwAABAxkA
Date: Wed, 26 Mar 2014 08:51:27 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/sDo5nAAx9prOkP3kG-G9Vt66_78
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 08:51:35 -0000

Hi Ulrich

1) I understand and agree it is good to have a text in v02 on OCS definitio=
n. #35 will deal on the protocol aspects about DOIC information transfer fo=
r client mitigation in te loss algorithm context .  But regarding OCS defin=
ition I prefer to have the OCS definition currently covering a larger scope=
 that may be reviewed if needed in 03 than to do the reverse. For loss algo=
rithm, in the dedicated part for loss that Ben mentioned, we can later add =
that the per client OCS case would be used for a specific client mitigation=
. For  other algorithms (eg rate control) we will see which type of OCS to =
apply , but it will remain compliant with the general definition. So I rema=
in in favor of my proposal, why not to introduce it?

2) about realm OCS, it is to identify the OCS associated to the generation =
of a realm OLR, as this OCS will store the=20
Reduction percentage for the realm.

Best regards

JJacques  =20


-----Message d'origine-----
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20
Envoy=E9=A0: mercredi 26 mars 2014 09:26
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet=A0: RE: issue #56 proposed conclusion

Hi JJacques,

In order to meet Steve's deadline for the 02-draft I would like to close #5=
6 as proposed by Steve.
This does not mean that we cannot improve text for 03.

Ad 1) I don't think that the definition of OCS is Loss specific. Whether we=
 need client-specific OCS should be discussed under #35. As we have it now =
there is one OCS shared for all reacting nodes with which the same algorith=
m was negotiated.
This of course limits agents taking the role of a reacting node for two cli=
ents C1 and C2 to advertize the same set of algorithm, and reacting nodes t=
o select the algorithm based on the set of advertized algorithm and not bas=
ed on the client.

Ad 2) The current text assumes that a reporting node is located in just one=
 realm. If that is not the case OCSs need to be maintained per realm. We ma=
y want to look at this when working on 03.

Best regards
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Wednesday, March 26, 2014 8:59 AM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

1) My point is that the definition of OCS should be sufficiently generic so=
 to apply to various algorithms. The current definition applies to the defa=
ult algorithm, but will need to be extended to support the overload mitigat=
ion for a specific  client.
For other algorithms, I mentioned the rate control as we will work on it. A=
nd in my previous mail example, with all clients and the server supporting =
selecting the rate control, I currently do not see how to not introduce OCS=
 per client somewhere (in the server or in a DA) to be able to run the rate=
 control.

So I propose  to evolve your definition
  =20
A reporting node maintains per supported Diameter application, per
    selected Abatement Algorithm and eventually per client if relevant an O=
verload
    Control State

Such a definition would be more generic and applicable to future algorithms=
. I think the draft should be future proof.


2) I am also questioning, if we have not the need to define an OCS per appl=
ication  per selected algorithm and per realm for a reporting node (eg  in =
the DA that is generating Realm reports for request without destination hos=
ts; realm OCS is only defined for reacting nodes in your proposal. Here aga=
in I would have  the additional question OCS eventually per client   =20


Best regards=20

JJacques=20

-----Message d'origine-----
De=A0: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy=
=E9=A0: mardi 25 mars 2014 09:24 =C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUE=
S); dime@ietf.org Objet=A0: RE: issue #56 proposed conclusion

Hi JJacques

Your concern is related to issue #35. For #35 we almost reached the conclus=
ion not to address client specific throttling in the 02-draft.

The latest proposal to solve #35 was to let clients indicate in OC-Supporte=
d-Features that they are clients; agents taking the role of reacting nodes =
on behalf of clients would not indicate  so. Servers must not request clien=
t specific throtting from reacting nodes that did not indicate that they ar=
e clients.
With this (partial) solution of #35 there would not be any impact to my pro=
posal for #56.

Best regards
Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given =
client=20

Your description of state is defined per Application and Abatement, so not =
including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There =
is the rate control algorithm that we will study, and here I am questioning=
 if we will not be driven to have a state per client, as the requested rate=
 will be rather specific to a client, some clients may have a small traffic=
  and others a large traffic, meaning to define a requested rate per client=
 somewhere.=20

So I may again repeat myself that the normal state would be per client in g=
eneral, which does not exclude to group all clients and consider a state co=
mmon to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but=
 it also concern other tickets.

Best regards=20

JJacques  =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES) Envoy=E9=A0: lundi 24 mars 2014 19:08 =C0=A0: dime@ietf.=
org Objet=A0: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm....=20


I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client=20

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques =20


-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN=
 - DE/Munich) Envoy=E9=A0: lundi 24 mars 2014 18:24 =C0=A0: Wiehe, Ulrich (=
NSN - DE/Munich); dime@ietf.org Objet=A0: Re: [Dime] issue #56 proposed con=
clusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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=
s
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OL=
R
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

  =20
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State.=20

    An Overload Control State may be identified by the pair of Application-=
Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatemen=
t
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

   =20
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host=
-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when
    receiving an answer message of application app-id containing an Orig-Ho=
st of
    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Re=
alm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the
    need to modify the requested amount of application app-id traffic reduc=
tion.

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

_______________________________________________
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 Wed Mar 26 01:55:03 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 03C791A010C for ; Wed, 26 Mar 2014 01:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Qrli01XPzlvW for ; Wed, 26 Mar 2014 01:54:51 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 51AB01A013D for ; Wed, 26 Mar 2014 01:54:50 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCL24078; Wed, 26 Mar 2014 08:54:48 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 08:54:22 +0000
Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 08:54:45 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 26 Mar 2014 16:54:33 +0800
From: "Shishufeng (Susan)" 
To: "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q//+EAID//3VhAA==
Date: Wed, 26 Mar 2014 08:54:31 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3E707@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <11539_1395822697_53329069_11539_6077_1_6B7134B31289DC4FAF731D844122B36E51C523@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <11539_1395822697_53329069_11539_6077_1_6B7134B31289DC4FAF731D844122B36E51C523@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3E707SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/gY1Yzuci8F1vmV18oQ9_HU7fNVs
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 08:55:00 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E707SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Lionel,

You didn't answer me why you decide to propose a way not preferred by major=
ity companies. I have strong concern on it. And for the 2/, we are not reve=
rting anything, it is optional in the existing draft from the beginning.

Thanks if we can conclude on this issue and move on.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 4:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Except your point of view that I respect, I haven't read anyone saying that=
 they cannot accept to rely on a required AVP. And it is not yet confirmed =
that the AVP will be useless for 3GPP application. S6a does not represent t=
he whole use cases in 3GPP and at least two operators think that they will =
use the concept of Realm-based report in their own network.
And even from your side, I understand that you consider useless in some cas=
es this AVP but you don't really challenge the fact that the presence of th=
is AVP in any report would cause an issue.

Based on this status, my preferred approach is the one proposed below.

Now, if there is strong concern about this AVP we can revert this decision =
but:
1/ there is no reason not to accept this working assumption
2/ moving back this AVP from required to optional will not fundamentally im=
pact the solution.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_26C84DFD55BC3040A45BF70926E55F2587C3E707SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Lionel,=



 =
;


You didn&#=
8217;t answer me why you decide to propose a way not preferred by majority =
companies. I have strong concern on it. And for the 2/, we are not
 reverting anything, it is optional in the existing draft from the beginnin=
g.


 =
;


Thanks if =
we can conclude on this issue and move on.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Wednesday, March 26, 2014 4:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


Except you=
r point of view that I respect, I haven't read anyone saying that they cann=
ot accept to rely on a required AVP. And it is not yet confirmed
 that the AVP will be useless for 3GPP application. S6a does not represent =
the whole use cases in 3GPP and at least two operators think that they will=
 use the concept of Realm-based report in their own network.


And even f=
rom your side, I understand that you consider useless in some cases this AV=
P but you don't really challenge the fact that the presence
 of this AVP in any report would cause an issue.


 =
;


Based on t=
his status, my preferred approach is the one proposed below.


 =
;


Now, if th=
ere is strong concern about this AVP we can revert this decision but:<=
/o:p>


1/ there i=
s no reason not to accept this working assumption


2/ moving =
back this AVP from required to optional will not fundamentally impact the s=
olution.


 =
;


Regards,


 =
;


Lionel


 =
;






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 09:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.<=
o:p>


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



As chair and temporary doc shepherd,=



 <=
/span>


Please stop this thread for now.


 <=
/span>


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 <=
/span>


Lionel =



 <=
/span>


 <=
/span>


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 <=
/span>






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. =



 


Best Regards,

Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] <=
/span>


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan<=
/pre>

Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 


If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?=



 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.<=
/o:p>


 


I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen=



Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 


I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
span lang=3D"FR">


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de =



lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 

[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,

 


I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?

 


So instead of:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


You would prefer:<=
/pre>

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue =



tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP=



 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 


This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 


--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz

  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new

Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>

 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_____________________________________________________________=
________


____________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


 




 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 =





 =







_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


________________________________________________________________=
_________________________________________________________


 


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.

 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;<=
o:p>


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3E707SZXEMA512MBXchi_--


From nobody Wed Mar 26 02:10: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 A7EC71A02F9 for ; Wed, 26 Mar 2014 02:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 6AGuwSMt54Cc for ; Wed, 26 Mar 2014 02:10:53 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF731A02F5 for ; Wed, 26 Mar 2014 02:10:53 -0700 (PDT)
Received: from localhost ([127.0.0.1]:59296 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WSjr8-0000Om-OW; Wed, 26 Mar 2014 10:10:42 +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: draft-docdt-dime-ovli@tools.ietf.org, lionel.morand@orange-ftgroup.com
X-Trac-Project: dime
Date: Wed, 26 Mar 2014 09:10:42 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/56#comment:1
Message-ID: <077.b74f7acbd1557b6879aeaeb2acd9d699@trac.tools.ietf.org>
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org>
X-Trac-Ticket-ID: 56
In-Reply-To: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, lionel.morand@orange-ftgroup.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ULhSWsQrASp9s82sH4gP6A6v8II
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #56 (draft-docdt-dime-ovli): Bad Description of Overload Control State
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: Wed, 26 Mar 2014 09:10:55 -0000

#56: Bad Description of Overload Control State

Changes (by lionel.morand@orange-ftgroup.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 The following text has been agreed (with "OCS" added in the acronym
 section):

     5.5.1.  Overload Control State (OCS)

     5.5.1.1   Overload Control States for reacting nodes

     A reacting node 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
 towards
       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 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
     following information:
     - Sequence number (as reveived in OC-OLR)
     - Time of expiry  (deviated from validity duration as received in OC-
 OLR
       and time of reception)
     - Selected Abatement Algorithm (as received in OC-Supported-Features)
     - Algorithm specific input data (as received within OC-OLR, e.g.
       Reduction Percentage for Loss)


     5.5.1.2   Overload Control States for reporting nodes

     A reporting node maintains per supported Diameter application and per
     supported (and eventually selected) Abatement Algorithm an Overload
     Control State.

     An Overload Control State may be identified by the pair of
 Application-Id
     and supported Abatement Algorithm.

     The Overload Control State for a given pair of Application and
 Abatement
     Algorithm could include the information:
     - Sequence number
     - Validity Duration and Expiry Time
     - Algorithm specific input data (e.g. Reduction Percentage for Loss)


     5.5.1.3  Maintaining Overload Control States

     Reacting nodes create a host-type OCS identified by OCS-Id = (app-id
 ,host-id) when receiving
     an answer message of application app-id containing an Orig-Host of
 host-id and a
     host-type OC-OLR AVP unless such host-type OCS already exists.

     Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id
 ,realm-id) when receiving
     an answer message of application app-id containing an Orig-Realm of
 realm-id and a
     realm-type OC-OLR AVP unless such realm type OCS already exists.

     Reacting nodes delete an OCS when it expires (i.e. when current time
     minus reception time is greater than validity duration).

     Reacting nodes update the host-type OCS identified by OCS-Id = (app-id
 ,host-id) when
     receiving an answer message of application app-id containing an Orig-
 Host of
     host-id and a host-type OC-OLR AVP with a sequence number higher than
 the
     stored sequence number.

     Reacting nodes update the realm-type OCS identified by OCS-Id = (app-
 id,realm-id) when
     receiving an answer message of application app-id containing an Orig-
 Realm of
     realm-id and a realm-type OC-OLR AVP with a sequence number higher
 than the
     stored sequence number.

     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when
 receiving a
     request of application app-id containing an OC-Supported-Features AVP
     indicating support of the Abatement Algorithm Alg (which the reporting
     node selects) while being overloaded, unless such OCS already exists.

     Reporting nodes delete an OCS when it expires.

     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg)
 when they detect the
     need to modify the requested amount of application app-id traffic
 reduction.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ulrich.wiehe@nsn.com   |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  major        |   Milestone:
Component:  draft-       |     Version:
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Wed Mar 26 02:19:28 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 5BA071A02ED for ; Wed, 26 Mar 2014 02:19:26 -0700 (PDT)
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 E3BqO963lW6W for ; Wed, 26 Mar 2014 02:19:17 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3B21A010C for ; Wed, 26 Mar 2014 02:19:15 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id B2EC31B841D; Wed, 26 Mar 2014 10:19:13 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 7C671158059; Wed, 26 Mar 2014 10:19:13 +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; Wed, 26 Mar 2014 10:19:12 +0100
From: 
To: "Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQNKav1Yd2xqUyLNClmxsrsL5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q//+EAID//3VhAP/+41iA
Date: Wed, 26 Mar 2014 09:19:12 +0000
Message-ID: <1369_1395825553_53329B91_1369_16430_1_6B7134B31289DC4FAF731D844122B36E51C825@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <7077_1392216348_52FB891B_7077_4146_1_6B7134B31289DC4FAF731D844122B36E49E1A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>   <546C1F19-2B53-4054-9C26-DDE6D0DF3C9F@nostrum.com> <087A34937E64E74E848732CFF8354B92097840F1@ESESSMB101.ericsson.se>  <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <11539_1395822697_53329069_11539_6077_1_6B7134B31289DC4FAF731D844122B36E51C523@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E707@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E707@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.2]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51C825PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.233016
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Lo_CNUpBTB4VvSDozEYkOkFMnNo
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 09:19:26 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51C825PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Susan,

I answered. You are not yet appointed as spokeswoman of the "majority of th=
e companies" :)
And my comment is only based on what I have seen on the reflector.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:55
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

You didn't answer me why you decide to propose a way not preferred by major=
ity companies. I have strong concern on it. And for the 2/, we are not reve=
rting anything, it is optional in the existing draft from the beginning.

Thanks if we can conclude on this issue and move on.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 4:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Except your point of view that I respect, I haven't read anyone saying that=
 they cannot accept to rely on a required AVP. And it is not yet confirmed =
that the AVP will be useless for 3GPP application. S6a does not represent t=
he whole use cases in 3GPP and at least two operators think that they will =
use the concept of Realm-based report in their own network.
And even from your side, I understand that you consider useless in some cas=
es this AVP but you don't really challenge the fact that the presence of th=
is AVP in any report would cause an issue.

Based on this status, my preferred approach is the one proposed below.

Now, if there is strong concern about this AVP we can revert this decision =
but:
1/ there is no reason not to accept this working assumption
2/ moving back this AVP from required to optional will not fundamentally im=
pact the solution.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E51C825PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Susan,


 <=
/p>

I answered=
. You are not yet appointed as spokeswoman of the "majority of the com=
panies"
J


And my com=
ment is only based on what I have seen on the reflector.<=
/p>

 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@h=
uawei.com]


Envoy=E9 : mercredi 26 mars 2014 09:55

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,=



 =
;


You didn&#=
8217;t answer me why you decide to propose a way not preferred by majority =
companies. I have strong concern on it. And for the 2/, we are not
 reverting anything, it is optional in the existing draft from the beginnin=
g.


 =
;


Thanks if =
we can conclude on this issue and move on.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Wednesday, March 26, 2014 4:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 <=
/p>

Except you=
r point of view that I respect, I haven't read anyone saying that they cann=
ot accept to rely on a required AVP. And it is not yet confirmed
 that the AVP will be useless for 3GPP application. S6a does not represent =
the whole use cases in 3GPP and at least two operators think that they will=
 use the concept of Realm-based report in their own network.


And even f=
rom your side, I understand that you consider useless in some cases this AV=
P but you don't really challenge the fact that the presence
 of this AVP in any report would cause an issue.


 =
;


Based on t=
his status, my preferred approach is the one proposed below.


 =
;


Now, if th=
ere is strong concern about this AVP we can revert this decision but:<=
/o:p>


1/ there i=
s no reason not to accept this working assumption


2/ moving =
back this AVP from required to optional will not fundamentally impact the s=
olution.


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 09:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,=



 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/o:p>




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 =



From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:<=
/pre>

 =



Hi,


 =



How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 =



If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 =



Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?


 =



- Jouni


 =



 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 =



 


Hello all,


 =



I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 =



I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 =



Best regards


/MCruz


 =



-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13<=
/pre>

To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 =



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 =



I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 =



- Jouni


 =



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 =



Hi Mcruz


 =



The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
o:p>


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 =



Best regards


 =



JJacques


 =



 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 


lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



Hi Maria Cruz,


 =



I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?


 =



So instead of:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



You would prefer:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



And I'm fine with this proposal.


 =



Cheers,


 =



Lionel


 =



-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



#54: OC-Report-Type as mandatory AVP


 =



Now in chapter 4.6:


 =



 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 =



This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 =



--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz


  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new


Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 =



Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>


 =



_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 =



_____________________________________________________________=
________


____________________________________________________


 =



Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 =



This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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


 =



 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 




 






_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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.


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 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_6B7134B31289DC4FAF731D844122B36E51C825PEXCVZYM13corpora_--


From nobody Wed Mar 26 04:17:47 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 206511A031D for ; Wed, 26 Mar 2014 04:17:33 -0700 (PDT)
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 IBoUEFvMDLae for ; Wed, 26 Mar 2014 04:17:20 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 885241A0302 for ; Wed, 26 Mar 2014 04:17:19 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2QBHENG022332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Mar 2014 06:17:16 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2QBHD9g017240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 12:17:14 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 12:17:14 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPQsn+hW8mxnR4ZUW/UfMU7zBoKJrvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg///4Z4AAAQkrAAAA/LoAAAD6fYAAAM0KgAAA3LAAAAC9sYAAAFiDgAAAPkmAAAA/7QAAABmiAAAC726w
Date: Wed, 26 Mar 2014 11:17:13 +0000
Message-ID: 
References: <18368_1395827838_5332A47E_18368_1278_1_6B7134B31289DC4FAF731D844122B36E51C99F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151D2573@DEMUMBX014.nsn-intra.net> <29440_1395828439_5332A6D7_29440_3303_1_6B7134B31289DC4FAF731D844122B36E51CA17@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <29440_1395828439_5332A6D7_29440_3303_1_6B7134B31289DC4FAF731D844122B36E51CA17@PEXCVZYM13.corporate.adroot.infra.ftgroup>
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_E194C2E18676714DACA9C3A2516265D20267A6FAFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Nkc7a3L1SmmPlidqXQHOjUvUBIk
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 11:17:33 -0000

--_000_E194C2E18676714DACA9C3A2516265D20267A6FAFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

We had an initial   discussion when writing the  01 draft which  resulted i=
n a non mandatory  AVP and a default value.
Then a ticket was produced to propose a mandatory AVP ; the author has a fu=
ll right to produce such a ticket

People have then indicated their preference, and we were several (including=
 me)  in favor to keep the draft  as it is, and some other expressed their =
preference for a mandatory AVP.
What is a bit surprising is how   the working assumption has moved from non=
 mandatory AVP to mandatory AVP?

I also agree that a decision should be taken now on this topic, but  could =
it not be those who have a preference for the mandatory AVP, to finally say=
 that the existing text  is acceptable or do they have a so strong concern =
to not keep the existing wording draft (I am not aware of such a concern), =
as Suzan has to keep the existing wording.

Best regards

JJacques

De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Envoy=E9 : mercredi 26 mars 2014 11:07
=C0 : Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; TROTTIN, JEAN-=
JACQUES (JEAN-JACQUES)
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I think that you could say that you are OK with the working assumption for =
now.
But you are right. Let see if Susan will react again :)

Lionel

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : mercredi 26 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I did so on 24.03.2014 17:30
Should I do again? (ignoring your request to stop the thread)

From: ext lionel.morand@orange.com [mailto=
:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 10:57 AM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; ext TROTTIN, JEA=
N-JACQUES (JEAN-JACQUES)
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Thank you for your answer.

Please use the wg mailing list to express your view on this issue.

Lionel

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : mercredi 26 mars 2014 10:50
=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

I have a slight preference in favour of Susan's proposal (as indicated in t=
he mail sent on 24.03.2014 17:30) but can accept your proposal.

I'm in favour of stopping this thread as you requested.

Best regards
Ulrich

From: ext lionel.morand@orange.com [mailto=
:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 10:40 AM
To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); ext TROTTIN, JEA=
N-JACQUES (JEAN-JACQUES)
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

I don't want to block anyone but we need to move forward at least for publi=
cation of the v02.

If you can accept my proposal, please say it.
If you cannot accept the proposed working assumption, please say it. And if=
 it is, please indicate what would be the technical issue that would cause =
implementation problem.

But don't let Susan speaking on behalf of you.

Regards,

lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com
Envoy=E9 : mercredi 26 mars 2014 10:19
=C0 : Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I answered. You are not yet appointed as spokeswoman of the "majority of th=
e companies" :)
And my comment is only based on what I have seen on the reflector.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:55
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

You didn't answer me why you decide to propose a way not preferred by major=
ity companies. I have strong concern on it. And for the 2/, we are not reve=
rting anything, it is optional in the existing draft from the beginning.

Thanks if we can conclude on this issue and move on.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 4:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Except your point of view that I respect, I haven't read anyone saying that=
 they cannot accept to rely on a required AVP. And it is not yet confirmed =
that the AVP will be useless for 3GPP application. S6a does not represent t=
he whole use cases in 3GPP and at least two operators think that they will =
use the concept of Realm-based report in their own network.
And even from your side, I understand that you consider useless in some cas=
es this AVP but you don't really challenge the fact that the presence of th=
is AVP in any report would cause an issue.

Based on this status, my preferred approach is the one proposed below.

Now, if there is strong concern about this AVP we can revert this decision =
but:
1/ there is no reason not to accept this working assumption
2/ moving back this AVP from required to optional will not fundamentally im=
pact the solution.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_E194C2E18676714DACA9C3A2516265D20267A6FAFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

We had an initial  &=
nbsp;discussion when writing the  01 draft which  resulted in a n=
on mandatory  AVP and a default value.


Then a ticket was produce=
d to propose a mandatory AVP ; the author has a full right to produce such =
a ticket


 <=
/p>

People have then indicate=
d their preference, and we were several (including me)  in favor to ke=
ep the draft  as it is, and some other expressed their preference
 for a mandatory AVP. 


What is a bit surprising =
is how   the working assumption has moved from non mandatory AVP to ma=
ndatory AVP?


 <=
/p>

I also agree that a decis=
ion should be taken now on this topic, but  could it not be those who =
have a preference for the mandatory AVP, to finally say that
 the existing text  is acceptable or do they have a so strong concern =
to not keep the existing wording draft (I am not aware of such a concern), =
as Suzan has to keep the existing wording.


 <=
/p>

Best regards<=
o:p>


 


JJacques &nbs=
p;    


 






De =
: lionel.morand@orange.=
com [mailto:lionel.morand@orange.com]


Envoy=E9 : mercredi 26 mars 2014 11:07

=C0 : Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; TR=
OTTIN, JEAN-JACQUES (JEAN-JACQUES)

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


I think that you could sa=
y that you are OK with the working assumption for now.

But you are right. Let se=
e if Susan will react again
J


 <=
/p>

Lionel=



 =







De =
: Wiehe, Ulrich (NSN - =
DE/Munich) [mailto:ulrich.wiehe@nsn=
.com]


Envoy=E9 : mercredi 26 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN,=
 JEAN-JACQUES (JEAN-JACQUES)

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


I did so on
24.03.2014 17:30


Should I do again? (ignor=
ing your request to stop the thread)


 <=
/p>





From: ext
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 10:57 AM

To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; ext TROTT=
IN, JEAN-JACQUES (JEAN-JACQUES)

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Thank you for your answer=
.


 <=
/p>

Please use the wg mailing=
 list to express your view on this issue.


 <=
/p>

Lionel=



 =







De =
: Wiehe, Ulrich (NSN - =
DE/Munich) [mailto:ulrich.wiehe@nsn=
.com]


Envoy=E9 : mercredi 26 mars 2014 10:50

=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN,=
 JEAN-JACQUES (JEAN-JACQUES)

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hi Lionel,


 =



I have a slight preferenc=
e in favour of Susan’s proposal (as indicated in the mail sent on 24.=
03.2014 17:30) but can accept your proposal.


 <=
/p>

I’m in favour of st=
opping this thread as you requested.


 <=
/p>

Best regards<=
/o:p>


Ulrich<=
/p>

 <=
/p>





From: ext
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 10:40 AM

To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); ext TROTT=
IN, JEAN-JACQUES (JEAN-JACQUES)

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi,


 <=
/p>

I don't want to block any=
one but we need to move forward at least for publication of the v02.=



 <=
/p>

If you can accept my prop=
osal, please say it.


If you cannot accept the =
proposed working assumption, please say it. And if it is, please indicate w=
hat would be the technical issue that would cause implementation
 problem.


 <=
/p>

But don't let Susan speak=
ing on behalf of you.


 <=
/p>

Regards,


 =



lionel=



 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de lionel.mor=
and@orange.com

Envoy=E9 : mercredi 26 mars 2014 10:19

=C0 : Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hi Susan,


 <=
/p>

I answered. You are not y=
et appointed as spokeswoman of the "majority of the companies"
J


And my comment is only ba=
sed on what I have seen on the reflector.


 <=
/p>

Regards,


 =



Lionel=



 =







De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 09:55

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hi Lionel,


 <=
/p>

You didn’t answer m=
e why you decide to propose a way not preferred by majority companies. I ha=
ve strong concern on it. And for the 2/, we are not reverting
 anything, it is optional in the existing draft from the beginning.<=
o:p>


 <=
/p>

Thanks if we can conclude=
 on this issue and move on.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 4:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,


 <=
/p>

Except your point of view=
 that I respect, I haven't read anyone saying that they cannot accept to re=
ly on a required AVP. And it is not yet confirmed that the
 AVP will be useless for 3GPP application. S6a does not represent the whole=
 use cases in 3GPP and at least two operators think that they will use the =
concept of Realm-based report in their own network.


And even from your side, =
I understand that you consider useless in some cases this AVP but you don't=
 really challenge the fact that the presence of this AVP
 in any report would cause an issue.


 <=
/p>

Based on this status, my =
preferred approach is the one proposed below.


 <=
/p>

Now, if there is strong c=
oncern about this AVP we can revert this decision but:

1/ there is no reason not=
 to accept this working assumption


2/ moving back this AVP f=
rom required to optional will not fundamentally impact the solution.=



 <=
/p>

Regards,


 =



Lionel=



 =







De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 09:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lionel,=



 <=
/p>

Thanks for your reply.


 <=
/p>

It is clear that majority=
 companies involved in the discussion prefer to not have this AVP as mandat=
ory. And Steve is ok with it as it is, and thus everyone
 is ok with it as optional. I’m wondering why you choose another way =
forward, and don’t take opinion from majority companies into account,=
 which is strange for me.



 <=
/p>

We talked much about it, =
and in some major cases, this AVP is useless. If needed, anyway an optional=
 AVP has to be present, I don’t see any problem with it.
 We did a lot like this in 3GPP spec. I don’t understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.


 <=
/p>

Best Regards,=



Susan

 <=
/p>

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,


 <=
/p>

I do care about comments =
from other but we need to move on.


 <=
/p>

My decision is based on t=
he following: from a technical point of view, there is no issue if we defin=
e this AVP as required. From a protocol aspect, it is cleaner
 as a report ALWAYS applies to a given type. Default value was considered a=
s sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggered this issu=
e) and myself.


 <=
/p>

Now, about the process, a=
 100% is not required to move forward. As it is not possible to get consens=
us on this issue, I use my prerogative to pick one solution,
 the one that seems to be the best solution at this stage, to be able to cl=
ose the discussion at this stage and produce the draft that we need.=



 <=
/p>

After, it is always possi=
ble to challenge again the content of the draft if there is still concern.<=
/span>


 <=
/p>

Benoit, the Area Director=
, is copied. It is not a putsch. Just administrative way agreed within IETF=
 to be able to move forward a WG draft, which is the ultimate
 goal of everyone I think.


 <=
/p>

Regards,


 <=
/p>

Lionel.=



 <=
/p>





De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org=


Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lionel,=



 <=
/p>

Further clarification:


 <=
/p>

I don’t agree with =
this, not ok to everyone as you said.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lionel,=



 <=
/p>

I don’t understand =
it.


 <=
/p>

Please clarify if you car=
e about other people’s comments.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,

 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (even if useless =
in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9crit =
:


 






Hello Steve,<=
/o:p>


 <=
/p>

Thanks for clarifying the=
 IETF procedure. I’m not familiar with it, while I know the draft is =
mainly for 3GPP use, that’s why we 3GPP delegates are deeply involved
 in this specific discussion. If most of 3GPP people think it is not so nee=
ded I couldn’t understand why it shall be mandatory.


 <=
/p>

From technical point of v=
iew, in the case realm based report type is not needed, nothing wrong witho=
ut this AVP, and even better and cleaner.


 <=
/p>

And you ever said you hav=
e preference but ok with either way forward, i.e., make it mandatory or opt=
ional. Then let’s move on with the draft as it is on this
 point, if you agree. 


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:<=
/o:p>






Hi Steve,


 <=
/p>

As I know, majority compa=
nies expressed preference to keep the AVP as optional and keep the texts as=
 they are. You have preference to have it explicitly but
 ok with either way. That’s how I assumed we reached consensus.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:<=
/o:p>






H=
ello Jouni,


&=
nbsp;


I=
 assume we had a lot of discussion on this and reached consensus to keep it=
 as it is in the draft. 


&=
nbsp;


B=
est Regards,


S=
usan


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: Jouni Korhonen [mailto:jouni=
.nospam@gmail.com] 


S=
ent: Saturday, March 22, 2014 10:38 AM


T=
o: Steve Donovan


C=
c: dime@ietf.org

S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


&=
nbsp;


&=
nbsp;


L=
ets have it explicit then. Use '<' and '>' to make the position fixed=
.


&=
nbsp;


-=
 Jouni


&=
nbsp;


O=
n Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

&=
nbsp;




I=
'm ok with either direction but generally lean toward being explicit.


&=
nbsp;


D=
o we have other opinions?  


&=
nbsp;


S=
teve


O=
n 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




H=
ello,


I=
 think the agreement tendency is the contrary: OC-Report-Type is not requir=
ed, while default value is Host. i.e. it will remain as it is now in the dr=
aft.


T=
his may be of some advantage for some applications that may only use Host, =
as long as they may never generate Realm reports.


I=
f there is consensus on this, I will go with this.


B=
est regards


/=
MCruz


 =



F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47=



T=
o: dime@ietf.org

S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 =



A=
ll,


&=
nbsp;


D=
o we have consensus that the OC-Report-Type AVP is required?


&=
nbsp;


I=
f so then one change would be as indicated in the syntax definition propose=
d by Lionel.  We would also remove wording on the default value.


&=
nbsp;


J=
ouni,


&=
nbsp;


H=
ow do we indicate a fixed position for an AVP?  

&=
nbsp;


I=
 presonally don't see this as critical but we can add this requirement if t=
here is consensus.


&=
nbsp;


R=
egards,


&=
nbsp;


S=
teve


&=
nbsp;


O=
n 2/28/14 10:27 AM, Jouni Korhonen wrote:


 =



H=
i,


 =



H=
ow having the AVP could be less error prone if it has a default 


v=
alue and the receiver knows exactly how to proceed when the AVP is <=
o:p>


n=
ot present?


 =



I=
f a node does not include it when it should, the implementation is <=
o:p>


b=
roken. Wouldn't a broken node be able to put wrong report type into =



t=
he AVP even if the AVP is mandatory?


 =



A=
nyway, if it is my statement keeping issue #54 still open, consider =



i=
t resolved from my side. I am OK making the OC-Report-Type AVP as 


r=
equired/mandatory AVP. Should we also consider it having a fixed 


p=
osition just after the OC-Sequence-Number AVP as well since it is 


g=
oing to in every OC-OLR?


 =



-=
 Jouni


 =



&=
nbsp;


&=
nbsp;


O=
n Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> w=
rote:


 =



&=
nbsp;


H=
ello all,


 =



I=
 understand JJ point of view, but I still tend to prefer to make it mandato=
ry, since I think this is less error-prone, since the only node that knows =
the requested Report-Type is the reporting, if for any reason a reporting i=
s omitting it (since it is optional), it will be always interpreted as HOST=
, but this type may be wrong.


 =



I=
 think DEFAULT values should never be error-prone, but used in "genera=
l cases", as a simplification, like e.g. a default for the Validity-Du=
ration. Default Validity-Duration will never be an "error", it co=
uld be not the best value (compared with another value perfectly tuned to r=
eporting node overload situation) but never the use of a Default value shou=
ld lead to an erroneous behavior.


 =



B=
est regards


/=
MCruz


 =



-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


T=
o: Jouni Korhonen


C=
c: dime@ietf.org

S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 =



I=
 actually prefer making it mandatory. The cost of adding it is trivial--eve=
n more so for a reporting node that only supports the default. The value of=
 having it is less opportunity for interop errors.


 =



O=
n Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



&=
nbsp;


A=
gree that it is a small optimization, which I put there because at <=
o:p>


t=
he beginning there seemed to be a lot of worry on every extra AVP 


;=
-)


 =



I=
 prefer having the AVP optional but with a default value just like <=
o:p>


i=
t is now. We have the same for the reduction percentage and the 


v=
alidity time as well.


 =



-=
 Jouni


 =



O=
n Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)&quo=
t; <jean-jacq=
ues.trottin@alcatel-lucent.com> wrote:


 =



H=
i Mcruz


 =



T=
he current description indicates that when not present the OLR is of type H=
ost, which was fine for me and keeps my preference. 

W=
e may have  deployments where Realm OLR is not used, or where statisti=
cally the HOST type is the most frequent, so to have the grouped OLR-AVP co=
ntaining a minimum of AVPs minimizes parsing. I agree it is a small optimiz=
ation.


 =



B=
est regards


 =



J=
Jacques


 =



&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de=
 


<=
a href=3D"mailto:lionel.morand@orange.com">lionel.morand@=
orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15=
:46 =C0 :


<=
a href=3D"mailto:dime@ietf.org">dime@ietf.org<=
/span>; maria.cruz.bartolome@ericsson.com Objet =
: Re: [Dime] 


[=
dime] #54: OC-Report-Type as mandatory AVP


 =



H=
i Maria Cruz,


 =



I=
'm assuming that you mean "required" instead of "mandatory&q=
uot;, right?


 =



S=
o instead of:


 =



O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          [ OC-Report-Typ=
e ]


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



 =



Y=
ou would prefer:


 =



O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          { OC-Report-Typ=
e }


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



 =



A=
nd I'm fine with this proposal.


 =



Cheers,


 


Lionel


 


-----Message d'origine-----<=
/span>


De : DiME [mailto:dime-bounces@ietf.org] De la part de=
 dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :=



<=
a href=3D"mailto:maria.cruz.bartolome@ericsson.com">maria=
.cruz.bartolome@ericsson.com Cc : dime@ietf.org Ob=
jet : [Dime] 


[=
dime] #54: OC-Report-Type as mandatory AVP


 =



#=
54: OC-Report-Type as mandatory AVP


 =



N=
ow in chapter 4.6:


 =



&=
nbsp;The default value of the OC-Report-Type AVP is 0 (i.e. the host  =



r=
eport).


 =



T=
his AVP is always required, right? Then, I think it is more precise that&nb=
sp; we define this AVP as mandatory.


 =



-=
-


-=
----------------------------------------------+---------------------


-=
----------------------------------------------+---

-=
----------------------------------------------+---

R=
eporter:  maria.c=
ruz.bartolome@ericsson.com  |      Owner:=
  MCruz


&=
nbsp; Type:  defect         &n=
bsp;            =
;       |  Bartolom=E9<=
/o:p>


P=
riority:  major         &=
nbsp;           &nbs=
p;        |     Stat=
us:  new


C=
omponent:  draft-docdt-dime-ovli      &n=
bsp;       |  Milestone:


S=
everity:  Active WG Document       =
          |    =
Version:  1.0


&=
nbsp;           &nbs=
p;            &=
nbsp;            &nb=
sp;     |   Keywords:<=
/pre>

-=
----------------------------------------------+---------------------


-=
----------------------------------------------+---

-=
----------------------------------------------+---

 =



T=
icket URL: &l=
t;http://trac.tools.ietf.org/wg/dime/trac/ticket/54>


dime <http://tools.ietf.org/wg/dime/>


 


_______________________________________________


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, ex=
ploites ou copies sans autorisation. Si vous avez recu ce message par erreu=
r, 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 falsif=
ie. Merci.


 =



T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law; they 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.


 =



_=
______________________________________________


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


_=
______________________________________________


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


 =



_=
______________________________________________


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


 =



_=
______________________________________________


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


 =



_=
______________________________________________


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


 =



_=
______________________________________________


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;


&=
nbsp;


&=
nbsp;




 




 






________________________________________________________________=
_________________________________________________________


 


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.


Thank you.


________________________________________________________________=
_________________________________________________________


 


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.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






--_000_E194C2E18676714DACA9C3A2516265D20267A6FAFR712WXCHMBA12z_--


From nobody Wed Mar 26 04:26:18 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 53D351A019C for ; Wed, 26 Mar 2014 04:26:16 -0700 (PDT)
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 3PCKgv3b0yKM for ; Wed, 26 Mar 2014 04:26:04 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id BE23E1A0181 for ; Wed, 26 Mar 2014 04:26:02 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-c0-5332b94871ed
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AB.43.10875.849B2335; Wed, 26 Mar 2014 12:26:00 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0387.000; Wed, 26 Mar 2014 12:25:59 +0100
From: Maria Cruz Bartolome 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPKdHmQtBV/d0cbEW2/a46j08/xprvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q//+EAID//3VhAP/+41iAgAIv24D//+6/sP//2Z1w//+JwQD//xK1AP/+EeGA//wQ56A=
Date: Wed, 26 Mar 2014 11:25:59 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097A0C86@ESESSMB101.ericsson.se>
References: <18368_1395827838_5332A47E_18368_1278_1_6B7134B31289DC4FAF731D844122B36E51C99F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151D2573@DEMUMBX014.nsn-intra.net> <29440_1395828439_5332A6D7_29440_3303_1_6B7134B31289DC4FAF731D844122B36E51CA17@PEXCVZYM13.corporate.adroot.infra.ftgroup> 
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.17]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097A0C86ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyM+Jvja7HTqNgg1czJSzm9q5gs9h0fh2L A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mo4sPUkc8HK3RwVcyd0szQwXj7M3sXIySEh YCLx/OtXNghbTOLCvfVANheHkMAhRonnW9axQjhLGCUuvvkFVsUmYCdx6fQLJhBbRKBcYmvz CRYQW1jAXuLC9dmsEHEHie+zzzOCNIsIbGKUOLTqLliCRUBV4mf7ErAGXgFfiSvbGlkgNsxi llh+fiYjSIJTIFbi6b93YA2MQDd9P7UGbBuzgLjErSfzmSBuFZBYsuc8M4QtKvHy8T+geg4g W1Fieb8cRHm+xIfWv8wQuwQlTs58wjKBUWQWkkmzkJTNQlIGEdeTuDF1ChuErS2xbOFrZghb V2LGv0MsyOILGNlXMbLnJmbmpJcbbmIExtDBLb91dzCeOidyiFGag0VJnPfDW+cgIYH0xJLU 7NTUgtSi+KLSnNTiQ4xMHJxSDYwddU8uB/cmOCcELKpNcJytc5fDqsAlb77Q8y9lKsedXqqt 3rmjZdWegL0xAXG7fTy1a965bYuUzHP6/Ltxf6b5kc1HFJ4pK7mdcFq558fPgzffLpo56/LT NXUncuVk1/q8Nspe5VaU7PfM/25PxIULIruV92Q+civP9vv5ad52rbVyz3ZPEX6jxFKckWio xVxUnAgAlPG4J28CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QgEVHyOJMfdj9yhF4MeUehlExOU
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 11:26:16 -0000

--_000_087A34937E64E74E848732CFF8354B92097A0C86ESESSMB101erics_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello,
I can accept both proposals as mentioned before.
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Sent: mi=E9rcoles, 26 de marzo de 2014 12:17
To: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi

We had an initial   discussion when writing the  01 draft which  resulted i=
n a non mandatory  AVP and a default value.
Then a ticket was produced to propose a mandatory AVP ; the author has a fu=
ll right to produce such a ticket

People have then indicated their preference, and we were several (including=
 me)  in favor to keep the draft  as it is, and some other expressed their =
preference for a mandatory AVP.
What is a bit surprising is how   the working assumption has moved from non=
 mandatory AVP to mandatory AVP?

I also agree that a decision should be taken now on this topic, but  could =
it not be those who have a preference for the mandatory AVP, to finally say=
 that the existing text  is acceptable or do they have a so strong concern =
to not keep the existing wording draft (I am not aware of such a concern), =
as Suzan has to keep the existing wording.

Best regards

JJacques

De : lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Envoy=E9 : mercredi 26 mars 2014 11:07
=C0 : Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; TROTTIN, JEAN-=
JACQUES (JEAN-JACQUES)
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I think that you could say that you are OK with the working assumption for =
now.
But you are right. Let see if Susan will react again :)

Lionel

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : mercredi 26 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I did so on 24.03.2014 17:30
Should I do again? (ignoring your request to stop the thread)

From: ext lionel.morand@orange.com [mailto=
:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 10:57 AM
To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; ext TROTTIN, JEA=
N-JACQUES (JEAN-JACQUES)
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Thank you for your answer.

Please use the wg mailing list to express your view on this issue.

Lionel

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : mercredi 26 mars 2014 10:50
=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES)
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

I have a slight preference in favour of Susan's proposal (as indicated in t=
he mail sent on 24.03.2014 17:30) but can accept your proposal.

I'm in favour of stopping this thread as you requested.

Best regards
Ulrich

From: ext lionel.morand@orange.com [mailto=
:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 10:40 AM
To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); ext TROTTIN, JEA=
N-JACQUES (JEAN-JACQUES)
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

I don't want to block anyone but we need to move forward at least for publi=
cation of the v02.

If you can accept my proposal, please say it.
If you cannot accept the proposed working assumption, please say it. And if=
 it is, please indicate what would be the technical issue that would cause =
implementation problem.

But don't let Susan speaking on behalf of you.

Regards,

lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com
Envoy=E9 : mercredi 26 mars 2014 10:19
=C0 : Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I answered. You are not yet appointed as spokeswoman of the "majority of th=
e companies" :)
And my comment is only based on what I have seen on the reflector.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:55
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

You didn't answer me why you decide to propose a way not preferred by major=
ity companies. I have strong concern on it. And for the 2/, we are not reve=
rting anything, it is optional in the existing draft from the beginning.

Thanks if we can conclude on this issue and move on.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 4:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Except your point of view that I respect, I haven't read anyone saying that=
 they cannot accept to rely on a required AVP. And it is not yet confirmed =
that the AVP will be useless for 3GPP application. S6a does not represent t=
he whole use cases in 3GPP and at least two operators think that they will =
use the concept of Realm-based report in their own network.
And even from your side, I understand that you consider useless in some cas=
es this AVP but you don't really challenge the fact that the presence of th=
is AVP in any report would cause an issue.

Based on this status, my preferred approach is the one proposed below.

Now, if there is strong concern about this AVP we can revert this decision =
but:
1/ there is no reason not to accept this working assumption
2/ moving back this AVP from required to optional will not fundamentally im=
pact the solution.

Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 09:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_087A34937E64E74E848732CFF8354B92097A0C86ESESSMB101erics_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello,<=
/p>

I can accept both proposa=
ls as mentioned before.


Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

Sent: mi=E9rcoles, 26 de marzo de 2014 12:17

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi


 <=
/p>

We had an initial  &=
nbsp;discussion when writing the  01 draft which  resulted in a n=
on mandatory  AVP and a default value.


Then a ticket was produce=
d to propose a mandatory AVP ; the author has a full right to produce such =
a ticket


 <=
/p>

People have then indicate=
d their preference, and we were several (including me)  in favor to ke=
ep the draft  as it is, and some other expressed their preference
 for a mandatory AVP. 


What is a bit surprising =
is how   the working assumption has moved from non mandatory AVP to ma=
ndatory AVP?


 <=
/p>

I also agree that a decis=
ion should be taken now on this topic, but  could it not be those who =
have a preference for the mandatory AVP, to finally say that
 the existing text  is acceptable or do they have a so strong concern =
to not keep the existing wording draft (I am not aware of such a concern), =
as Suzan has to keep the existing wording.


 <=
/p>

Best regards<=
o:p>


 


JJacques &nbs=
p;    


 






De =
: lionel.morand@orange.=
com [mailto:lionel.morand@orange.com]


Envoy=E9 : mercredi 26 mars 2014 11:07

=C0 : Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; TR=
OTTIN, JEAN-JACQUES (JEAN-JACQUES)

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


I think that you could sa=
y that you are OK with the working assumption for now.

But you are right. Let se=
e if Susan will react again
J


 <=
/p>

Lionel=



 =







De =
: Wiehe, Ulrich (NSN - =
DE/Munich) [mailto:ulrich.wiehe@nsn=
.com]


Envoy=E9 : mercredi 26 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN,=
 JEAN-JACQUES (JEAN-JACQUES)

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


I did so on
24.03.2014 17:30


Should I do again? (ignor=
ing your request to stop the thread)


 <=
/p>





From: ext
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 10:57 AM

To: Wiehe, Ulrich (NSN - DE/Munich); Maria Cruz Bartolome; ext TROTT=
IN, JEAN-JACQUES (JEAN-JACQUES)

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Thank you for your answer=
.


 <=
/p>

Please use the wg mailing=
 list to express your view on this issue.


 <=
/p>

Lionel=



 =







De =
: Wiehe, Ulrich (NSN - =
DE/Munich) [mailto:ulrich.wiehe@nsn=
.com]


Envoy=E9 : mercredi 26 mars 2014 10:50

=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; ext TROTTIN,=
 JEAN-JACQUES (JEAN-JACQUES)

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hi Lionel,


 =



I have a slight preferenc=
e in favour of Susan’s proposal (as indicated in the mail sent on 24.=
03.2014 17:30) but can accept your proposal.


 <=
/p>

I’m in favour of st=
opping this thread as you requested.


 <=
/p>

Best regards<=
/o:p>


Ulrich<=
/p>

 <=
/p>





From: ext
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 10:40 AM

To: Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); ext TROTT=
IN, JEAN-JACQUES (JEAN-JACQUES)

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi,


 <=
/p>

I don't want to block any=
one but we need to move forward at least for publication of the v02.=



 <=
/p>

If you can accept my prop=
osal, please say it.


If you cannot accept the =
proposed working assumption, please say it. And if it is, please indicate w=
hat would be the technical issue that would cause implementation
 problem.


 <=
/p>

But don't let Susan speak=
ing on behalf of you.


 <=
/p>

Regards,


 =



lionel=



 =







De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de lionel.mor=
and@orange.com

Envoy=E9 : mercredi 26 mars 2014 10:19

=C0 : Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hi Susan,


 <=
/p>

I answered. You are not y=
et appointed as spokeswoman of the "majority of the companies"
J


And my comment is only ba=
sed on what I have seen on the reflector.


 <=
/p>

Regards,


 =



Lionel=



 =







De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 09:55

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hi Lionel,


 <=
/p>

You didn’t answer m=
e why you decide to propose a way not preferred by majority companies. I ha=
ve strong concern on it. And for the 2/, we are not reverting
 anything, it is optional in the existing draft from the beginning.<=
o:p>


 <=
/p>

Thanks if we can conclude=
 on this issue and move on.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 4:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,


 <=
/p>

Except your point of view=
 that I respect, I haven't read anyone saying that they cannot accept to re=
ly on a required AVP. And it is not yet confirmed that the
 AVP will be useless for 3GPP application. S6a does not represent the whole=
 use cases in 3GPP and at least two operators think that they will use the =
concept of Realm-based report in their own network.


And even from your side, =
I understand that you consider useless in some cases this AVP but you don't=
 really challenge the fact that the presence of this AVP
 in any report would cause an issue.


 <=
/p>

Based on this status, my =
preferred approach is the one proposed below.


 <=
/p>

Now, if there is strong c=
oncern about this AVP we can revert this decision but:

1/ there is no reason not=
 to accept this working assumption


2/ moving back this AVP f=
rom required to optional will not fundamentally impact the solution.=



 <=
/p>

Regards,


 =



Lionel=



 =







De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 09:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lionel,=



 <=
/p>

Thanks for your reply.


 <=
/p>

It is clear that majority=
 companies involved in the discussion prefer to not have this AVP as mandat=
ory. And Steve is ok with it as it is, and thus everyone
 is ok with it as optional. I’m wondering why you choose another way =
forward, and don’t take opinion from majority companies into account,=
 which is strange for me.



 <=
/p>

We talked much about it, =
and in some major cases, this AVP is useless. If needed, anyway an optional=
 AVP has to be present, I don’t see any problem with it.
 We did a lot like this in 3GPP spec. I don’t understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.


 <=
/p>

Best Regards,=



Susan

 <=
/p>

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,


 <=
/p>

I do care about comments =
from other but we need to move on.


 <=
/p>

My decision is based on t=
he following: from a technical point of view, there is no issue if we defin=
e this AVP as required. From a protocol aspect, it is cleaner
 as a report ALWAYS applies to a given type. Default value was considered a=
s sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggered this issu=
e) and myself.


 <=
/p>

Now, about the process, a=
 100% is not required to move forward. As it is not possible to get consens=
us on this issue, I use my prerogative to pick one solution,
 the one that seems to be the best solution at this stage, to be able to cl=
ose the discussion at this stage and produce the draft that we need.=



 <=
/p>

After, it is always possi=
ble to challenge again the content of the draft if there is still concern.<=
/span>


 <=
/p>

Benoit, the Area Director=
, is copied. It is not a putsch. Just administrative way agreed within IETF=
 to be able to move forward a WG draft, which is the ultimate
 goal of everyone I think.


 <=
/p>

Regards,


 <=
/p>

Lionel.=



 <=
/p>





De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org=


Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lionel,=



 <=
/p>

Further clarification:


 <=
/p>

I don’t agree with =
this, not ok to everyone as you said.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lionel,=



 <=
/p>

I don’t understand =
it.


 <=
/p>

Please clarify if you car=
e about other people’s comments.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,

 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (even if useless =
in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9crit =
:


 






Hello Steve,<=
/o:p>


 <=
/p>

Thanks for clarifying the=
 IETF procedure. I’m not familiar with it, while I know the draft is =
mainly for 3GPP use, that’s why we 3GPP delegates are deeply involved
 in this specific discussion. If most of 3GPP people think it is not so nee=
ded I couldn’t understand why it shall be mandatory.


 <=
/p>

From technical point of v=
iew, in the case realm based report type is not needed, nothing wrong witho=
ut this AVP, and even better and cleaner.


 <=
/p>

And you ever said you hav=
e preference but ok with either way forward, i.e., make it mandatory or opt=
ional. Then let’s move on with the draft as it is on this
 point, if you agree. 


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:<=
/o:p>






Hi Steve,


 <=
/p>

As I know, majority compa=
nies expressed preference to keep the AVP as optional and keep the texts as=
 they are. You have preference to have it explicitly but
 ok with either way. That’s how I assumed we reached consensus.


 <=
/p>

Best Regards,=



Susan

 <=
/p>





From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:<=
/o:p>






H=
ello Jouni,


&=
nbsp;


I=
 assume we had a lot of discussion on this and reached consensus to keep it=
 as it is in the draft. 


&=
nbsp;


B=
est Regards,


S=
usan


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: Jouni Korhonen [mailto:jouni=
.nospam@gmail.com] 


S=
ent: Saturday, March 22, 2014 10:38 AM


T=
o: Steve Donovan


C=
c: dime@ietf.org

S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


&=
nbsp;


&=
nbsp;


L=
ets have it explicit then. Use '<' and '>' to make the position fixed=
.


&=
nbsp;


-=
 Jouni


&=
nbsp;


O=
n Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

&=
nbsp;




I=
'm ok with either direction but generally lean toward being explicit.


&=
nbsp;


D=
o we have other opinions?  


&=
nbsp;


S=
teve


O=
n 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




H=
ello,


I=
 think the agreement tendency is the contrary: OC-Report-Type is not requir=
ed, while default value is Host. i.e. it will remain as it is now in the dr=
aft.


T=
his may be of some advantage for some applications that may only use Host, =
as long as they may never generate Realm reports.


I=
f there is consensus on this, I will go with this.


B=
est regards


/=
MCruz


 =



F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47=



T=
o: dime@ietf.org

S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 =



A=
ll,


&=
nbsp;


D=
o we have consensus that the OC-Report-Type AVP is required?


&=
nbsp;


I=
f so then one change would be as indicated in the syntax definition propose=
d by Lionel.  We would also remove wording on the default value.


&=
nbsp;


J=
ouni,


&=
nbsp;


H=
ow do we indicate a fixed position for an AVP?  

&=
nbsp;


I=
 presonally don't see this as critical but we can add this requirement if t=
here is consensus.


&=
nbsp;


R=
egards,


&=
nbsp;


S=
teve


&=
nbsp;


O=
n 2/28/14 10:27 AM, Jouni Korhonen wrote:


 =



H=
i,


 =



H=
ow having the AVP could be less error prone if it has a default 


v=
alue and the receiver knows exactly how to proceed when the AVP is <=
o:p>


n=
ot present?


 =



I=
f a node does not include it when it should, the implementation is <=
o:p>


b=
roken. Wouldn't a broken node be able to put wrong report type into =



t=
he AVP even if the AVP is mandatory?


 =



A=
nyway, if it is my statement keeping issue #54 still open, consider =



i=
t resolved from my side. I am OK making the OC-Report-Type AVP as 


r=
equired/mandatory AVP. Should we also consider it having a fixed 


p=
osition just after the OC-Sequence-Number AVP as well since it is 


g=
oing to in every OC-OLR?


 =



-=
 Jouni


 =



&=
nbsp;


&=
nbsp;


O=
n Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> w=
rote:


 =



&=
nbsp;


H=
ello all,


 =



I=
 understand JJ point of view, but I still tend to prefer to make it mandato=
ry, since I think this is less error-prone, since the only node that knows =
the requested Report-Type is the reporting, if for any reason a reporting i=
s omitting it (since it is optional), it will be always interpreted as HOST=
, but this type may be wrong.


 =



I=
 think DEFAULT values should never be error-prone, but used in "genera=
l cases", as a simplification, like e.g. a default for the Validity-Du=
ration. Default Validity-Duration will never be an "error", it co=
uld be not the best value (compared with another value perfectly tuned to r=
eporting node overload situation) but never the use of a Default value shou=
ld lead to an erroneous behavior.


 =



B=
est regards


/=
MCruz


 =



-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


T=
o: Jouni Korhonen


C=
c: dime@ietf.org

S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/o:p>


 =



I=
 actually prefer making it mandatory. The cost of adding it is trivial--eve=
n more so for a reporting node that only supports the default. The value of=
 having it is less opportunity for interop errors.


 =



O=
n Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



&=
nbsp;


A=
gree that it is a small optimization, which I put there because at <=
o:p>


t=
he beginning there seemed to be a lot of worry on every extra AVP 


;=
-)


 =



I=
 prefer having the AVP optional but with a default value just like <=
o:p>


i=
t is now. We have the same for the reduction percentage and the 


v=
alidity time as well.


 =



-=
 Jouni


 =



O=
n Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)&quo=
t; <jean-jacq=
ues.trottin@alcatel-lucent.com> wrote:


 =



H=
i Mcruz


 =



T=
he current description indicates that when not present the OLR is of type H=
ost, which was fine for me and keeps my preference. 

W=
e may have  deployments where Realm OLR is not used, or where statisti=
cally the HOST type is the most frequent, so to have the grouped OLR-AVP co=
ntaining a minimum of AVPs minimizes parsing. I agree it is a small optimiz=
ation.


 =



B=
est regards


 =



J=
Jacques


 =



&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de=
 


<=
a href=3D"mailto:lionel.morand@orange.com">lionel.morand@=
orange.com Envoy=E9 : mercredi 12 f=E9vrier 2=
014 15:46 =C0 :


<=
a href=3D"mailto:dime@ietf.org">dime@ietf.org<=
/span>; maria.cruz.bartolome@ericsson.com Objet =
: Re: [Dime] 


[=
dime] #54: OC-Report-Type as mandatory AVP


 =



H=
i Maria Cruz,


 =



I=
'm assuming that you mean "required" instead of "mandatory&q=
uot;, right?


 =



S=
o instead of:


 =



O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          [ OC-Report-Typ=
e ]


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



 =



Y=
ou would prefer:


 =



O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          { OC-Report-Typ=
e }


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



 =



A=
nd I'm fine with this proposal.


 =



Cheers,


 


Lionel


 


-----Message d'origine-----<=
/span>


De : DiME [mailto:dime-bounces@ietf.org] De la part de=
 dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :=



<=
a href=3D"mailto:maria.cruz.bartolome@ericsson.com">maria=
.cruz.bartolome@ericsson.com Cc : dime@ietf.org Ob=
jet : [Dime] 


[=
dime] #54: OC-Report-Type as mandatory AVP


 =



#=
54: OC-Report-Type as mandatory AVP


 =



N=
ow in chapter 4.6:


 =



&=
nbsp;The default value of the OC-Report-Type AVP is 0 (i.e. the host  =



r=
eport).


 =



T=
his AVP is always required, right? Then, I think it is more precise that&nb=
sp; we define this AVP as mandatory.


 =



-=
-


-=
----------------------------------------------+---------------------


-=
----------------------------------------------+---

-=
----------------------------------------------+---

R=
eporter:  maria.c=
ruz.bartolome@ericsson.com  |      Owner:=
  MCruz


&=
nbsp; Type:  defect         &n=
bsp;            =
;       |  Bartolom=E9<=
/o:p>


P=
riority:  major         &=
nbsp;           &nbs=
p;        |     Stat=
us:  new


C=
omponent:  draft-docdt-dime-ovli      &n=
bsp;       |  Milestone:


S=
everity:  Active WG Document       =
          |    =
Version:  1.0


&=
nbsp;           &nbs=
p;            &=
nbsp;            &nb=
sp;     |   Keywords:<=
/pre>

-=
----------------------------------------------+---------------------


-=
----------------------------------------------+---

-=
----------------------------------------------+---

 =



T=
icket URL: &l=
t;http://trac.tools.ietf.org/wg/dime/trac/ticket/54>


dime <http://tools.ietf.org/wg/dime/>


 


_______________________________________________


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, ex=
ploites ou copies sans autorisation. Si vous avez recu ce message par erreu=
r, 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 falsif=
ie. Merci.


 =



T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law; they 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.


 =



_=
______________________________________________


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


_=
______________________________________________


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


 =



_=
______________________________________________


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


 =



_=
______________________________________________


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


 =



_=
______________________________________________


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


 =



_=
______________________________________________


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;


&=
nbsp;


&=
nbsp;




 




 






________________________________________________________________=
_________________________________________________________


 


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.


Thank you.


________________________________________________________________=
_________________________________________________________


 


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.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






--_000_087A34937E64E74E848732CFF8354B92097A0C86ESESSMB101erics_--


From nobody Wed Mar 26 04:30: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 904301A0316 for ; Wed, 26 Mar 2014 04:30:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.239
X-Spam-Level: 
X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 B8Xcy2Q2FqT6 for ; Wed, 26 Mar 2014 04:30:41 -0700 (PDT)
Received: from sessmg21.mgmt.ericsson.se (sessmg21.ericsson.net [193.180.251.40]) by ietfa.amsl.com (Postfix) with ESMTP id D77251A019C for ; Wed, 26 Mar 2014 04:30:40 -0700 (PDT)
X-AuditID: c1b4fb28-b7f8e8e000007f0a-73-5332ba5e83dc
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id B9.9D.32522.E5AB2335; Wed, 26 Mar 2014 12:30:38 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.123]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0387.000; Wed, 26 Mar 2014 12:30:38 +0100
From: Maria Cruz Bartolome 
To: Steve Donovan , "dime@ietf.org" 
Thread-Topic: [Dime] Issue #23 - Proposed resolution
Thread-Index: AQHPSGyHo/hRJOjvGke2FwEBr47Q4ZrzPCpA
Date: Wed, 26 Mar 2014 11:30:37 +0000
Message-ID: <087A34937E64E74E848732CFF8354B92097A0CAF@ESESSMB101.ericsson.se>
References: <5331ED2E.4030507@usdonovans.com>
In-Reply-To: <5331ED2E.4030507@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.17]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B92097A0CAFESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+JvjW7cLqNgg0m7DC3m9q5gs9jQxOPA 5LFkyU8mj1Vv+1gDmKK4bFJSczLLUov07RK4Mh7v3sBcsE2/YuKkLuYGxluaXYycHBICJhKL X3ezQ9hiEhfurWcDsYUETjBKzOgs72LkArKXMEo82XqCFSTBJmAncen0CyYQW0TAV+J452kW EFtYwFii+cszqLiJxO2vF5khbCOJG98g6lkEVCWm/4KI8wL1/rh2hBVima7E2r+vwBZzCuhJ 3PzQCVbDCHTQ91NrwHqZBcQlbj2ZzwRxqIDEkj3nmSFsUYmXj/8BzeEAshUllvfLQZTnS0y4 co0FYpWgxMmZT1gmMIrMQjJpFpKyWUjKIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypG yeLU4uLcdCNDvdz03BK91KLM5OLi/Dy94tRNjMDYOrjlt8YOxu5r9ocYpTlYlMR5q2Z2BgkJ pCeWpGanphakFsUXleakFh9iZOLglGpgbP4bGh46O2C5lk7/AZmJpxvfm0gZPQyf4G2Y4rpR 6q1BbqPg3JkxnZdSv7T6FXKHt5+p+RD3OX6CfsCB7/HHf8Sl7ZjluLq11imAad8KQeWtRZHO Tt8fJxYJuYTcXOHasUh7rs1KoVVJp1wTlBcviWNIYAiSWfxg9v3zUbKnL3B4vKn4tu+bEktx RqKhFnNRcSIAZzS6t3sCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/NNVQG2fEr2CbVgk-k74FJowevb8
Subject: Re: [Dime] Issue #23 - Proposed resolution
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: Wed, 26 Mar 2014 11:30:43 -0000

--_000_087A34937E64E74E848732CFF8354B92097A0CAFESESSMB101erics_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve, all,

In my opinion RRR term is misleading.
I think we need to come up with a name that clearly could differentiate fro=
m "Realm".
Then, my proposal is to do not modify that in draft.
If later, finally we consider "all requests to realm" report, then we would=
 need to come up with a better terminology.
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: martes, 25 de marzo de 2014 21:55
To: dime@ietf.org
Subject: [Dime] Issue #23 - Proposed resolution

All,

Given that we do not have consensus on removing Realm-Routed-Request report=
s, I propose that we resolve issue 23 by renaming what is called Realm repo=
rts in the -01 draft to Realm-Routed-Reports in the -02 draft.

I will update the issue with the text changes when I make them, but I will =
do nothing but change the name and make the wording consistent in that Real=
m-Routed-Reports apply to requests sent to the realm that do not have a Des=
tination-Host AVP.

Regards,

Steve

--_000_087A34937E64E74E848732CFF8354B92097A0CAFESESSMB101erics_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Steve, all,


 <=
/p>

In my opinion RRR term is=
 misleading.


I think we need to come u=
p with a name that clearly could differentiate from “Realm”.


Then, my proposal is to d=
o not modify that in draft.


If later, finally we cons=
ider “all requests to realm” report, then we would need to come=
 up with a better terminology.


Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [mailto:dime-bounces@ietf.org]
On Behalf Of Steve Donovan

Sent: martes, 25 de marzo de 2014 21:55

To: dime@ietf.org

Subject: [Dime] Issue #23 - Proposed resolution





 


All,



Given that we do not have consensus on removing Realm-Routed-Request report=
s, I propose that we resolve issue 23 by renaming what is called Realm repo=
rts in the -01 draft to Realm-Routed-Reports in the -02 draft.



I will update the issue with the text changes when I make them, but I will =
do nothing but change the name and make the wording consistent in that Real=
m-Routed-Reports apply to requests sent to the realm that do not have a Des=
tination-Host AVP.



Regards,



Steve






--_000_087A34937E64E74E848732CFF8354B92097A0CAFESESSMB101erics_--


From nobody Wed Mar 26 04:48:04 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 108951A0270 for ; Wed, 26 Mar 2014 04:48:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 4QaOFqWJKsKE for ; Wed, 26 Mar 2014 04:48:00 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA591A01A9 for ; Wed, 26 Mar 2014 04:48:00 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50914 helo=Steves-MacBook-Air-2.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSmJB-0005hl-7E; Wed, 26 Mar 2014 04:47:58 -0700
Message-ID: <5332BE65.5000108@usdonovans.com>
Date: Wed, 26 Mar 2014 06:47:49 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Maria Cruz Bartolome ,  "dime@ietf.org" 
References: <5331ED2E.4030507@usdonovans.com> <087A34937E64E74E848732CFF8354B92097A0CAF@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B92097A0CAF@ESESSMB101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------070800060107050905020906"
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/SCZrf9lGWwXZnJQGcy66dlUJGlg
Subject: Re: [Dime] Issue #23 - Proposed resolution
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: Wed, 26 Mar 2014 11:48:02 -0000

This is a multi-part message in MIME format.
--------------070800060107050905020906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Maria Cruz,

I'm open to other names, please make a suggestion if you don't want RRR.

One of the reasons for the ticket was that the draft itself is currently 
not consistent in describing this report.  In some places it describes 
it as a RRR and in other cases it describes it as a Realm.

Note that this is NOT what we discussed and agreed to in London, but I'm 
ok with leaving the decision on Realm reports to after -02 is published.

Regards,

Steve

On 3/26/14, 6:30 AM, Maria Cruz Bartolome wrote:
>
> Steve, all,
>
> In my opinion RRR term is misleading.
>
> I think we need to come up with a name that clearly could 
> differentiate from "Realm".
>
> Then, my proposal is to do not modify that in draft.
>
> If later, finally we consider "all requests to realm" report, then we 
> would need to come up with a better terminology.
>
> Cheers
>
> /MCruz
>
> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Steve Donovan
> *Sent:* martes, 25 de marzo de 2014 21:55
> *To:* dime@ietf.org
> *Subject:* [Dime] Issue #23 - Proposed resolution
>
> All,
>
> Given that we do not have consensus on removing Realm-Routed-Request 
> reports, I propose that we resolve issue 23 by renaming what is called 
> Realm reports in the -01 draft to Realm-Routed-Reports in the -02 draft.
>
> I will update the issue with the text changes when I make them, but I 
> will do nothing but change the name and make the wording consistent in 
> that Realm-Routed-Reports apply to requests sent to the realm that do 
> not have a Destination-Host AVP.
>
> Regards,
>
> Steve
>


--------------070800060107050905020906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Maria Cruz,

    

    I'm open to other names, please make a suggestion if you don't want
    RRR.

    

    One of the reasons for the ticket was that the draft itself is
    currently not consistent in describing this report.  In some places
    it describes it as a RRR and in other cases it describes it as a
    Realm.

    

    Note that this is NOT what we discussed and agreed to in London, but
    I'm ok with leaving the decision on Realm reports to after -02 is
    published.

    

    Regards,

    

    Steve

    

    
On 3/26/14, 6:30 AM, Maria Cruz
      Bartolome wrote:

    

    

      
      
      
      

        
Steve,
            all,

        
 

        
In
            my opinion RRR term is misleading.

        
I
            think we need to come up with a name that clearly could
            differentiate from “Realm”.

        
Then,
            my proposal is to do not modify that in draft.

        
If
            later, finally we consider “all requests to realm” report,
            then we would need to come up with a better terminology.

        
Cheers

        
/MCruz

        
 

        

          

            
From:
                DiME [mailto:dime-bounces@ietf.org]
                On Behalf Of Steve Donovan

                Sent: martes, 25 de marzo de 2014 21:55

                To: dime@ietf.org

                Subject: [Dime] Issue #23 - Proposed resolution

          

        

        
 

        
All,

          

          Given that we do not have consensus on removing
          Realm-Routed-Request reports, I propose that we resolve issue
          23 by renaming what is called Realm reports in the -01 draft
          to Realm-Routed-Reports in the -02 draft.

          

          I will update the issue with the text changes when I make
          them, but I will do nothing but change the name and make the
          wording consistent in that Realm-Routed-Reports apply to
          requests sent to the realm that do not have a Destination-Host
          AVP.

          

          Regards,

          

          Steve

      

    

    

  


--------------070800060107050905020906--


From nobody Wed Mar 26 04:56:46 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 AC4F21A01B0 for ; Wed, 26 Mar 2014 04:56:42 -0700 (PDT)
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 zE8FS8w9IA5p for ; Wed, 26 Mar 2014 04:56:36 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFA11A01A5 for ; Wed, 26 Mar 2014 04:56:35 -0700 (PDT)
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 s2QBuVnu015570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Mar 2014 06:56:32 -0500 (CDT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2QBuUma014755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 12:56:30 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 12:56:30 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPRRfXQhWaUi5Qi0CrluviFm2KiJrr96eAgAQ/IICAACZLgIAAKEkAgAEezICAACLtgIAAF+QAgAABqQCAAAHCAIAAFKOAgADo84CAAGjMoA==
Date: Wed, 26 Mar 2014 11:56:29 +0000
Message-ID: 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5331B195.9020402@usdonovans.com> <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com>
In-Reply-To: <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.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.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20267A7ABFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/T2B2_NtlWDf--3J0VmfHCYrWE4g
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Wed, 26 Mar 2014 11:56:42 -0000

--_000_E194C2E18676714DACA9C3A2516265D20267A7ABFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

With others, I share Lionel summary on this topic, and the v02 draft should=
 be on this statement. I also agree with  Mcruz, for the meantime to keep t=
he the "realm" report   name as it is in current  draft
Then there can be a ticket about other ways to understand the  realm  repor=
t

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de lionel.morand@orange=
.com
Envoy=E9 : mercredi 26 mars 2014 07:35
=C0 : Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org;=
 Steve Donovan
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports


Hi Steve,



In London, we ended up with the following proposal:



- ONLY two report types

- "Host" that applies when destination-host is present in the request.

- "Realm" that applies to any request sent to a realm, except when a destin=
ation-host is present in the request AND a "Host" applies for this destinat=
ion-host.



About renaming "Realm" as "Realm-Routed-Request", no strong issue as soon a=
s the principle above are kept.



The need for realm-based type that would apply to any request (even if a "H=
ost" exists for a destination-host in the request) was challenged and not r=
etained. Ben was supposed to lock you in a room and to convince you that th=
is last report type was not needed.



Lionel



Envoy=E9 depuis mon Sony Xperia SP d'Orange



Steve Donovan > a=
 =E9crit :


Consensus is obviously a fleeting and temporary thing.

Let us make sure that we are precise in our definitions of the report types=
 we are discussing.

Host report - Applies when the destination-host AVP is present in the reque=
st.
Realm-Routed-Request (RRR) - Applies when there is no destination-host AVP =
in the request.
Realm - Applies to 100% of requests sent to the realm.

These are the definitions used in our discussions in London and in various =
places in our email discussions.

Can we please agree to use these definitions going forward so we are all ta=
lking about the same thing.

Regards,

Steve
On 3/25/14 10:27 AM, lionel.morand@orange.com wrote:
Hi Maria Cruz, All,

In the previous mail, you wrote:

That is, we have two reports, host and realm.
Host applies when Destination_host is present, and then it takes precedence=
 over Realm. If both are present, only Host is applied.
Realm applies when only Destination_realm is present.

And I agree with this statement. But I'm not sure that this is the case dis=
cussed by Ulrich.

Whatever the name of the realm report type, is there an agreement on the de=
scription given above by Maria Cruz and discussed in London?

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoy=E9 : mardi 25 mars 2014 16:21
=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports

Dear all,

I support option 1 a well
Cheers
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN -=
 DE/Munich)
Sent: martes, 25 de marzo de 2014 16:15
To: ext Steve Donovan; dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Steve,
Thank you for this summary.
Please see inline.

Ulrich

From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,

I mean going backwards from where I thought we were after the London meetin=
g.

We are clearly out of sync but hopefully we can fix that.

Here's my understanding of the status of #23 and #55.

Prior to London meeting:

#23 status:
 - Agreement to change the name of existing realm reports to realm-routed-r=
eports (RRR).
this includes agreement to keep the (newly called) realm-routed-rep=
orts
 - Discussions were ongoing as to the need for both realm reports and RRR r=
eports.
I would say "...as to the need for realm reports in addition to rea=
lm-routed-reports" 


#55 status:
  - Agreement on adding Realm reports based on the definition that realm re=
ports apply to all traffic sent to the realm.
This is what I'm missing. The issue has been very briefly discussed=
 under #34 without conclusion. There was no discussion under #55

  - Limited discussion on the interaction between the new realm reports and=
 the existing host and RRR reports.

After London meeting:

#23 status:
  - Tentative agreement in London meeting to remove RRR reports.
What was the technical argument?

  - Ben expressed the strongest concern with this plan.  Steve and Ben took=
 action to discuss and come back with a recommendation.

#55 status:
  - No change

Summary:
  - Tentative consensus reached to move forward with two report types - hos=
t and realm, with realm having the new definition.
What was the technical argument?

Current status:

#23 status:
 - Change the name to RRR
 - Whether or not to remove RRR and revisit later or keep RRR and revisit l=
ater is an open issue.

#55 status:
  - My opinion is that we have at least rough consensus on the need to supp=
ort realm reports.  Others might have a different opinion.
 There was no comment posted to issue #55, also no proposed solutio=
n, so I cannot see where the consensus came from


Summary:
  - I believe we have three options:

   1) Support host and RRR reports
   2) Support host and Realm reports -- This was the tentative plan coming =
out of the London meeting
< Ulrich> There is not even an issue number identifying problems with RRR a=
nd proposing to remove RRR

   3) Support host, RRR and Realm reports
 I support option 1

Regards,

Steve
On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,
I don't think we are going backwards (we may be out of synch though)

Can you please summarize the status of #23 and #55.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 7:38 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ok, we are going backwards on this one.

I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.

I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.

At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.

Steve
On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I do not agree.

We should still have the option
3) support report type 0 (this is called host report) and support of report=
 type 1 (this has been called relam report but people argued it should bett=
er be called realm routed request report).

Whether or not we need in addition to type 0 and type 1 (or as a replacemen=
t of type 1) a realm-no-matter-whether-destination-host-is present-or-not r=
eport   is an open issue (see #55).
There are a lot of open questions  with regard to #55 and I have not seen a=
 conclusion.
Where I have seen a conclusion is issue #34 and that is inline with option =
3).

Unless we conclude on #55, or decide to re-open #34, option 3) is what shou=
ld go in the -02 draft.


Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, March 24, 2014 2:57 PM
To: dime@ietf.org
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Rout=
ed-Reports

Ulrich,
All,

We have two options for the -02 draft.

1) Support Host and Realm as proposed below, removing RRR reports.
2) Support Host, Realm and RRR reports.

The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be added b=
ack in if and when we are convinced of the need.

If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.

I plan to make these updates Wednesday morning, Dallas, Texas time.

Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addressed =
in the -03 draft.

Regards,

Steve
On 3/21/14 4:05 PM, Steve Donovan wrote:
Ulrich,

The discussion should be captured in the minutes to the meeting.  I wasn't =
able to find them posted yet.

Jouni, Lionel, what is the status of the minutes for the meeting?

My reading of emails prior to the London meeting is different from yours.  =
I believe we had come to the conclusion that we needed host and realm (with=
 the definition of realm as outlined below).  We were still discussing the =
need for Realm-Routed-Request reports.

Regards,

Steve
On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

I don't know what happend in London.
Can you please summarize the technical reasons that led to the London agree=
ment.
E-mail discussions prior to London have clearly directed towards a report t=
ype that requests throttling of realm routed request messages (i.e. not con=
taining a destination host) rather than a report type that requests throttl=
ing of messages routed towards a realm (no matter whether they contain a de=
stination host or not).

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Friday, March 21, 2014 3:33 PM
To: dime@ietf.org
Subject: [Dime] Resolution on action to discuss the need for Realm-Routed-R=
eports

All,

Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.

As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:

- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).

- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).

The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.

My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft.

We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is a det=
ermination that RRRs are needed in time to include in the base draft then i=
t can be considered at that time.

Based on this, I propose the following

- Resolution to issue #23 is to remove RRR reports from the document.
- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).
- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).

There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording prio=
r to the -02 draft being submitted.  To this end, I'll open a new issue to =
deal with the need for wording on the interaction.

Regards,

Steve




_______________________________________________

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.


___________________________________________________________________________=
______________________________________________



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_E194C2E18676714DACA9C3A2516265D20267A7ABFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi



 <=
/p>

With others, I share Lion=
el summary on this topic, and the v02 draft should be on this statement. I =
also agree with  Mcruz, for the meantime to keep the the
 “realm” report   name as it is in current  draf=
t 


Then there can be a ticke=
t about other ways to understand the  realm  report



 <=
/p>

Best regards



 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de lionel.morand@orange.com

Envoy=E9 : mercredi 26 mars 2014 07:35

=C0 : Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich); di=
me@ietf.org; Steve Donovan

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


=
Hi Steve,


=
 


=
In London, we ended up with the following proposal:


=
 


=
- ONLY two report types


=
- "Host" that applies when destination-host is present in the req=
uest.


=
- "Realm" that applies to any request sent to a realm, except whe=
n a destination-host is present in the request AND a "Host" appli=
es for this destination-host.


=
 


=
About renaming "Realm" as "Realm-Routed-Request", no st=
rong issue as soon as the principle above are kept.


=
 


=
The need for realm-based type that would apply to any request (even if a &q=
uot;Host" exists for a destination-host in the request) was challenged=
 and not retained. Ben was supposed to lock you in a room and to convince y=
ou that this last report type was not needed.


=
 


=
Lionel 


=
 


=
Envoy=E9 depuis mon Sony Xperia SP d'Orange


=
 


=
Steve Donovan <srdonovan@usd=
onovans.com> a =E9crit :


=
 




Consensus is obviousl=
y a fleeting and temporary thing.



Let us make sure that we are precise in our definitions of the report types=
 we are discussing.



Host report - Applies when the destination-host AVP is present in the reque=
st.

Realm-Routed-Request (RRR) - Applies when there is no destination-host AVP =
in the request.

Realm - Applies to 100% of requests sent to the realm.



These are the definitions used in our discussions in London and in various =
places in our email discussions. 




Can we please agree to use these definitions going forward so we are all ta=
lking about the same thing.



Regards,



Steve




On 3/25/14 10:27 AM, 
lionel.morand@orange.com wrote:








Hi Maria Cruz, All,


 <=
/p>

In the previous mail, you=
 wrote:


 <=
/p>

That is, we have two reports, host and realm.



Host applies when Destination_host is present, and then it takes pre=
cedence over Realm. If both are present, only Host is applied.


Realm applies when only Destination_realm is present.


 <=
/p>

And I agree with this sta=
tement. But I'm not sure that this is the case discussed by Ulrich.<=
o:p>


 <=
/p>

Whatever the name of the =
realm report type, is there an agreement on the description given above by =
Maria Cruz and discussed in London?


 <=
/p>

Regards,


 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 DiME [mailto:dime-bounces@ietf.org]
De la part de Maria Cruz Bartolome

Envoy=E9 : mardi 25 mars 2014 16:21

=C0 : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; 
dime@ietf.org

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


Dear all,


 <=
/p>

I support option 1 a well=



Cheers<=
/p>

/MCruz<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)

Sent: martes, 25 de marzo de 2014 16:15

To: ext Steve Donovan; dime@ietf.or=
g

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Steve,<=
/p>

Thank you for this summar=
y.


Please see inline.=



 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 2:49 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,



I mean going backwards from where I thought we were after the London meetin=
g.



We are clearly out of sync but hopefully we can fix that.



Here's my understanding of the status of #23 and #55.



Prior to London meeting:



#23 status:

 - Agreement to change the name of existing realm reports to realm-rou=
ted-reports (RRR).


<Ulrich>this includes agreement to keep the (newly called) real=
m-routed-reports</Ulrich>

 - Discussions were ongoing as to the need for both realm reports and =
RRR reports.


<Ulrich>I would say “…as to the need for realm repo=
rts in addition to realm-routed-reports” </Ulrich><=
/o:p>






#55 status:

  - Agreement on adding Realm reports based on the definition that rea=
lm reports apply to all traffic sent to the realm.


<Ulrich>This is what I’m missing. The issue has been very=
 briefly discussed under #34 without conclusion. There was no discussion
 under #55</Ulrich>




  - Limited discussion on the interaction between the new realm report=
s and the existing host and RRR reports.



After London meeting:



#23 status:

  - Tentative agreement in London meeting to remove RRR reports.


<Ulrich>What was the technical argument?</Ulrich><=
o:p>




  - Ben expressed the strongest concern with this plan.  Steve and Ben took action to discuss and come back with a recomme=
ndation. 




#55 status:

  - No change



Summary:

  - Tentative consensus reached to move forward with two report types =
- host and realm, with realm having the new definition.

<Ulrich>What was the technical argu=
ment?</Ulrich>



Current status:



#23 status:

 - Change the name to RRR

 - Whether or not to remove RRR and revisit later or keep RRR and revi=
sit later is an open issue.



#55 status:

  - My opinion is that we have at least rough consensus on the need to=
 support realm reports.  Others might have a different opinion.=



<Ulrich> There was no comment posted to issue #55, also no prop=
osed solution, so I cannot see where the consensus came from</Ulrich>=







Summary:

  - I believe we have three options:



   1) Support host and RRR reports

   2) Support host and Realm reports -- This was the tentative pl=
an coming out of the London meeting


< Ulrich> There is not even an issue number identifying problem=
s with RRR and proposing to remove RRR</Ulrich>




   3) Support host, RRR and Realm reports


<Ulrich> I support option 1</Ulrich>



Regards,



Steve




On 3/25/14 6:44 AM, Wiehe, Ulrich =
(NSN - DE/Munich) wrote:






Steve,<=
/p>

I don’t think we ar=
e going backwards (we may be out of synch though)


 <=
/p>

Can you please summarize =
the status of #23 and #55.


 <=
/p>

Ulrich<=
/p>

 <=
/p>

 <=
/p>





From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 7:38 PM

To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ok,=
 we are going backwards on this one.



I did not include option three because we had moved past that option in our=
 discussions, both on the list (I thought), and in the meeting.




I believe that we had come to rough consensus on the need for a realm repor=
t and the only remaining issue was whether we also included the RRR report =
type.



At this point, the only option is to leave all of the issues related to the=
 report types open and attempt to resolve them in the -03 draft.



Steve




On 3/24/14 11:13 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I do not agre=
e.


 =



We should still have the =
option



3) support report type 0 =
(this is called host report) and support of report type 1 (this has been ca=
lled relam report but people argued it should better be
 called realm routed request report).


 <=
/p>

Whether or not we need in=
 addition to type 0 and type 1 (or as a replacement of type 1) a realm-no-m=
atter-whether-destination-host-is present-or-not report
   is an open issue (see #55).


There are a lot of open q=
uestions  with regard to #55 and I have not seen a conclusion.<=
o:p>


Where I have seen a concl=
usion is issue #34 and that is inline with option 3).


 <=
/p>

Unless we conclude on #55=
, or decide to re-open #34, option 3) is what should go in the -02 draft.


 <=
/p>

 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Monday, March 24, 2014 2:57 PM

To: dime@ietf.org

Subject: Re: [Dime] Resolution on action to discuss the need for Rea=
lm-Routed-Reports






 


Ulr=
ich,

All,



We have two options for the -02 draft.



1) Support Host and Realm as proposed below, removing RRR reports.

2) Support Host, Realm and RRR reports.



The default plan is to go with option 1 in the -02 draft, as that was the p=
roposal that came out of the meeting in London.  RRR reports can be ad=
ded back in if and when we are convinced of the need. 




If there are strong objections to this then I will update the -02 draft to =
reflect all three report types.



I plan to make these updates Wednesday morning, Dallas, Texas time.



Either way I do not expect we will have agreed to wording on the interactio=
n between the report types when a reacting node has multiple report types, =
all of which apply to individual requests.  This will need to be addre=
ssed in the -03 draft.



Regards,



Steve




On 3/21/14 4:05 PM, Steve Donovan =
wrote:






Ulr=
ich,



The discussion should be captured in the minutes to the meeting.  I wa=
sn't able to find them posted yet.



Jouni, Lionel, what is the status of the minutes for the meeting?



My reading of emails prior to the London meeting is different from yours.&n=
bsp; I believe we had come to the conclusion that we needed host and realm =
(with the definition of realm as outlined below).  We were still discu=
ssing the need for Realm-Routed-Request reports.



Regards,



Steve




On 3/21/14 10:09 AM, Wiehe, Ulrich=
 (NSN - DE/Munich) wrote:






Steve,=



 =



I don’t know what h=
append in London.


Can you please summarize =
the technical reasons that led to the London agreement.



E-mail discussions prior =
to London have clearly directed towards a report type that requests throttl=
ing of realm routed request messages (i.e. not containing
 a destination host) rather than a report type that requests throttling of =
messages routed towards a realm (no matter whether they contain a destinati=
on host or not).   


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Steve Donovan

Sent: Friday, March 21, 2014 3:33 PM

To: dime@ietf.org

Subject: [Dime] Resolution on action to discuss the need for Realm-R=
outed-Reports






 


All,



Ben and I took the action item to discuss the need for the Realm-Routed-Rep=
orts (RRR) report type.



As you may recall, the consensus coming out of the DIME WG meeting in Londo=
n was to support two report types:



- Host -- Impacting requests with a Destination-Host AVP matching the host =
in the overload report (with the host implicitly determined from the Origin=
-Host AVP of the answer message carrying the overload report).



- Realm -- Impacting 100% of the requests with a Destination-Realm AVP matc=
hing the realm in the overload report (with the realm implicitly determine =
from the Origin-Realm of the answer message carrying the overload report).<=
br>


The action Ben and I took was to come back with an opinion on whether RRR r=
eports should also be supported.



My summary of the discussion is that we recommend to NOT include RRR report=
s in the current version of the base DOIC draft. 




We still have some concerns with the granularity of control enabled by havi=
ng just the two report types but the analysis of whether RRR reports are st=
ill needed can occur independent of the base DOIC draft.  If there is =
a determination that RRRs are needed
 in time to include in the base draft then it can be considered at that tim=
e.



Based on this, I propose the following 



- Resolution to issue #23 is to remove RRR reports from the document.

- Resolution to issue #55 is to add Realm reports (actually to redefine the=
m per the above definition).

- Resolution to issue #57 is that it no longer applies (as it deals with RR=
Rs).



There is also need for text describing the interaction between host and the=
 realm reports.  I don't expect we will have consensus on this wording=
 prior to the -02 draft being submitted.  To this end, I'll open a new=
 issue to deal with the need for wording on
 the interaction.



Regards,



Steve 












_______________________________________________


DiME mailing list


DiME@ietf.org


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




 




 




 




______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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.






--_000_E194C2E18676714DACA9C3A2516265D20267A7ABFR712WXCHMBA12z_--


From nobody Wed Mar 26 05:15:09 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 0B1411A0055 for ; Wed, 26 Mar 2014 05:15:07 -0700 (PDT)
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 rgO2VdsadCRK for ; Wed, 26 Mar 2014 05:15:01 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id D3DF41A0039 for ; Wed, 26 Mar 2014 05:15:01 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62324 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSmjQ-0007sH-Gr; Wed, 26 Mar 2014 05:14:58 -0700
Message-ID: <5332C4C1.9010801@usdonovans.com>
Date: Wed, 26 Mar 2014 07:14:57 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: lionel.morand@orange.com,  Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5331B195.9020402@usdonovans.com> <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com>
In-Reply-To: <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com>
Content-Type: multipart/alternative; boundary="------------000600090905090801050505"
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/8-RnJD-eFWwTcuRQfnkQ1gL9XSY
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Wed, 26 Mar 2014 12:15:07 -0000

This is a multi-part message in MIME format.
--------------000600090905090801050505
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit

Lionel,

Please see inline.

Steve


On 3/26/14 1:34 AM, lionel.morand@orange.com wrote:
> Hi Steve,
>
> In London, we ended up with the following proposal:
>
> - ONLY two report types - "Host" that applies when destination-host
> is present in the request. - "Realm" that applies to any request
> sent to a realm, except when a destination-host is present in the
> request AND a "Host" applies for this destination-host.

SRD> Yes, we agreed to two report types, Host and Realm.  The definition
of Realm was all traffic sent to the realm.  Look back at slide 4 in the
slides for the meeting to confirm:

http://tools.ietf.org/agenda/89/slides/slides-89-dime-1.pdf

My reading of the above is consistent with these definitions.  The above
statement also defines the interaction between host and realm reports. 
Restating, the following normative statements would apply:

When determining if a request should be throttled, there are three cases:

- Only a Realm report (based on the definition from the meeting) matches
the message -- In this case the Realm report MUST be used to determine
if the message is throttled.
- Only a Host report matches the message -- In this case the Host report
MUST be used to determine if the message is throttled.
- Both a Realm and Host report match the message -- In this case the
Host report MUST be used to determine if the message is throttled and
throttling based on the Realm report MUST NOT also be applied to the
message.

I'm ok at the moment with this wording, but I don't think we've thought
through the implications of prioritizing Host reports over Realm reports
when both apply.  As such, this is open to change in a future version of
the draft.

> 
> About renaming "Realm" as "Realm-Routed-Request", no strong issue as
> soon as the principle above are kept.

SRD> If we go with your proposal above then there is no name change but
rather a change in the definition of Realm report.

If we go with Ulrich's proposal then we should change the name from
Realm to RRR (or some other name yet to be suggested).

If we go with three reports then we also need to change the name of the
existing Realm report to RRR and redefine Realm to match the above logic.

> 
> The need for realm-based type that would apply to any request (even
> if a "Host" exists for a destination-host in the request) was
> challenged and not retained. Ben was supposed to lock you in a room
> and to convince you that this last report type was not needed.

This is NOT my recollection of the decision and is NOT what is reflected
in the minutes.  This is also NOT what you say above.

Here's the relevant portion of the minutes:

Report types - there was consensus that Host and Realm report types
needed to be retained. Ben suggested that if a node sent a Realm report,
it needed to be an absolute authority for the realm. Dave did not agree
that agents needed to be authoritative and felt that clients should be
able to make their own decisions on conflicting realm reports, which
Lionel disagreed with. Maria Cruz agreed with both proposals because it
would be deployment dependent. Steve said that the draft should provide
guidance that a sender of the realm report should be an authority and
that realm reports should not contradict. It should provide guidance on
what the client should do if does receive different realm reports. Ben
pointed out that, in the case where a realm was sending overload
reports, individual servers could send Reductions of 0% in their reports
to provide more information to clients.


ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a
proposal on whether to remove or to incorporate.

ACTION: Next version of DOIC will keep Host and Realm and leave
Realm-Routed-Request an open issue.

ACTION: Clarify precedence of the host and realm report types and what
actions to take when they are received.



> 
> Lionel
>
> Envoyé depuis mon Sony Xperia SP d'Orange
>
> Steve Donovan  a écrit :
>
> Consensus is obviously a fleeting and temporary thing.
>
> Let us make sure that we are precise in our definitions of the
> report types we are discussing.
>
> Host report - Applies when the destination-host AVP is present in
> the request. Realm-Routed-Request (RRR) - Applies when there is no
> destination-host AVP in the request. Realm - Applies to 100% of
> requests sent to the realm.
>
> These are the definitions used in our discussions in London and in
> various places in our email discussions.
>
> Can we please agree to use these definitions going forward so we are
> all talking about the same thing.
>
> Regards,
>
> Steve
>
> On 3/25/14 10:27 AM, lionel.morand@orange.com wrote:
>>
>> Hi Maria Cruz, All,
>>
>>
>>
>> In the previous mail, you wrote:
>>
>>
>>
>> /That is, we have two reports, host and realm. /
>>
>> /Host applies when Destination_host is present, and then it takes
>> precedence over Realm. If both are present, only Host is applied./
>>
>> /Realm applies when only Destination_realm is present./
>>
>>
>>
>> And I agree with this statement. But I'm not sure that this is the
>> case discussed by Ulrich.
>>
>>
>>
>> Whatever the name of the realm report type, is there an agreement
>> on the description given above by Maria Cruz and discussed in
>> London?
>>
>>
>>
>> Regards,
>>
>>
>>
>> Lionel
>>
>>
>>
>> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria
>> Cruz Bartolome *Envoyé :* mardi 25 mars 2014 16:21 *À :* Wiehe,
>> Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org *Objet
>> :* Re: [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>
>>
>> Dear all,
>>
>>
>>
>> I support option 1 a well
>>
>> Cheers
>>
>> /MCruz
>>
>>
>>
>> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Wiehe,
>> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de 2014 16:15
>>  *To:* ext Steve Donovan; dime@ietf.org *Subject:* Re: [Dime]
>> Resolution on action to discuss the need for Realm-Routed-Reports
>>
>>
>>
>> Steve,
>>
>> Thank you for this summary.
>>
>> Please see inline.
>>
>>
>>
>> Ulrich
>>
>>
>>
>> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com] *Sent:*
>> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN -
>> DE/Munich); dime@ietf.org  *Subject:* Re:
>> [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>
>>
>> Ulrich,
>>
>> I mean going backwards from where I thought we were after the
>> London meeting.
>>
>> We are clearly out of sync but hopefully we can fix that.
>>
>> Here's my understanding of the status of #23 and #55.
>>
>> Prior to London meeting:
>>
>> #23 status: - Agreement to change the name of existing realm
>> reports to realm-routed-reports (RRR).
>>
>> this includes agreement to keep the (newly called)
>> realm-routed-reports - Discussions were ongoing as to the
>> need for both realm reports and RRR reports.
>>
>> I would say “…as to the need for realm reports in addition
>> to realm-routed-reports” 
>>
>>
>>
>> #55 status: - Agreement on adding Realm reports based on the
>> definition that realm reports apply to all traffic sent to the
>> realm.
>>
>> This is what I’m missing. The issue has been very briefly
>> discussed under #34 without conclusion. There was no discussion
>> under #55
>>
>>
>> - Limited discussion on the interaction between the new realm
>> reports and the existing host and RRR reports.
>>
>> After London meeting:
>>
>> #23 status: - Tentative agreement in London meeting to remove RRR
>> reports.
>>
>> What was the technical argument?
>>
>>
>> - Ben expressed the strongest concern with this plan.  Steve and
>> Ben took action to discuss and come back with a recommendation.
>>
>> #55 status: - No change
>>
>> Summary: - Tentative consensus reached to move forward with two
>> report types - host and realm, with realm having the new
>> definition. What was the technical argument?
>>
>>
>> Current status:
>>
>> #23 status: - Change the name to RRR - Whether or not to remove
>> RRR and revisit later or keep RRR and revisit later is an open
>> issue.
>>
>> #55 status: - My opinion is that we have at least rough consensus
>> on the need to support realm reports.  Others might have a
>> different opinion.
>>
>>  There was no comment posted to issue #55, also no
>> proposed solution, so I cannot see where the consensus came
>> from
>>
>>
>>
>> Summary: - I believe we have three options:
>>
>> 1) Support host and RRR reports 2) Support host and Realm reports
>> -- This was the tentative plan coming out of the London meeting
>>
>> < Ulrich> There is not even an issue number identifying problems
>> with RRR and proposing to remove RRR
>>
>>
>> 3) Support host, RRR and Realm reports
>>
>>  I support option 1
>>
>>
>> Regards,
>>
>> Steve
>>
>> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>
>> Steve,
>>
>> I don’t think we are going backwards (we may be out of synch
>> though)
>>
>>
>>
>> Can you please summarize the status of #23 and #55.
>>
>>
>>
>> Ulrich
>>
>>
>>
>>
>>
>> *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com] *Sent:*
>> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -
>> DE/Munich); dime@ietf.org  *Subject:* Re:
>> [Dime] Resolution on action to discuss the need for
>> Realm-Routed-Reports
>>
>>
>>
>> Ok, we are going backwards on this one.
>>
>> I did not include option three because we had moved past that
>> option in our discussions, both on the list (I thought), and in
>> the meeting.
>>
>> I believe that we had come to rough consensus on the need for a
>> realm report and the only remaining issue was whether we also
>> included the RRR report type.
>>
>> At this point, the only option is to leave all of the issues
>> related to the report types open and attempt to resolve them in
>> the -03 draft.
>>
>> Steve
>>
>> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>
>> Steve,
>>
>>
>>
>> I do not agree.
>>
>>
>>
>> We should still have the option
>>
>> 3) support report type 0 (this is called host report) and support
>> of report type 1 (this has been called relam report but people
>> argued it should better be called realm routed request report).
>>
>>
>>
>> Whether or not we need in addition to type 0 and type 1 (or as a
>> replacement of type 1) a
>> realm-no-matter-whether-destination-host-is present-or-not report
>> is an open issue (see #55).
>>
>> There are a lot of open questions  with regard to #55 and I have
>> not seen a conclusion.
>>
>> Where I have seen a conclusion is issue #34 and that is inline
>> with option 3).
>>
>>
>>
>> Unless we conclude on #55, or decide to re-open #34, option 3) is
>> what should go in the -02 draft.
>>
>>
>>
>>
>>
>> Ulrich
>>
>>
>>
>> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM *To:*
>> dime@ietf.org  *Subject:* Re: [Dime]
>> Resolution on action to discuss the need for Realm-Routed-Reports
>>
>>
>>
>> Ulrich, All,
>>
>> We have two options for the -02 draft.
>>
>> 1) Support Host and Realm as proposed below, removing RRR reports.
>>  2) Support Host, Realm and RRR reports.
>>
>> The default plan is to go with option 1 in the -02 draft, as that
>> was the proposal that came out of the meeting in London.  RRR
>> reports can be added back in if and when we are convinced of the
>> need.
>>
>> If there are strong objections to this then I will update the -02
>> draft to reflect all three report types.
>>
>> I plan to make these updates Wednesday morning, Dallas, Texas
>> time.
>>
>> Either way I do not expect we will have agreed to wording on the
>> interaction between the report types when a reacting node has
>> multiple report types, all of which apply to individual requests.
>> This will need to be addressed in the -03 draft.
>>
>> Regards,
>>
>> Steve
>>
>> On 3/21/14 4:05 PM, Steve Donovan wrote:
>>
>> Ulrich,
>>
>> The discussion should be captured in the minutes to the meeting.
>> I wasn't able to find them posted yet.
>>
>> Jouni, Lionel, what is the status of the minutes for the meeting?
>>
>> My reading of emails prior to the London meeting is different from
>> yours.  I believe we had come to the conclusion that we needed
>> host and realm (with the definition of realm as outlined below).
>> We were still discussing the need for Realm-Routed-Request
>> reports.
>>
>> Regards,
>>
>> Steve
>>
>> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>>
>> Steve,
>>
>>
>>
>> I don’t know what happend in London.
>>
>> Can you please summarize the technical reasons that led to the
>> London agreement.
>>
>> E-mail discussions prior to London have clearly directed towards a
>> report type that requests throttling of realm routed request
>> messages (i.e. not containing a destination host) rather than a
>> report type that requests throttling of messages routed towards a
>> realm (no matter whether they contain a destination host or not).
>>
>>
>>
>>
>> Ulrich
>>
>>
>>
>> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *ext
>> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM *To:*
>> dime@ietf.org  *Subject:* [Dime] Resolution
>> on action to discuss the need for Realm-Routed-Reports
>>
>>
>>
>> All,
>>
>> Ben and I took the action item to discuss the need for the
>> Realm-Routed-Reports (RRR) report type.
>>
>> As you may recall, the consensus coming out of the DIME WG meeting
>> in London was to support two report types:
>>
>> - Host -- Impacting requests with a Destination-Host AVP matching
>> the host in the overload report (with the host implicitly
>> determined from the Origin-Host AVP of the answer message carrying
>> the overload report).
>>
>> - Realm -- Impacting 100% of the requests with a Destination-Realm
>> AVP matching the realm in the overload report (with the realm
>> implicitly determine from the Origin-Realm of the answer message
>> carrying the overload report).
>>
>> The action Ben and I took was to come back with an opinion on
>> whether RRR reports should also be supported.
>>
>> My summary of the discussion is that we recommend to NOT include
>> RRR reports in the current version of the base DOIC draft.
>>
>> We still have some concerns with the granularity of control
>> enabled by having just the two report types but the analysis of
>> whether RRR reports are still needed can occur independent of the
>> base DOIC draft.  If there is a determination that RRRs are needed
>> in time to include in the base draft then it can be considered at
>> that time.
>>
>> Based on this, I propose the following
>>
>> - Resolution to issue #23 is to remove RRR reports from the
>> document. - Resolution to issue #55 is to add Realm reports
>> (actually to redefine them per the above definition). - Resolution
>> to issue #57 is that it no longer applies (as it deals with RRRs).
>>
>> There is also need for text describing the interaction between
>> host and the realm reports.  I don't expect we will have consensus
>> on this wording prior to the -02 draft being submitted.  To this
>> end, I'll open a new issue to deal with the need for wording on
>> the interaction.
>>
>> Regards,
>>
>> Steve
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> 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.



--------------000600090905090801050505
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Lionel,

    

    Please see inline.

    

    Steve

    

    

    On 3/26/14 1:34 AM, lionel.morand@orange.com wrote:

    > Hi Steve,

      > 

      > In London, we ended up with the following proposal:

      > 

      > - ONLY two report types - "Host" that applies when
      destination-host 

      > is present in the request. - "Realm" that applies to any
      request

      > sent to a realm, except when a destination-host is present in
      the

      > request AND a "Host" applies for this destination-host.

    

    SRD> Yes, we agreed to two report types, Host and Realm.  The
    definition of Realm was all traffic sent to the realm.  Look back at
    slide 4 in the slides for the meeting to confirm:

    

    http://tools.ietf.org/agenda/89/slides/slides-89-dime-1.pdf

    

    My reading of the above is consistent with these definitions.  The
    above statement also defines the interaction between host and realm
    reports.  Restating, the following normative statements would apply:

    

    When determining if a request should be throttled, there are three
    cases:

    

    - Only a Realm report (based on the definition from the meeting)
    matches the message -- In this case the Realm report MUST be used to
    determine if the message is throttled.

    - Only a Host report matches the message -- In this case the Host
    report MUST be used to determine if the message is throttled.

    - Both a Realm and Host report match the message -- In this case the
    Host report MUST be used to determine if the message is throttled
    and throttling based on the Realm report MUST NOT also be applied to
    the message.

    

    I'm ok at the moment with this wording, but I don't think we've
    thought through the implications of prioritizing Host reports over
    Realm reports when both apply.  As such, this is open to change in a
    future version of the draft.

    

    > 

      > About renaming "Realm" as "Realm-Routed-Request", no strong
      issue as 

      > soon as the principle above are kept.

    

    SRD> If we go with your proposal above then there is no name
    change but rather a change in the definition of Realm report.

    

    If we go with Ulrich's proposal then we should change the name from
    Realm to RRR (or some other name yet to be suggested).

    

    If we go with three reports then we also need to change the name of
    the existing Realm report to RRR and redefine Realm to match the
    above logic.

    

    > 

      > The need for realm-based type that would apply to any request
      (even 

      > if a "Host" exists for a destination-host in the request) was
      

      > challenged and not retained. Ben was supposed to lock you in
      a room 

      > and to convince you that this last report type was not
      needed.

    

    This is NOT my recollection of the decision and is NOT what is
    reflected in the minutes.  This is also NOT what you say above. 

    

    Here's the relevant portion of the minutes:

    

    Report types - there was consensus that Host and Realm report types
    needed to be retained. Ben suggested that if a node sent a Realm
    report, it needed to be an absolute authority for the realm. Dave
    did not agree that agents needed to be authoritative and felt that
    clients should be able to make their own decisions on conflicting
    realm reports, which Lionel disagreed with. Maria Cruz agreed with
    both proposals because it would be deployment dependent. Steve said
    that the draft should provide guidance that a sender of the realm
    report should be an authority and that realm reports should not
    contradict. It should provide guidance on what the client should do
    if does receive different realm reports. Ben pointed out that, in
    the case where a realm was sending overload reports, individual
    servers could send Reductions of 0% in their reports to provide more
    information to clients. 

    

    

    ACTION: Ben and Steve to discuss Realm-Routed-Request and come up
    with a proposal on whether to remove or to incorporate. 

    

    ACTION: Next version of DOIC will keep Host and Realm and leave
    Realm-Routed-Request an open issue. 

    

    ACTION: Clarify precedence of the host and realm report types and
    what actions to take when they are received. 

    

    

    

    > 

      > Lionel

      > 

      > Envoyé depuis mon Sony Xperia SP d'Orange

      > 

      > Steve Donovan <srdonovan@usdonovans.com> a écrit :

      > 

      > Consensus is obviously a fleeting and temporary thing.

      > 

      > Let us make sure that we are precise in our definitions of
      the

      > report types we are discussing.

      > 

      > Host report - Applies when the destination-host AVP is
      present in

      > the request. Realm-Routed-Request (RRR) - Applies when there
      is no 

      > destination-host AVP in the request. Realm - Applies to 100%
      of 

      > requests sent to the realm.

      > 

      > These are the definitions used in our discussions in London
      and in 

      > various places in our email discussions.

      > 

      > Can we please agree to use these definitions going forward so
      we are 

      > all talking about the same thing.

      > 

      > Regards,

      > 

      > Steve

      > 

      > On 3/25/14 10:27 AM, lionel.morand@orange.com wrote:

      >> 

      >> Hi Maria Cruz, All,

      >> 

      >> 

      >> 

      >> In the previous mail, you wrote:

      >> 

      >> 

      >> 

      >> /That is, we have two reports, host and realm. /

      >> 

      >> /Host applies when Destination_host is present, and then
      it takes 

      >> precedence over Realm. If both are present, only Host is
      applied./

      >> 

      >> /Realm applies when only Destination_realm is present./

      >> 

      >> 

      >> 

      >> And I agree with this statement. But I'm not sure that
      this is the 

      >> case discussed by Ulrich.

      >> 

      >> 

      >> 

      >> Whatever the name of the realm report type, is there an
      agreement 

      >> on the description given above by Maria Cruz and
      discussed in 

      >> London?

      >> 

      >> 

      >> 

      >> Regards,

      >> 

      >> 

      >> 

      >> Lionel

      >> 

      >> 

      >> 

      >> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
      Maria 

      >> Cruz Bartolome *Envoyé :* mardi 25 mars 2014 16:21 *À :*
      Wiehe, 

      >> Ulrich (NSN - DE/Munich); ext Steve Donovan;
      dime@ietf.org *Objet 

      >> :* Re: [Dime] Resolution on action to discuss the need
      for 

      >> Realm-Routed-Reports

      >> 

      >> 

      >> 

      >> Dear all,

      >> 

      >> 

      >> 

      >> I support option 1 a well

      >> 

      >> Cheers

      >> 

      >> /MCruz

      >> 

      >> 

      >> 

      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *Wiehe, 

      >> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de
      2014 16:15

      >>  *To:* ext Steve Donovan; dime@ietf.org *Subject:* Re:
      [Dime] 

      >> Resolution on action to discuss the need for
      Realm-Routed-Reports

      >> 

      >> 

      >> 

      >> Steve,

      >> 

      >> Thank you for this summary.

      >> 

      >> Please see inline.

      >> 

      >> 

      >> 

      >> Ulrich

      >> 

      >> 

      >> 

      >> *From:*ext Steve Donovan
      [mailto:srdonovan@usdonovans.com] *Sent:* 

      >> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN
      - 

      >> DE/Munich); dime@ietf.org <mailto:dime@ietf.org>
      *Subject:* Re: 

      >> [Dime] Resolution on action to discuss the need for 

      >> Realm-Routed-Reports

      >> 

      >> 

      >> 

      >> Ulrich,

      >> 

      >> I mean going backwards from where I thought we were after
      the 

      >> London meeting.

      >> 

      >> We are clearly out of sync but hopefully we can fix that.

      >> 

      >> Here's my understanding of the status of #23 and #55.

      >> 

      >> Prior to London meeting:

      >> 

      >> #23 status: - Agreement to change the name of existing
      realm 

      >> reports to realm-routed-reports (RRR).

      >> 

      >> <Ulrich>this includes agreement to keep the (newly
      called) 

      >> realm-routed-reports</Ulrich> - Discussions were
      ongoing as to the 

      >> need for both realm reports and RRR reports.

      >> 

      >> <Ulrich>I would say “…as to the need for realm
      reports in addition 

      >> to realm-routed-reports” </Ulrich>

      >> 

      >> 

      >> 

      >> #55 status: - Agreement on adding Realm reports based on
      the 

      >> definition that realm reports apply to all traffic sent
      to the 

      >> realm.

      >> 

      >> <Ulrich>This is what I’m missing. The issue has
      been very briefly 

      >> discussed under #34 without conclusion. There was no
      discussion 

      >> under #55</Ulrich>

      >> 

      >> 

      >> - Limited discussion on the interaction between the new
      realm 

      >> reports and the existing host and RRR reports.

      >> 

      >> After London meeting:

      >> 

      >> #23 status: - Tentative agreement in London meeting to
      remove RRR 

      >> reports.

      >> 

      >> <Ulrich>What was the technical
      argument?</Ulrich>

      >> 

      >> 

      >> - Ben expressed the strongest concern with this plan. 
      Steve and 

      >> Ben took action to discuss and come back with a
      recommendation.

      >> 

      >> #55 status: - No change

      >> 

      >> Summary: - Tentative consensus reached to move forward
      with two 

      >> report types - host and realm, with realm having the new
      

      >> definition. <Ulrich>What was the technical
      argument?</Ulrich>

      >> 

      >> 

      >> Current status:

      >> 

      >> #23 status: - Change the name to RRR - Whether or not to
      remove

      >> RRR and revisit later or keep RRR and revisit later is an
      open

      >> issue.

      >> 

      >> #55 status: - My opinion is that we have at least rough
      consensus 

      >> on the need to support realm reports.  Others might have
      a 

      >> different opinion.

      >> 

      >> <Ulrich> There was no comment posted to issue #55,
      also no

      >> proposed solution, so I cannot see where the consensus
      came

      >> from</Ulrich>

      >> 

      >> 

      >> 

      >> Summary: - I believe we have three options:

      >> 

      >> 1) Support host and RRR reports 2) Support host and Realm
      reports 

      >> -- This was the tentative plan coming out of the London
      meeting

      >> 

      >> < Ulrich> There is not even an issue number
      identifying problems 

      >> with RRR and proposing to remove RRR</Ulrich>

      >> 

      >> 

      >> 3) Support host, RRR and Realm reports

      >> 

      >> <Ulrich> I support option 1</Ulrich>

      >> 

      >> 

      >> Regards,

      >> 

      >> Steve

      >> 

      >> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >> 

      >> Steve,

      >> 

      >> I don’t think we are going backwards (we may be out of
      synch 

      >> though)

      >> 

      >> 

      >> 

      >> Can you please summarize the status of #23 and #55.

      >> 

      >> 

      >> 

      >> Ulrich

      >> 

      >> 

      >> 

      >> 

      >> 

      >> *From:*ext Steve Donovan
      [mailto:srdonovan@usdonovans.com] *Sent:* 

      >> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -
      

      >> DE/Munich); dime@ietf.org <mailto:dime@ietf.org>
      *Subject:* Re: 

      >> [Dime] Resolution on action to discuss the need for 

      >> Realm-Routed-Reports

      >> 

      >> 

      >> 

      >> Ok, we are going backwards on this one.

      >> 

      >> I did not include option three because we had moved past
      that 

      >> option in our discussions, both on the list (I thought),
      and in

      >> the meeting.

      >> 

      >> I believe that we had come to rough consensus on the need
      for a 

      >> realm report and the only remaining issue was whether we
      also 

      >> included the RRR report type.

      >> 

      >> At this point, the only option is to leave all of the
      issues 

      >> related to the report types open and attempt to resolve
      them in

      >> the -03 draft.

      >> 

      >> Steve

      >> 

      >> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >> 

      >> Steve,

      >> 

      >> 

      >> 

      >> I do not agree.

      >> 

      >> 

      >> 

      >> We should still have the option

      >> 

      >> 3) support report type 0 (this is called host report) and
      support 

      >> of report type 1 (this has been called relam report but
      people 

      >> argued it should better be called realm routed request
      report).

      >> 

      >> 

      >> 

      >> Whether or not we need in addition to type 0 and type 1
      (or as a 

      >> replacement of type 1) a 

      >> realm-no-matter-whether-destination-host-is
      present-or-not report 

      >> is an open issue (see #55).

      >> 

      >> There are a lot of open questions  with regard to #55 and
      I have 

      >> not seen a conclusion.

      >> 

      >> Where I have seen a conclusion is issue #34 and that is
      inline

      >> with option 3).

      >> 

      >> 

      >> 

      >> Unless we conclude on #55, or decide to re-open #34,
      option 3) is 

      >> what should go in the -02 draft.

      >> 

      >> 

      >> 

      >> 

      >> 

      >> Ulrich

      >> 

      >> 

      >> 

      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *ext

      >> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM
      *To:*

      >> dime@ietf.org <mailto:dime@ietf.org> *Subject:* Re:
      [Dime]

      >> Resolution on action to discuss the need for
      Realm-Routed-Reports

      >> 

      >> 

      >> 

      >> Ulrich, All,

      >> 

      >> We have two options for the -02 draft.

      >> 

      >> 1) Support Host and Realm as proposed below, removing RRR
      reports.

      >>  2) Support Host, Realm and RRR reports.

      >> 

      >> The default plan is to go with option 1 in the -02 draft,
      as that 

      >> was the proposal that came out of the meeting in London. 
      RRR 

      >> reports can be added back in if and when we are convinced
      of the 

      >> need.

      >> 

      >> If there are strong objections to this then I will update
      the -02 

      >> draft to reflect all three report types.

      >> 

      >> I plan to make these updates Wednesday morning, Dallas,
      Texas 

      >> time.

      >> 

      >> Either way I do not expect we will have agreed to wording
      on the 

      >> interaction between the report types when a reacting node
      has 

      >> multiple report types, all of which apply to individual
      requests. 

      >> This will need to be addressed in the -03 draft.

      >> 

      >> Regards,

      >> 

      >> Steve

      >> 

      >> On 3/21/14 4:05 PM, Steve Donovan wrote:

      >> 

      >> Ulrich,

      >> 

      >> The discussion should be captured in the minutes to the
      meeting.

      >> I wasn't able to find them posted yet.

      >> 

      >> Jouni, Lionel, what is the status of the minutes for the
      meeting?

      >> 

      >> My reading of emails prior to the London meeting is
      different from 

      >> yours.  I believe we had come to the conclusion that we
      needed

      >> host and realm (with the definition of realm as outlined
      below).

      >> We were still discussing the need for
      Realm-Routed-Request

      >> reports.

      >> 

      >> Regards,

      >> 

      >> Steve

      >> 

      >> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >> 

      >> Steve,

      >> 

      >> 

      >> 

      >> I don’t know what happend in London.

      >> 

      >> Can you please summarize the technical reasons that led
      to the 

      >> London agreement.

      >> 

      >> E-mail discussions prior to London have clearly directed
      towards a 

      >> report type that requests throttling of realm routed
      request 

      >> messages (i.e. not containing a destination host) rather
      than a 

      >> report type that requests throttling of messages routed
      towards a 

      >> realm (no matter whether they contain a destination host
      or not).

      >> 

      >> 

      >> 

      >> 

      >> Ulrich

      >> 

      >> 

      >> 

      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *ext

      >> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM
      *To:*

      >> dime@ietf.org <mailto:dime@ietf.org> *Subject:*
      [Dime] Resolution

      >> on action to discuss the need for Realm-Routed-Reports

      >> 

      >> 

      >> 

      >> All,

      >> 

      >> Ben and I took the action item to discuss the need for
      the 

      >> Realm-Routed-Reports (RRR) report type.

      >> 

      >> As you may recall, the consensus coming out of the DIME
      WG meeting 

      >> in London was to support two report types:

      >> 

      >> - Host -- Impacting requests with a Destination-Host AVP
      matching 

      >> the host in the overload report (with the host implicitly
      

      >> determined from the Origin-Host AVP of the answer message
      carrying 

      >> the overload report).

      >> 

      >> - Realm -- Impacting 100% of the requests with a
      Destination-Realm 

      >> AVP matching the realm in the overload report (with the
      realm 

      >> implicitly determine from the Origin-Realm of the answer
      message 

      >> carrying the overload report).

      >> 

      >> The action Ben and I took was to come back with an
      opinion on 

      >> whether RRR reports should also be supported.

      >> 

      >> My summary of the discussion is that we recommend to NOT
      include 

      >> RRR reports in the current version of the base DOIC
      draft.

      >> 

      >> We still have some concerns with the granularity of
      control

      >> enabled by having just the two report types but the
      analysis of

      >> whether RRR reports are still needed can occur
      independent of the

      >> base DOIC draft.  If there is a determination that RRRs
      are needed

      >> in time to include in the base draft then it can be
      considered at

      >> that time.

      >> 

      >> Based on this, I propose the following

      >> 

      >> - Resolution to issue #23 is to remove RRR reports from
      the 

      >> document. - Resolution to issue #55 is to add Realm
      reports 

      >> (actually to redefine them per the above definition). -
      Resolution 

      >> to issue #57 is that it no longer applies (as it deals
      with RRRs).

      >> 

      >> There is also need for text describing the interaction
      between

      >> host and the realm reports.  I don't expect we will have
      consensus

      >> on this wording prior to the -02 draft being submitted. 
      To this

      >> end, I'll open a new issue to deal with the need for
      wording on

      >> the interaction.

      >> 

      >> Regards,

      >> 

      >> Steve

      >> 

      >> 

      >> 

      >> 

      >> 

      >> _______________________________________________

      >> 

      >> DiME mailing list

      >> 

      >> DiME@ietf.org <mailto: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.

    

    

  


--------------000600090905090801050505--


From nobody Wed Mar 26 05:20: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 3C42B1A01B0 for ; Wed, 26 Mar 2014 05:20:49 -0700 (PDT)
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 uTORGdifvgX7 for ; Wed, 26 Mar 2014 05:20:40 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 564401A0055 for ; Wed, 26 Mar 2014 05:20:40 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62333 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSmoo-0005X5-14; Wed, 26 Mar 2014 05:20:36 -0700
Message-ID: <5332C60E.2060805@usdonovans.com>
Date: Wed, 26 Mar 2014 07:20:30 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "Shishufeng (Susan)" ,  "lionel.morand@orange.com" , Jouni Korhonen 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------090401030006050805010806"
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/sg1Yh0pJMS63xl2EqBk8E5MN-c8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 12:20:49 -0000

This is a multi-part message in MIME format.
--------------090401030006050805010806
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I disagree that the majority of individuals (companies don't apply here)
have a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it
explicit. 

I also support Lionel being able to make a decision.  We all need to be
flexible enough to accept that decision, especially when there is no
technical reason to disagree with the decision.

Steve

On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
>
> Hello Lionel,
>
>  
>
> Thanks for your reply.
>
>  
>
> It is clear that majority companies involved in the discussion prefer
> to not have this AVP as mandatory. And Steve is ok with it as it is,
> and thus everyone is ok with it as optional. I'm wondering why you
> choose another way forward, and don't take opinion from majority
> companies into account, which is strange for me.
>
>  
>
> We talked much about it, and in some major cases, this AVP is useless.
> If needed, anyway an optional AVP has to be present, I don't see any
> problem with it. We did a lot like this in 3GPP spec. I don't
> understand how in this case it shall be mandatory if you also agree
> that it is not needed in some cases.
>
>  
>
> Best Regards,
>
> Susan
>
>  
>
>  
>
> *From:*lionel.morand@orange.com [mailto:lionel.morand@orange.com]
> *Sent:* Wednesday, March 26, 2014 3:35 PM
> *To:* Shishufeng (Susan); Steve Donovan; Jouni Korhonen
> *Cc:* dime@ietf.org; Benoit Claise
> *Subject:* RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> Hi Susan,
>
>  
>
> I do care about comments from other but we need to move on.
>
>  
>
> My decision is based on the following: from a technical point of view,
> there is no issue if we define this AVP as required. From a protocol
> aspect, it is cleaner as a report ALWAYS applies to a given type.
> Default value was considered as sub-optimal by Jouni, Ben, Steve,
> Maria Cruz (who has triggered this issue) and myself.
>
>  
>
> Now, about the process, a 100% is not required to move forward. As it
> is not possible to get consensus on this issue, I use my prerogative
> to pick one solution, the one that seems to be the best solution at
> this stage, to be able to close the discussion at this stage and
> produce the draft that we need.
>
>  
>
> After, it is always possible to challenge again the content of the
> draft if there is still concern.
>
>  
>
> Benoit, the Area Director, is copied. It is not a putsch. Just
> administrative way agreed within IETF to be able to move forward a WG
> draft, which is the ultimate goal of everyone I think.
>
>  
>
> Regards,
>
>  
>
> Lionel.
>
>  
>
> *De :*Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
> *Envoyé :* mercredi 26 mars 2014 08:06
> *À :* Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni
> Korhonen
> *Cc :* dime@ietf.org 
> *Objet :* RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> Hello Lionel,
>
>  
>
> Further clarification:
>
>  
>
> I don't agree with this, not ok to everyone as you said.
>
>  
>
> Best Regards,
>
> Susan
>
>  
>
> *From:*Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
> *Sent:* Wednesday, March 26, 2014 2:56 PM
> *To:* lionel.morand@orange.com ;
> Steve Donovan; Jouni Korhonen
> *Cc:* dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> Hello Lionel,
>
>  
>
> I don't understand it.
>
>  
>
> Please clarify if you care about other people's comments.
>
>  
>
> Best Regards,
>
> Susan
>
>  
>
> *From:*lionel.morand@orange.com 
> [mailto:lionel.morand@orange.com]
> *Sent:* Wednesday, March 26, 2014 2:44 PM
> *To:* Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
> *Cc:* dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> As chair and temporary doc shepherd,
>  
> Please stop this thread for now.
>  
> As mandatory/required is ok for everyone (even if useless in certain case), let use it for now.
>  
> Lionel 
>  
>  
> "Shishufeng (Susan)" > a écrit :
>  
>
> Hello Steve,
>
>  
>
> Thanks for clarifying the IETF procedure. I'm not familiar with it,
> while I know the draft is mainly for 3GPP use, that's why we 3GPP
> delegates are deeply involved in this specific discussion. If most of
> 3GPP people think it is not so needed I couldn't understand why it
> shall be mandatory.
>
>  
>
> From technical point of view, in the case realm based report type is
> not needed, nothing wrong without this AVP, and even better and cleaner.
>
>  
>
> And you ever said you have preference but ok with either way forward,
> i.e., make it mandatory or optional. Then let's move on with the draft
> as it is on this point, if you agree.
>
>  
>
> Best Regards,
>
> Susan
>
>  
>
> *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
> *Sent:* Tuesday, March 25, 2014 8:39 PM
> *To:* Shishufeng (Susan); Jouni Korhonen
> *Cc:* dime@ietf.org 
> *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>  
>
> Susan,
>
> We have not been following a process of determining consensus based on
> a majority of companies expressing a preference.  It is also the case
> that, in the IETF, companies do not contribute, individuals contribute.
>
> In addition, if we did take a "vote" on this one, I'm not sure which
> side would actually have a majority.
>
> We might need to change our process to speed things up, but right now
> we have been striving for true consensus where everyone agrees.  Note
> that this doesn't mean everyone agrees with the technical reasoning
> behind the decision.  There have been many cases where agreement is
> reached because it was more important to get something finished then
> to win a technical argument.
>
> If we can't start moving a little faster then we will likely need to
> change to rough consensus, where the measure is that most everyone
> agrees.  However, in the IETF, even this is not a voting process.  If
> things are close to 50-50 in opinions then the correct process is to
> continue to discuss the technical merits of each alternative until
> rough consensus is reached.
>
> Regards,
>
> Steve
>
> On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
>
>     Hi Steve,
>
>      
>
>     As I know, majority companies expressed preference to keep the AVP
>     as optional and keep the texts as they are. You have preference to
>     have it explicitly but ok with either way. That's how I assumed we
>     reached consensus.
>
>      
>
>     Best Regards,
>
>     Susan
>
>      
>
>     *From:*Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Monday, March 24, 2014 8:26 PM
>     *To:* Shishufeng (Susan); Jouni Korhonen
>     *Cc:* dime@ietf.org 
>     *Subject:* Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>      
>
>     Susan,
>
>     We are in the middle of the discussion and have not yet reached
>     consensus.
>
>     I agree with Jouni on making it explicit.  Either way, we should
>     try to make a decision quickly.
>
>     Steve
>
>     On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:
>
>         Hello Jouni,
>
>          
>
>         I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 
>
>          
>
>         Best Regards,
>
>         Susan
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
>
>         Sent: Saturday, March 22, 2014 10:38 AM
>
>         To: Steve Donovan
>
>         Cc: dime@ietf.org 
>
>         Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>          
>
>          
>
>         Lets have it explicit then. Use '<' and '>' to make the position fixed.
>
>          
>
>         - Jouni
>
>          
>
>         On Mar 19, 2014, at 1:29 AM, Steve Donovan   wrote:
>
>          
>
>             I'm ok with either direction but generally lean toward being explicit.
>
>              
>
>             Do we have other opinions?  
>
>              
>
>             Steve
>
>             On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:
>
>                 Hello,
>
>                 I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.
>
>                 This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.
>
>                 If there is consensus on this, I will go with this.
>
>                 Best regards
>
>                 /MCruz
>
>                  
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
>
>                 Sent: martes, 18 de marzo de 2014 17:47
>
>                 To: dime@ietf.org 
>
>                 Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 All,
>
>                  
>
>                 Do we have consensus that the OC-Report-Type AVP is required?
>
>                  
>
>                 If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.
>
>                  
>
>                 Jouni,
>
>                  
>
>                 How do we indicate a fixed position for an AVP?  
>
>                  
>
>                 I presonally don't see this as critical but we can add this requirement if there is consensus.
>
>                  
>
>                 Regards,
>
>                  
>
>                 Steve
>
>                  
>
>                 On 2/28/14 10:27 AM, Jouni Korhonen wrote:
>
>                  
>
>                 Hi,
>
>                  
>
>                 How having the AVP could be less error prone if it has a default 
>
>                 value and the receiver knows exactly how to proceed when the AVP is 
>
>                 not present?
>
>                  
>
>                 If a node does not include it when it should, the implementation is 
>
>                 broken. Wouldn't a broken node be able to put wrong report type into 
>
>                 the AVP even if the AVP is mandatory?
>
>                  
>
>                 Anyway, if it is my statement keeping issue #54 still open, consider 
>
>                 it resolved from my side. I am OK making the OC-Report-Type AVP as 
>
>                 required/mandatory AVP. Should we also consider it having a fixed 
>
>                 position just after the OC-Sequence-Number AVP as well since it is 
>
>                 going to in every OC-OLR?
>
>                  
>
>                 - Jouni
>
>                  
>
>                  
>
>                  
>
>                 On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome   wrote:
>
>                  
>
>                  
>
>                 Hello all,
>
>                  
>
>                 I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.
>
>                  
>
>                 I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.
>
>                  
>
>                 Best regards
>
>                 /MCruz
>
>                  
>
>                 -----Original Message-----
>
>                 From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell
>
>                 Sent: viernes, 14 de febrero de 2014 23:13
>
>                 To: Jouni Korhonen
>
>                 Cc: dime@ietf.org 
>
>                 Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.
>
>                  
>
>                 On Feb 13, 2014, at 6:05 AM, Jouni Korhonen   wrote:
>
>                  
>
>                  
>
>                 Agree that it is a small optimization, which I put there because at 
>
>                 the beginning there seemed to be a lot of worry on every extra AVP 
>
>                 ;-)
>
>                  
>
>                 I prefer having the AVP optional but with a default value just like 
>
>                 it is now. We have the same for the reduction percentage and the 
>
>                 validity time as well.
>
>                  
>
>                 - Jouni
>
>                  
>
>                 On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"   wrote:
>
>                  
>
>                 Hi Mcruz
>
>                  
>
>                 The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 
>
>                 We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.
>
>                  
>
>                 Best regards
>
>                  
>
>                 JJacques
>
>                  
>
>                  
>
>                  
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de 
>
>                 lionel.morand@orange.com  Envoyé : mercredi 12 février 2014 15:46 À :
>
>                 dime@ietf.org ; maria.cruz.bartolome@ericsson.com  Objet : Re: [Dime] 
>
>                 [dime] #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 Hi Maria Cruz,
>
>                  
>
>                 I'm assuming that you mean "required" instead of "mandatory", right?
>
>                  
>
>                 So instead of:
>
>                  
>
>                 OC-OLR ::= < AVP Header: TBD2 >
>
>                            < OC-Sequence-Number >
>
>                            [ OC-Report-Type ]
>
>                            [ OC-Reduction-Percentage ]
>
>                            [ OC-Validity-Duration ]
>
>                          * [ AVP ]
>
>                  
>
>                 You would prefer:
>
>                  
>
>                 OC-OLR ::= < AVP Header: TBD2 >
>
>                            < OC-Sequence-Number >
>
>                            { OC-Report-Type }
>
>                            [ OC-Reduction-Percentage ]
>
>                            [ OC-Validity-Duration ]
>
>                          * [ AVP ]
>
>                  
>
>                 And I'm fine with this proposal.
>
>                  
>
>                 Cheers,
>
>                  
>
>                 Lionel
>
>                  
>
>                 -----Message d'origine-----
>
>                 De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 
>
>                 tracker Envoyé : mercredi 12 février 2014 15:26 À :
>
>                 maria.cruz.bartolome@ericsson.com  Cc : dime@ietf.org  Objet : [Dime] 
>
>                 [dime] #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 #54: OC-Report-Type as mandatory AVP
>
>                  
>
>                 Now in chapter 4.6:
>
>                  
>
>                  The default value of the OC-Report-Type AVP is 0 (i.e. the host  
>
>                 report).
>
>                  
>
>                 This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.
>
>                  
>
>                 --
>
>                 -----------------------------------------------+---------------------
>
>                 -----------------------------------------------+---
>
>                 -----------------------------------------------+---
>
>                 Reporter:  maria.cruz.bartolome@ericsson.com   |      Owner:  MCruz
>
>                   Type:  defect                             |  Bartolomé
>
>                 Priority:  major                              |     Status:  new
>
>                 Component:  draft-docdt-dime-ovli              |  Milestone:
>
>                 Severity:  Active WG Document                 |    Version:  1.0
>
>                                                             |   Keywords:
>
>                 -----------------------------------------------+---------------------
>
>                 -----------------------------------------------+---
>
>                 -----------------------------------------------+---
>
>                  
>
>                 Ticket URL:  
>
>                 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
>
>                  
>
>                  
>
>              
>
>             _______________________________________________
>
>             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.


--------------090401030006050805010806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I disagree that the
      majority of individuals (companies don't apply here) have a
      preference.  We have not established the view of a majority.

      

      If we took a vote of individuals on this, I would vote for making
      it explicit.  

      

      I also support Lionel being able to make a decision.  We all need
      to be flexible enough to accept that decision, especially when
      there is no technical reason to disagree with the decision.

      

      Steve

      

    
    
On 3/26/14 3:03 AM, Shishufeng (Susan)
      wrote:

    

    

      
      
      
      

        
Hello Lionel,

        
 

        
Thanks for your reply.

        
 

        
It is clear that majority companies involved in
            the discussion prefer to not have this AVP as mandatory. And
            Steve is ok with it as it is, and thus everyone is ok with
            it as optional. I’m wondering why you choose another way
            forward, and don’t take opinion from majority companies into
            account, which is strange for me.
            

        
 

        
We talked much about it, and in some major
            cases, this AVP is useless. If needed, anyway an optional
            AVP has to be present, I don’t see any problem with it. We
            did a lot like this in 3GPP spec. I don’t understand how in
            this case it shall be mandatory if you also agree that it is
            not needed in some cases.

        
 

        
Best Regards,

        
Susan

        
 

        
 

        

          

            
From: lionel.morand@orange.com
                [mailto:lionel.morand@orange.com]
                

                Sent: Wednesday, March 26, 2014 3:35 PM

                To: Shishufeng (Susan); Steve Donovan; Jouni
                Korhonen

                Cc: dime@ietf.org; Benoit Claise

                Subject: RE: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        
Hi Susan,

        
 

        
I do care about comments from other but we need
            to move on.

        
 

        
My decision is based on the following: from a
            technical point of view, there is no issue if we define this
            AVP as required. From a protocol aspect, it is cleaner as a
            report ALWAYS applies to a given type. Default value was
            considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz
            (who has triggered this issue) and myself.

        
 

        
Now, about the process, a 100% is not required
            to move forward. As it is not possible to get consensus on
            this issue, I use my prerogative to pick one solution, the
            one that seems to be the best solution at this stage, to be
            able to close the discussion at this stage and produce the
            draft that we need.

        
 

        
After, it is always possible to challenge again
            the content of the draft if there is still concern.

        
 

        
Benoit, the Area Director, is copied. It is not
            a putsch. Just administrative way agreed within IETF to be
            able to move forward a WG draft, which is the ultimate goal
            of everyone I think.

        
 

        
Regards,

        
 

        
Lionel.

        
 

        

          

            
De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
                

                Envoyé : mercredi 26 mars 2014 08:06

                À : Shishufeng (Susan); MORAND Lionel IMT/OLN;
                Steve Donovan; Jouni Korhonen

                Cc : dime@ietf.org

                Objet : RE: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        
Hello Lionel,

        
 

        
Further clarification:

        
 

        
I don’t agree with this, not ok to everyone as
            you said.

        
 

        
Best Regards,

        
Susan

        
 

        

          

            
From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
                

                Sent: Wednesday, March 26, 2014 2:56 PM

                To: lionel.morand@orange.com;
                Steve Donovan; Jouni Korhonen

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        
Hello Lionel,

        
 

        
I don’t understand it.

        
 

        
Please clarify if you care about other people’s
            comments.

        
 

        
Best Regards,

        
Susan

        
 

        

          

            
From:
                lionel.morand@orange.com
                [mailto:lionel.morand@orange.com]
                

                Sent: Wednesday, March 26, 2014 2:44 PM

                To: Steve Donovan; Jouni Korhonen; Shishufeng
                (Susan)

                Cc: dime@ietf.org

                Subject: Re: [Dime] [dime] #54: OC-Report-Type as
                mandatory AVP

          

        

        
 

        
As chair and temporary doc shepherd,

        
 

        
Please stop this thread for now.

        
 

        
As mandatory/required is ok for everyone (even if useless in certain case), let use it for now.

        
 

        
Lionel 

        
 

        
 

        
"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a écrit :

        
 

        

          

            
Hello Steve,

            
 

            
Thanks for clarifying the IETF procedure.
                I’m not familiar with it, while I know the draft is
                mainly for 3GPP use, that’s why we 3GPP delegates are
                deeply involved in this specific discussion. If most of
                3GPP people think it is not so needed I couldn’t
                understand why it shall be mandatory.

            
 

            
From technical point of view, in the case
                realm based report type is not needed, nothing wrong
                without this AVP, and even better and cleaner.

            
 

            
And you ever said you have preference but
                ok with either way forward, i.e., make it mandatory or
                optional. Then let’s move on with the draft as it is on
                this point, if you agree. 

            
 

            
Best Regards,

            
Susan

            
 

            

              

                
From: Steve Donovan [mailto:srdonovan@usdonovans.com]
                    

                    Sent: Tuesday, March 25, 2014 8:39 PM

                    To: Shishufeng (Susan); Jouni Korhonen

                    Cc: dime@ietf.org

                    Subject: Re: [Dime] [dime] #54:
                    OC-Report-Type as mandatory AVP

              

            

            
 

            
Susan,

                

                We have not been following a process of determining
                consensus based on a majority of companies expressing a
                preference.  It is also the case that, in the IETF,
                companies do not contribute, individuals contribute.

                

                In addition, if we did take a "vote" on this one, I'm
                not sure which side would actually have a majority.

                

                We might need to change our process to speed things up,
                but right now we have been striving for true consensus
                where everyone agrees.  Note that this doesn't mean
                everyone agrees with the technical reasoning behind the
                decision.  There have been many cases where agreement is
                reached because it was more important to get something
                finished then to win a technical argument.

                

                If we can't start moving a little faster then we will
                likely need to change to rough consensus, where the
                measure is that most everyone agrees.  However, in the
                IETF, even this is not a voting process.  If things are
                close to 50-50 in opinions then the correct process is
                to continue to discuss the technical merits of each
                alternative until rough consensus is reached.

                

                Regards,

                

                Steve

            

              
On 3/25/14, 2:00
                  AM, Shishufeng (Susan) wrote:

            

            

              
Hi Steve,

              
 

              
As I know, majority companies expressed
                  preference to keep the AVP as optional and keep the
                  texts as they are. You have preference to have it
                  explicitly but ok with either way. That’s how I
                  assumed we reached consensus.

              
 

              
Best Regards,

              
Susan

              
 

              

                

                  
From: Steve Donovan [mailto:srdonovan@usdonovans.com]
                      

                      Sent: Monday, March 24, 2014 8:26 PM

                      To: Shishufeng (Susan); Jouni Korhonen

                      Cc: dime@ietf.org

                      Subject: Re: [Dime] [dime] #54:
                      OC-Report-Type as mandatory AVP

                

              

              
 

              
Susan,

                  

                  We are in the middle of the discussion and have not
                  yet reached consensus.

                  

                  I agree with Jouni on making it explicit.  Either way,
                  we should try to make a decision quickly.

                  

                  Steve

              

                
On 3/23/14 10:59
                    PM, Shishufeng (Susan) wrote:

              

              

                
Hello Jouni,

                
 

                
I assume we had a lot of discussion on this and reached consensus to keep it as it is in the draft. 

                
 

                
Best Regards,

                
Susan

                
 

                
 

                
-----Original Message-----

                
From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 

                
Sent: Saturday, March 22, 2014 10:38 AM

                
To: Steve Donovan

                
Cc: dime@ietf.org

                
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

                
 

                
 

                
Lets have it explicit then. Use '<' and '>' to make the position fixed.

                
 

                
- Jouni

                
 

                
On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

                
 

                

                  
I'm ok with either direction but generally lean toward being explicit.

                  
 

                  
Do we have other opinions?  

                  
 

                  
Steve

                  
On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

                  

                    
Hello,

                    
I think the agreement tendency is the contrary: OC-Report-Type is not required, while default value is Host. i.e. it will remain as it is now in the draft.

                    
This may be of some advantage for some applications that may only use Host, as long as they may never generate Realm reports.

                    
If there is consensus on this, I will go with this.

                    
Best regards

                    
/MCruz

                    
 

                    
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

                    
Sent: martes, 18 de marzo de 2014 17:47

                    
To: dime@ietf.org

                    
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
All,

                    
 

                    
Do we have consensus that the OC-Report-Type AVP is required?

                    
 

                    
If so then one change would be as indicated in the syntax definition proposed by Lionel.  We would also remove wording on the default value.

                    
 

                    
Jouni,

                    
 

                    
How do we indicate a fixed position for an AVP?  

                    
 

                    
I presonally don't see this as critical but we can add this requirement if there is consensus.

                    
 

                    
Regards,

                    
 

                    
Steve

                    
 

                    
On 2/28/14 10:27 AM, Jouni Korhonen wrote:

                    
 

                    
Hi,

                    
 

                    
How having the AVP could be less error prone if it has a default 

                    
value and the receiver knows exactly how to proceed when the AVP is 

                    
not present?

                    
 

                    
If a node does not include it when it should, the implementation is 

                    
broken. Wouldn't a broken node be able to put wrong report type into 

                    
the AVP even if the AVP is mandatory?

                    
 

                    
Anyway, if it is my statement keeping issue #54 still open, consider 

                    
it resolved from my side. I am OK making the OC-Report-Type AVP as 

                    
required/mandatory AVP. Should we also consider it having a fixed 

                    
position just after the OC-Sequence-Number AVP as well since it is 

                    
going to in every OC-OLR?

                    
 

                    
- Jouni

                    
 

                    
 

                    
 

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

                    
 

                    
 

                    
Hello all,

                    
 

                    
I understand JJ point of view, but I still tend to prefer to make it mandatory, since I think this is less error-prone, since the only node that knows the requested Report-Type is the reporting, if for any reason a reporting is omitting it (since it is optional), it will be always interpreted as HOST, but this type may be wrong.

                    
 

                    
I think DEFAULT values should never be error-prone, but used in "general cases", as a simplification, like e.g. a default for the Validity-Duration. Default Validity-Duration will never be an "error", it could be not the best value (compared with another value perfectly tuned to reporting node overload situation) but never the use of a Default value should lead to an erroneous behavior.

                    
 

                    
Best regards

                    
/MCruz

                    
 

                    
-----Original Message-----

                    
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

                    
Sent: viernes, 14 de febrero de 2014 23:13

                    
To: Jouni Korhonen

                    
Cc: dime@ietf.org

                    
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
I actually prefer making it mandatory. The cost of adding it is trivial--even more so for a reporting node that only supports the default. The value of having it is less opportunity for interop errors.

                    
 

                    
On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:

                    
 

                    
 

                    
Agree that it is a small optimization, which I put there because at 

                    
the beginning there seemed to be a lot of worry on every extra AVP 

                    
;-)

                    
 

                    
I prefer having the AVP optional but with a default value just like 

                    
it is now. We have the same for the reduction percentage and the 

                    
validity time as well.

                    
 

                    
- Jouni

                    
 

                    
On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:

                    
 

                    
Hi Mcruz

                    
 

                    
The current description indicates that when not present the OLR is of type Host, which was fine for me and keeps my preference. 

                    
We may have  deployments where Realm OLR is not used, or where statistically the HOST type is the most frequent, so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is a small optimization.

                    
 

                    
Best regards

                    
 

                    
JJacques

                    
 

                    
 

                    
 

                    
 

                    
-----Message d'origine-----

                    
De : DiME [mailto:dime-bounces@ietf.org] De la part de 

                    
lionel.morand@orange.com Envoyé : mercredi 12 février 2014 15:46 À :

                    
dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime] 

                    
[dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
Hi Maria Cruz,

                    
 

                    
I'm assuming that you mean "required" instead of "mandatory", right?

                    
 

                    
So instead of:

                    
 

                    
OC-OLR ::= < AVP Header: TBD2 >

                    
           < OC-Sequence-Number >

                    
           [ OC-Report-Type ]

                    
           [ OC-Reduction-Percentage ]

                    
           [ OC-Validity-Duration ]

                    
         * [ AVP ]

                    
 

                    
You would prefer:

                    
 

                    
OC-OLR ::= < AVP Header: TBD2 >

                    
           < OC-Sequence-Number >

                    
           { OC-Report-Type }

                    
           [ OC-Reduction-Percentage ]

                    
           [ OC-Validity-Duration ]

                    
         * [ AVP ]

                    
 

                    
And I'm fine with this proposal.

                    
 

                    
Cheers,

                    
 

                    
Lionel

                    
 

                    
-----Message d'origine-----

                    
De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue 

                    
tracker Envoyé : mercredi 12 février 2014 15:26 À :

                    
maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] 

                    
[dime] #54: OC-Report-Type as mandatory AVP

                    
 

                    
#54: OC-Report-Type as mandatory AVP

                    
 

                    
Now in chapter 4.6:

                    
 

                    
 The default value of the OC-Report-Type AVP is 0 (i.e. the host  

                    
report).

                    
 

                    
This AVP is always required, right? Then, I think it is more precise that  we define this AVP as mandatory.

                    
 

                    
--

                    
-----------------------------------------------+---------------------

                    
-----------------------------------------------+---

                    
-----------------------------------------------+---

                    
Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

                    
  Type:  defect                             |  Bartolomé

                    
Priority:  major                              |     Status:  new

                    
Component:  draft-docdt-dime-ovli              |  Milestone:

                    
Severity:  Active WG Document                 |    Version:  1.0

                    
                                            |   Keywords:

                    
-----------------------------------------------+---------------------

                    
-----------------------------------------------+---

                    
-----------------------------------------------+---

                    
 

                    
Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54>

                    
dime <http://tools.ietf.org/wg/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

                    
 

                    
 

                  

                  
 

                  
_______________________________________________

                  
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.

      

    

    

  


--------------090401030006050805010806--


From nobody Wed Mar 26 05:23:09 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 C72521A018B for ; Wed, 26 Mar 2014 05:23:07 -0700 (PDT)
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 MFp2AtS9ADhR for ; Wed, 26 Mar 2014 05:23:05 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 92B8F1A0084 for ; Wed, 26 Mar 2014 05:23:05 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62337 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSmrF-0000u9-Tb for dime@ietf.org; Wed, 26 Mar 2014 05:23:03 -0700
Message-ID: <5332C6A6.40700@usdonovans.com>
Date: Wed, 26 Mar 2014 07:23:02 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2014@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030004020109050509090309"
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/qG2eZkKL9QZCelvgLURolLtOAyU
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 12:23:08 -0000

This is a multi-part message in MIME format.
--------------030004020109050509090309
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

This text is not normative so a reporting node can create the OCS
anytime it wishes.  It is very much an implementation decision.

The value of this text is that it helps to explain the DOIC mechanism. 

Regards,

Steve


On 3/26/14 2:56 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi Ulrich
>
> I agree with your example: so with an OCS that can be defined per application and algorithm.
> Nevertheless a remark, I think this OCS exists only when the algorithm has been selected. I do not see the case of an OCS with a supported but not selected algorithm. I may miss something.
>
> So wording in 5.5.1.2 could be:
> 	A reporting node maintains per supported Diameter application and per
>     selected Abatement Algorithm an Overload
>     Control State....
>  
> This does  not remove my questioning about the per client case: pease see the other mail
>
> Best regards
>
> JJacques
>
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
> Envoyé : mardi 25 mars 2014 09:08
> À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
> Objet : RE: issue #56 proposed conclusion
>
> Hi JJacques,
>
> let me try to give an example:
>
> Client C1 supports algorithms A1 and A2.
> Server S supports algorithms A1 and A2.
> Client C2 supports only algorithm A1.
>
> C1 sends an application x request indicating support of A1 and A2 to the server S.
> Now S selects one single algorithm (in this example A2) and requests some reduction using A2.  S has a OCS identified by the pair (x,A2).
>
> Now client C2 sends an application x request indicating support of A1 to S. 
> Again S selects one single algorithm (in this case A1) and requests some reduction using A1. S has an OCS identified by the pair (x,A1).
>
> In summary it is right that S selects one single algorithm out of the set of adveritzed algorithms, but this does not mean that S must only maintain one OCS.
>
> Best regards
> Ulrich
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: Monday, March 24, 2014 7:08 PM
> To: dime@ietf.org
> Subject: Re: [Dime] issue #56 proposed conclusion
>
> Hi Ulrich
>
> In 5.5.1.2 you wrote:
> 	A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State
>
> but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become
>
>      ...per supported Diameter application and for the
>     selected Abatement Algorithm.... 
>
>
> I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 
>
> Interest of this text is that it clarifies the node behaviors.
>
> Best regards
>
> JJacques  
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion
>
> Dear all,
>
> I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
> I'm fine with not abbreviating "Overload Control State".
>
> I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
> Ulrich
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich)
> Sent: Thursday, March 20, 2014 2:08 PM
> To: dime@ietf.org
> Subject: issue #56 proposed conclusion
>
> #56: Bad Description of Overload Control State
>
>
> Dear all,
>
> I have received comments from Steve, MCruz and Jouni.
>
> I believe all comments are covered by the following proposed text:
>
>
>
>     5.5.1.  Overload Control State (OCS)
>
>     5.5.1.1   Overload Control States for reacting nodes
>
>     A reacting node 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 towards
>       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 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
>     following information:
>     - Sequence number (as reveived in OC-OLR)
>     - Time of expiry  (deviated from validity duration as received in OC-OLR
>       and time of reception)
>     - Selected Abatement Algorithm (as received in OC-Supported-Features)
>     - Algorithm specific input data (as received within OC-OLR, e.g.
>       Reduction Percentage for Loss)
>
>    
>     5.5.1.2   Overload Control States for reporting nodes
>
>     A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State. 
>
>     An Overload Control State may be identified by the pair of Application-Id
>     and supported Abatement Algorithm.
>
>     The Overload Control State for a given pair of Application and Abatement
>     Algorithm could include the information:
>     - Sequence number
>     - Validity Duration and Expiry Time
>     - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>     
>     5.5.1.3  Maintaining Overload Control States
>
>     Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>     an answer message of application app-id containing an Orig-Host of host-id and a
>     host-type OC-OLR AVP unless such host-type OCS already exists.
>
>     Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>     an answer message of application app-id containing an Orig-Realm of realm-id and a
>     realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>     Reacting nodes delete an OCS when it expires (i.e. when current time
>     minus reception time is greater than validity duration).
>
>     Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>     receiving an answer message of application app-id containing an Orig-Host of
>     host-id and a host-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>     receiving an answer message of application app-id containing an Orig-Realm of
>     realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>     request of application app-id containing an OC-Supported-Features AVP
>     indicating support of the Abatement Algorithm Alg (which the reporting
>     node selects) while being overloaded, unless such OCS already exists.
>
>     Reporting nodes delete an OCS when it expires.
>
>     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>     need to modify the requested amount of application app-id traffic reduction.
>
> 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
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>


--------------030004020109050509090309
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      This text is not normative so a reporting node can create the OCS
      anytime it wishes.  It is very much an implementation decision.

      

      The value of this text is that it helps to explain the DOIC
      mechanism.  

      

      Regards,

      

      Steve

      

      

    
    
On 3/26/14 2:56 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
Hi Ulrich

I agree with your example: so with an OCS that can be defined per application and algorithm.
Nevertheless a remark, I think this OCS exists only when the algorithm has been selected. I do not see the case of an OCS with a supported but not selected algorithm. I may miss something.

So wording in 5.5.1.2 could be:
	A reporting node maintains per supported Diameter application and per
    selected Abatement Algorithm an Overload
    Control State....
 
This does  not remove my questioning about the per client case: pease see the other mail

Best regards

JJacques


-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Envoyé : mardi 25 mars 2014 09:08
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet : RE: issue #56 proposed conclusion

Hi JJacques,

let me try to give an example:

Client C1 supports algorithms A1 and A2.
Server S supports algorithms A1 and A2.
Client C2 supports only algorithm A1.

C1 sends an application x request indicating support of A1 and A2 to the server S.
Now S selects one single algorithm (in this example A2) and requests some reduction using A2.  S has a OCS identified by the pair (x,A2).

Now client C2 sends an application x request indicating support of A1 to S. 
Again S selects one single algorithm (in this case A1) and requests some reduction using A1. S has an OCS identified by the pair (x,A1).

In summary it is right that S selects one single algorithm out of the set of adveritzed algorithms, but this does not mean that S must only maintain one OCS.

Best regards
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:08 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm.... 


I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques  


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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 towards
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OLR
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

   
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State. 

    An Overload Control State may be identified by the pair of Application-Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatement
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

    
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of realm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
    receiving an answer message of application app-id containing an Orig-Host of
    host-id and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Realm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
    need to modify the requested amount of application app-id traffic reduction.

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

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



    

    

  


--------------030004020109050509090309--


From nobody Wed Mar 26 05:25: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 B970A1A02DF for ; Wed, 26 Mar 2014 05:25:53 -0700 (PDT)
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 RVLoLLhWupIP for ; Wed, 26 Mar 2014 05:25:50 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id E1C411A0084 for ; Wed, 26 Mar 2014 05:25:50 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62340 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSmtv-00041P-22 for dime@ietf.org; Wed, 26 Mar 2014 05:25:48 -0700
Message-ID: <5332C74B.3000303@usdonovans.com>
Date: Wed, 26 Mar 2014 07:25:47 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030101030008020809060506"
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/Ybj9M4fMns5R8CqvuJ0IRxe8y8Y
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 12:25:54 -0000

This is a multi-part message in MIME format.
--------------030101030008020809060506
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

Please see inline.

Steve

On 3/26/14 2:58 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi Ulrich
>
> 1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.
> For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.
>
> So I propose  to evolve your definition
>    
> A reporting node maintains per supported Diameter application, per
>     selected Abatement Algorithm and eventually per client if relevant an Overload
>     Control State
SRD> I agree with the per algorithm, but I don't think we need the word
selected.  I also don't think we need the  "... and eventually" part. 
That can be added if and when we have that extension mechanism defined.
>
> Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.
>
>
> 2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    
SRD> I thought OCS per report type was already there.
>
>
> Best regards 
>
> JJacques 
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
> Envoyé : mardi 25 mars 2014 09:24
> À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
> Objet : RE: issue #56 proposed conclusion
>
> Hi JJacques
>
> Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.
>
> The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.
> With this (partial) solution of #35 there would not be any impact to my proposal for #56.
>
> Best regards
> Ulrich
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: Monday, March 24, 2014 7:43 PM
> To: dime@ietf.org
> Subject: Re: [Dime] issue #56 proposed conclusion
>
> Hi Ulrich and all
>
> Still to complement my remark about question of the mitigation for a given client 
>
> Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)
>
> I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 
>
> So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.
>
> This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.
>
> Best regards 
>
> JJacques   
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion
>
> Hi Ulrich
>
> In 5.5.1.2 you wrote:
> 	A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State
>
> but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become
>
>      ...per supported Diameter application and for the
>     selected Abatement Algorithm.... 
>
>
> I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 
>
> Interest of this text is that it clarifies the node behaviors.
>
> Best regards
>
> JJacques  
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion
>
> Dear all,
>
> I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
> I'm fine with not abbreviating "Overload Control State".
>
> I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
> Ulrich
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich)
> Sent: Thursday, March 20, 2014 2:08 PM
> To: dime@ietf.org
> Subject: issue #56 proposed conclusion
>
> #56: Bad Description of Overload Control State
>
>
> Dear all,
>
> I have received comments from Steve, MCruz and Jouni.
>
> I believe all comments are covered by the following proposed text:
>
>
>
>     5.5.1.  Overload Control State (OCS)
>
>     5.5.1.1   Overload Control States for reacting nodes
>
>     A reacting node 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 towards
>       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 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
>     following information:
>     - Sequence number (as reveived in OC-OLR)
>     - Time of expiry  (deviated from validity duration as received in OC-OLR
>       and time of reception)
>     - Selected Abatement Algorithm (as received in OC-Supported-Features)
>     - Algorithm specific input data (as received within OC-OLR, e.g.
>       Reduction Percentage for Loss)
>
>    
>     5.5.1.2   Overload Control States for reporting nodes
>
>     A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State. 
>
>     An Overload Control State may be identified by the pair of Application-Id
>     and supported Abatement Algorithm.
>
>     The Overload Control State for a given pair of Application and Abatement
>     Algorithm could include the information:
>     - Sequence number
>     - Validity Duration and Expiry Time
>     - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>     
>     5.5.1.3  Maintaining Overload Control States
>
>     Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>     an answer message of application app-id containing an Orig-Host of host-id and a
>     host-type OC-OLR AVP unless such host-type OCS already exists.
>
>     Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>     an answer message of application app-id containing an Orig-Realm of realm-id and a
>     realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>     Reacting nodes delete an OCS when it expires (i.e. when current time
>     minus reception time is greater than validity duration).
>
>     Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>     receiving an answer message of application app-id containing an Orig-Host of
>     host-id and a host-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>     receiving an answer message of application app-id containing an Orig-Realm of
>     realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>     request of application app-id containing an OC-Supported-Features AVP
>     indicating support of the Abatement Algorithm Alg (which the reporting
>     node selects) while being overloaded, unless such OCS already exists.
>
>     Reporting nodes delete an OCS when it expires.
>
>     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>     need to modify the requested amount of application app-id traffic reduction.
>
> 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
>
> _______________________________________________
> 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
>


--------------030101030008020809060506
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      Please see inline.

      

      Steve

      

    
    
On 3/26/14 2:58 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
Hi Ulrich

1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.
For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.

So I propose  to evolve your definition
   
A reporting node maintains per supported Diameter application, per
    selected Abatement Algorithm and eventually per client if relevant an Overload
    Control State

    

    SRD> I agree with the per algorithm, but I don't think we need
    the word selected.  I also don't think we need the  "... and
    eventually" part.  That can be added if and when we have that
    extension mechanism defined.

    

      

Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.


2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    

    

    SRD> I thought OCS per report type was already there.

    

      


Best regards 

JJacques 

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Envoyé : mardi 25 mars 2014 09:24
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet : RE: issue #56 proposed conclusion

Hi JJacques

Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.

The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.
With this (partial) solution of #35 there would not be any impact to my proposal for #56.

Best regards
Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given client 

Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 

So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.

Best regards 

JJacques   


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm.... 


I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques  


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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 towards
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OLR
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

   
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State. 

    An Overload Control State may be identified by the pair of Application-Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatement
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

    
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of realm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
    receiving an answer message of application app-id containing an Orig-Host of
    host-id and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Realm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
    need to modify the requested amount of application app-id traffic reduction.

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

_______________________________________________
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



    

    

  


--------------030101030008020809060506--


From nobody Wed Mar 26 05:27: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 D2A761A02A9 for ; Wed, 26 Mar 2014 05:27:39 -0700 (PDT)
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 XtZ6hU4v8AHZ for ; Wed, 26 Mar 2014 05:27:36 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 412211A018B for ; Wed, 26 Mar 2014 05:27:36 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62347 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSmvc-0005q1-8i for dime@ietf.org; Wed, 26 Mar 2014 05:27:33 -0700
Message-ID: <5332C7B4.4060805@usdonovans.com>
Date: Wed, 26 Mar 2014 07:27:32 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020306090500010901060706"
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/3OgTzpo8_HFKorMu-Psdxg7oRog
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 12:27:40 -0000

This is a multi-part message in MIME format.
--------------020306090500010901060706
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

I am not in favor of your suggestion.  I won't restate -- its in my
previous email.

Steve

On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Hi Ulrich
>
> 1) I understand and agree it is good to have a text in v02 on OCS definition. #35 will deal on the protocol aspects about DOIC information transfer for client mitigation in te loss algorithm context .  But regarding OCS definition I prefer to have the OCS definition currently covering a larger scope that may be reviewed if needed in 03 than to do the reverse. For loss algorithm, in the dedicated part for loss that Ben mentioned, we can later add that the per client OCS case would be used for a specific client mitigation. For  other algorithms (eg rate control) we will see which type of OCS to apply , but it will remain compliant with the general definition. So I remain in favor of my proposal, why not to introduce it?
>
> 2) about realm OCS, it is to identify the OCS associated to the generation of a realm OLR, as this OCS will store the 
> Reduction percentage for the realm.
>
> Best regards
>
> JJacques   
>
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
> Envoyé : mercredi 26 mars 2014 09:26
> À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
> Objet : RE: issue #56 proposed conclusion
>
> Hi JJacques,
>
> In order to meet Steve's deadline for the 02-draft I would like to close #56 as proposed by Steve.
> This does not mean that we cannot improve text for 03.
>
> Ad 1) I don't think that the definition of OCS is Loss specific. Whether we need client-specific OCS should be discussed under #35. As we have it now there is one OCS shared for all reacting nodes with which the same algorithm was negotiated.
> This of course limits agents taking the role of a reacting node for two clients C1 and C2 to advertize the same set of algorithm, and reacting nodes to select the algorithm based on the set of advertized algorithm and not based on the client.
>
> Ad 2) The current text assumes that a reporting node is located in just one realm. If that is not the case OCSs need to be maintained per realm. We may want to look at this when working on 03.
>
> Best regards
> Ulrich
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: Wednesday, March 26, 2014 8:59 AM
> To: dime@ietf.org
> Subject: Re: [Dime] issue #56 proposed conclusion
>
> Hi Ulrich
>
> 1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.
> For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.
>
> So I propose  to evolve your definition
>    
> A reporting node maintains per supported Diameter application, per
>     selected Abatement Algorithm and eventually per client if relevant an Overload
>     Control State
>
> Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.
>
>
> 2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    
>
>
> Best regards 
>
> JJacques 
>
> -----Message d'origine-----
> De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: issue #56 proposed conclusion
>
> Hi JJacques
>
> Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.
>
> The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.
> With this (partial) solution of #35 there would not be any impact to my proposal for #56.
>
> Best regards
> Ulrich
>
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
> Sent: Monday, March 24, 2014 7:43 PM
> To: dime@ietf.org
> Subject: Re: [Dime] issue #56 proposed conclusion
>
> Hi Ulrich and all
>
> Still to complement my remark about question of the mitigation for a given client 
>
> Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)
>
> I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 
>
> So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.
>
> This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.
>
> Best regards 
>
> JJacques   
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion
>
> Hi Ulrich
>
> In 5.5.1.2 you wrote:
> 	A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State
>
> but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become
>
>      ...per supported Diameter application and for the
>     selected Abatement Algorithm.... 
>
>
> I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 
>
> Interest of this text is that it clarifies the node behaviors.
>
> Best regards
>
> JJacques  
>
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion
>
> Dear all,
>
> I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
> I'm fine with not abbreviating "Overload Control State".
>
> I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
> Ulrich
>
> -----Original Message-----
> From: Wiehe, Ulrich (NSN - DE/Munich)
> Sent: Thursday, March 20, 2014 2:08 PM
> To: dime@ietf.org
> Subject: issue #56 proposed conclusion
>
> #56: Bad Description of Overload Control State
>
>
> Dear all,
>
> I have received comments from Steve, MCruz and Jouni.
>
> I believe all comments are covered by the following proposed text:
>
>
>
>     5.5.1.  Overload Control State (OCS)
>
>     5.5.1.1   Overload Control States for reacting nodes
>
>     A reacting node 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 towards
>       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 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
>     following information:
>     - Sequence number (as reveived in OC-OLR)
>     - Time of expiry  (deviated from validity duration as received in OC-OLR
>       and time of reception)
>     - Selected Abatement Algorithm (as received in OC-Supported-Features)
>     - Algorithm specific input data (as received within OC-OLR, e.g.
>       Reduction Percentage for Loss)
>
>    
>     5.5.1.2   Overload Control States for reporting nodes
>
>     A reporting node maintains per supported Diameter application and per
>     supported (and eventually selected) Abatement Algorithm an Overload
>     Control State. 
>
>     An Overload Control State may be identified by the pair of Application-Id
>     and supported Abatement Algorithm.
>
>     The Overload Control State for a given pair of Application and Abatement
>     Algorithm could include the information:
>     - Sequence number
>     - Validity Duration and Expiry Time
>     - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>     
>     5.5.1.3  Maintaining Overload Control States
>
>     Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>     an answer message of application app-id containing an Orig-Host of host-id and a
>     host-type OC-OLR AVP unless such host-type OCS already exists.
>
>     Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>     an answer message of application app-id containing an Orig-Realm of realm-id and a
>     realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>     Reacting nodes delete an OCS when it expires (i.e. when current time
>     minus reception time is greater than validity duration).
>
>     Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>     receiving an answer message of application app-id containing an Orig-Host of
>     host-id and a host-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>     receiving an answer message of application app-id containing an Orig-Realm of
>     realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>     stored sequence number.
>
>     Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>     request of application app-id containing an OC-Supported-Features AVP
>     indicating support of the Abatement Algorithm Alg (which the reporting
>     node selects) while being overloaded, unless such OCS already exists.
>
>     Reporting nodes delete an OCS when it expires.
>
>     Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>     need to modify the requested amount of application app-id traffic reduction.
>
> 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
>
> _______________________________________________
> 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
>


--------------020306090500010901060706
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      I am not in favor of your suggestion.  I won't restate -- its in
      my previous email.

      

      Steve

      

    
    
On 3/26/14 3:51 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
Hi Ulrich

1) I understand and agree it is good to have a text in v02 on OCS definition. #35 will deal on the protocol aspects about DOIC information transfer for client mitigation in te loss algorithm context .  But regarding OCS definition I prefer to have the OCS definition currently covering a larger scope that may be reviewed if needed in 03 than to do the reverse. For loss algorithm, in the dedicated part for loss that Ben mentioned, we can later add that the per client OCS case would be used for a specific client mitigation. For  other algorithms (eg rate control) we will see which type of OCS to apply , but it will remain compliant with the general definition. So I remain in favor of my proposal, why not to introduce it?

2) about realm OCS, it is to identify the OCS associated to the generation of a realm OLR, as this OCS will store the 
Reduction percentage for the realm.

Best regards

JJacques   


-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Envoyé : mercredi 26 mars 2014 09:26
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org
Objet : RE: issue #56 proposed conclusion

Hi JJacques,

In order to meet Steve's deadline for the 02-draft I would like to close #56 as proposed by Steve.
This does not mean that we cannot improve text for 03.

Ad 1) I don't think that the definition of OCS is Loss specific. Whether we need client-specific OCS should be discussed under #35. As we have it now there is one OCS shared for all reacting nodes with which the same algorithm was negotiated.
This of course limits agents taking the role of a reacting node for two clients C1 and C2 to advertize the same set of algorithm, and reacting nodes to select the algorithm based on the set of advertized algorithm and not based on the client.

Ad 2) The current text assumes that a reporting node is located in just one realm. If that is not the case OCSs need to be maintained per realm. We may want to look at this when working on 03.

Best regards
Ulrich


-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Wednesday, March 26, 2014 8:59 AM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.
For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.

So I propose  to evolve your definition
   
A reporting node maintains per supported Diameter application, per
    selected Abatement Algorithm and eventually per client if relevant an Overload
    Control State

Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.


2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    


Best regards 

JJacques 

-----Message d'origine-----
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: issue #56 proposed conclusion

Hi JJacques

Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.

The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.
With this (partial) solution of #35 there would not be any impact to my proposal for #56.

Best regards
Ulrich



-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Monday, March 24, 2014 7:43 PM
To: dime@ietf.org
Subject: Re: [Dime] issue #56 proposed conclusion

Hi Ulrich and all

Still to complement my remark about question of the mitigation for a given client 

Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)

I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 

So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.

This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.

Best regards 

JJacques   


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

Hi Ulrich

In 5.5.1.2 you wrote:
	A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State

but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become

     ...per supported Diameter application and for the
    selected Abatement Algorithm.... 


I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 

Interest of this text is that it clarifies the node behaviors.

Best regards

JJacques  


-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

Dear all,

I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

I'm fine with not abbreviating "Overload Control State".

I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

Ulrich

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich)
Sent: Thursday, March 20, 2014 2:08 PM
To: dime@ietf.org
Subject: issue #56 proposed conclusion

#56: Bad Description of Overload Control State


Dear all,

I have received comments from Steve, MCruz and Jouni.

I believe all comments are covered by the following proposed text:



    5.5.1.  Overload Control State (OCS)

    5.5.1.1   Overload Control States for reacting nodes

    A reacting node 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 towards
      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 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
    following information:
    - Sequence number (as reveived in OC-OLR)
    - Time of expiry  (deviated from validity duration as received in OC-OLR
      and time of reception)
    - Selected Abatement Algorithm (as received in OC-Supported-Features)
    - Algorithm specific input data (as received within OC-OLR, e.g.
      Reduction Percentage for Loss)

   
    5.5.1.2   Overload Control States for reporting nodes

    A reporting node maintains per supported Diameter application and per
    supported (and eventually selected) Abatement Algorithm an Overload
    Control State. 

    An Overload Control State may be identified by the pair of Application-Id
    and supported Abatement Algorithm.

    The Overload Control State for a given pair of Application and Abatement
    Algorithm could include the information:
    - Sequence number
    - Validity Duration and Expiry Time
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

    
    5.5.1.3  Maintaining Overload Control States

    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
    an answer message of application app-id containing an Orig-Host of host-id and a
    host-type OC-OLR AVP unless such host-type OCS already exists.

    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
    an answer message of application app-id containing an Orig-Realm of realm-id and a
    realm-type OC-OLR AVP unless such realm type OCS already exists.

    Reacting nodes delete an OCS when it expires (i.e. when current time
    minus reception time is greater than validity duration).

    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
    receiving an answer message of application app-id containing an Orig-Host of
    host-id and a host-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
    receiving an answer message of application app-id containing an Orig-Realm of
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
    stored sequence number.

    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
    request of application app-id containing an OC-Supported-Features AVP
    indicating support of the Abatement Algorithm Alg (which the reporting
    node selects) while being overloaded, unless such OCS already exists.

    Reporting nodes delete an OCS when it expires.

    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
    need to modify the requested amount of application app-id traffic reduction.

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

_______________________________________________
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



    

    

  


--------------020306090500010901060706--


From nobody Wed Mar 26 05:35: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 ED42D1A0326 for ; Wed, 26 Mar 2014 05:35:34 -0700 (PDT)
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 OOiWAvZ6eHKe for ; Wed, 26 Mar 2014 05:35:30 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6861A0327 for ; Wed, 26 Mar 2014 05:35:26 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62360 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSn3A-00066y-Kp for dime@ietf.org; Wed, 26 Mar 2014 05:35:23 -0700
Message-ID: <5332C989.6000504@usdonovans.com>
Date: Wed, 26 Mar 2014 07:35:21 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5331B195.9020402@usdonovans.com> <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020209020009080200000906"
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/6cBO-Sw2T59b_K3ifU5nUgDiv6w
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Wed, 26 Mar 2014 12:35:35 -0000

This is a multi-part message in MIME format.
--------------020209020009080200000906
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

I disagree with keeping the name Realm.  We had consensus on the name
change a long time ago. 

In addition, Lionel's email is not internally consistent.  I have
responded with proposed clarifications.

Steve

On 3/26/14 6:56 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi
>
>  
>
> With others, I share Lionel summary on this topic, and the v02 draft
> should be on this statement. I also agree with  Mcruz, for the
> meantime to keep the the "realm" report   name as it is in current  draft
>
> Then there can be a ticket about other ways to understand the  realm
>  report
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
> lionel.morand@orange.com
> *Envoyé :* mercredi 26 mars 2014 07:35
> *À :* Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/Munich);
> dime@ietf.org; Steve Donovan
> *Objet :* Re: [Dime] Resolution on action to discuss the need for
> Realm-Routed-Reports
>
>  
>
> Hi Steve,
>  
> In London, we ended up with the following proposal:
>  
> - ONLY two report types
> - "Host" that applies when destination-host is present in the request.
> - "Realm" that applies to any request sent to a realm, except when a destination-host is present in the request AND a "Host" applies for this destination-host.
>  
> About renaming "Realm" as "Realm-Routed-Request", no strong issue as soon as the principle above are kept.
>  
> The need for realm-based type that would apply to any request (even if a "Host" exists for a destination-host in the request) was challenged and not retained. Ben was supposed to lock you in a room and to convince you that this last report type was not needed.
>  
> Lionel 
>  
> Envoyé depuis mon Sony Xperia SP d'Orange
>  
> Steve Donovan > a écrit :
>  
>
> Consensus is obviously a fleeting and temporary thing.
>
> Let us make sure that we are precise in our definitions of the report
> types we are discussing.
>
> Host report - Applies when the destination-host AVP is present in the
> request.
> Realm-Routed-Request (RRR) - Applies when there is no destination-host
> AVP in the request.
> Realm - Applies to 100% of requests sent to the realm.
>
> These are the definitions used in our discussions in London and in
> various places in our email discussions. 
>
> Can we please agree to use these definitions going forward so we are
> all talking about the same thing.
>
> Regards,
>
> Steve
>
> On 3/25/14 10:27 AM, lionel.morand@orange.com
>  wrote:
>
>     Hi Maria Cruz, All,
>
>      
>
>     In the previous mail, you wrote:
>
>      
>
>     /That is, we have two reports, host and realm. /
>
>     /Host applies when Destination_host is present, and then it takes
>     precedence over Realm. If both are present, only Host is applied./
>
>     /Realm applies when only Destination_realm is present./
>
>      
>
>     And I agree with this statement. But I'm not sure that this is the
>     case discussed by Ulrich.
>
>      
>
>     Whatever the name of the realm report type, is there an agreement
>     on the description given above by Maria Cruz and discussed in London?
>
>      
>
>     Regards,
>
>      
>
>     Lionel
>
>      
>
>     *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Maria
>     Cruz Bartolome
>     *Envoyé :* mardi 25 mars 2014 16:21
>     *À :* Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan;
>     dime@ietf.org 
>     *Objet :* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Dear all,
>
>      
>
>     I support option 1 a well
>
>     Cheers
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of *Wiehe,
>     Ulrich (NSN - DE/Munich)
>     *Sent:* martes, 25 de marzo de 2014 16:15
>     *To:* ext Steve Donovan; dime@ietf.org 
>     *Subject:* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Steve,
>
>     Thank you for this summary.
>
>     Please see inline.
>
>      
>
>     Ulrich
>
>      
>
>     *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>     *Sent:* Tuesday, March 25, 2014 2:49 PM
>     *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>     
>     *Subject:* Re: [Dime] Resolution on action to discuss the need for
>     Realm-Routed-Reports
>
>      
>
>     Ulrich,
>
>     I mean going backwards from where I thought we were after the
>     London meeting.
>
>     We are clearly out of sync but hopefully we can fix that.
>
>     Here's my understanding of the status of #23 and #55.
>
>     Prior to London meeting:
>
>     #23 status:
>      - Agreement to change the name of existing realm reports to
>     realm-routed-reports (RRR).
>
>     this includes agreement to keep the (newly called)
>     realm-routed-reports
>      - Discussions were ongoing as to the need for both realm reports
>     and RRR reports.
>
>     I would say "...as to the need for realm reports in
>     addition to realm-routed-reports" 
>
>
>
>     #55 status:
>       - Agreement on adding Realm reports based on the definition that
>     realm reports apply to all traffic sent to the realm.
>
>     This is what I'm missing. The issue has been very briefly
>     discussed under #34 without conclusion. There was no discussion
>     under #55
>
>
>       - Limited discussion on the interaction between the new realm
>     reports and the existing host and RRR reports.
>
>     After London meeting:
>
>     #23 status:
>       - Tentative agreement in London meeting to remove RRR reports.
>
>     What was the technical argument?
>
>
>       - Ben expressed the strongest concern with this plan.  Steve and
>     Ben took action to discuss and come back with a recommendation. 
>
>     #55 status:
>       - No change
>
>     Summary:
>       - Tentative consensus reached to move forward with two report
>     types - host and realm, with realm having the new definition.
>     What was the technical argument?
>
>
>     Current status:
>
>     #23 status:
>      - Change the name to RRR
>      - Whether or not to remove RRR and revisit later or keep RRR and
>     revisit later is an open issue.
>
>     #55 status:
>       - My opinion is that we have at least rough consensus on the
>     need to support realm reports.  Others might have a different opinion.
>
>      There was no comment posted to issue #55, also no
>     proposed solution, so I cannot see where the consensus came
>     from
>
>
>
>     Summary:
>       - I believe we have three options:
>
>        1) Support host and RRR reports
>        2) Support host and Realm reports -- This was the tentative
>     plan coming out of the London meeting
>
>     < Ulrich> There is not even an issue number identifying problems
>     with RRR and proposing to remove RRR
>
>
>        3) Support host, RRR and Realm reports
>
>      I support option 1
>
>
>     Regards,
>
>     Steve
>
>     On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>         Steve,
>
>         I don't think we are going backwards (we may be out of synch
>         though)
>
>          
>
>         Can you please summarize the status of #23 and #55.
>
>          
>
>         Ulrich
>
>          
>
>          
>
>         *From:*ext Steve Donovan [mailto:srdonovan@usdonovans.com]
>         *Sent:* Monday, March 24, 2014 7:38 PM
>         *To:* Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
>         
>         *Subject:* Re: [Dime] Resolution on action to discuss the need
>         for Realm-Routed-Reports
>
>          
>
>         Ok, we are going backwards on this one.
>
>         I did not include option three because we had moved past that
>         option in our discussions, both on the list (I thought), and
>         in the meeting.
>
>         I believe that we had come to rough consensus on the need for
>         a realm report and the only remaining issue was whether we
>         also included the RRR report type.
>
>         At this point, the only option is to leave all of the issues
>         related to the report types open and attempt to resolve them
>         in the -03 draft.
>
>         Steve
>
>         On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>             Steve,
>
>              
>
>             I do not agree.
>
>              
>
>             We should still have the option
>
>             3) support report type 0 (this is called host report) and
>             support of report type 1 (this has been called relam
>             report but people argued it should better be called realm
>             routed request report).
>
>              
>
>             Whether or not we need in addition to type 0 and type 1
>             (or as a replacement of type 1) a
>             realm-no-matter-whether-destination-host-is present-or-not
>             report   is an open issue (see #55).
>
>             There are a lot of open questions  with regard to #55 and
>             I have not seen a conclusion.
>
>             Where I have seen a conclusion is issue #34 and that is
>             inline with option 3).
>
>              
>
>             Unless we conclude on #55, or decide to re-open #34,
>             option 3) is what should go in the -02 draft.
>
>              
>
>              
>
>             Ulrich
>
>              
>
>             *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>             *ext Steve Donovan
>             *Sent:* Monday, March 24, 2014 2:57 PM
>             *To:* dime@ietf.org 
>             *Subject:* Re: [Dime] Resolution on action to discuss the
>             need for Realm-Routed-Reports
>
>              
>
>             Ulrich,
>             All,
>
>             We have two options for the -02 draft.
>
>             1) Support Host and Realm as proposed below, removing RRR
>             reports.
>             2) Support Host, Realm and RRR reports.
>
>             The default plan is to go with option 1 in the -02 draft,
>             as that was the proposal that came out of the meeting in
>             London.  RRR reports can be added back in if and when we
>             are convinced of the need. 
>
>             If there are strong objections to this then I will update
>             the -02 draft to reflect all three report types.
>
>             I plan to make these updates Wednesday morning, Dallas,
>             Texas time.
>
>             Either way I do not expect we will have agreed to wording
>             on the interaction between the report types when a
>             reacting node has multiple report types, all of which
>             apply to individual requests.  This will need to be
>             addressed in the -03 draft.
>
>             Regards,
>
>             Steve
>
>             On 3/21/14 4:05 PM, Steve Donovan wrote:
>
>                 Ulrich,
>
>                 The discussion should be captured in the minutes to
>                 the meeting.  I wasn't able to find them posted yet.
>
>                 Jouni, Lionel, what is the status of the minutes for
>                 the meeting?
>
>                 My reading of emails prior to the London meeting is
>                 different from yours.  I believe we had come to the
>                 conclusion that we needed host and realm (with the
>                 definition of realm as outlined below).  We were still
>                 discussing the need for Realm-Routed-Request reports.
>
>                 Regards,
>
>                 Steve
>
>                 On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
>                 wrote:
>
>                     Steve,
>
>                      
>
>                     I don't know what happend in London.
>
>                     Can you please summarize the technical reasons
>                     that led to the London agreement.
>
>                     E-mail discussions prior to London have clearly
>                     directed towards a report type that requests
>                     throttling of realm routed request messages (i.e.
>                     not containing a destination host) rather than a
>                     report type that requests throttling of messages
>                     routed towards a realm (no matter whether they
>                     contain a destination host or not).   
>
>                      
>
>                     Ulrich
>
>                      
>
>                     *From:*DiME [mailto:dime-bounces@ietf.org] *On
>                     Behalf Of *ext Steve Donovan
>                     *Sent:* Friday, March 21, 2014 3:33 PM
>                     *To:* dime@ietf.org 
>                     *Subject:* [Dime] Resolution on action to discuss
>                     the need for Realm-Routed-Reports
>
>                      
>
>                     All,
>
>                     Ben and I took the action item to discuss the need
>                     for the Realm-Routed-Reports (RRR) report type.
>
>                     As you may recall, the consensus coming out of the
>                     DIME WG meeting in London was to support two
>                     report types:
>
>                     - Host -- Impacting requests with a
>                     Destination-Host AVP matching the host in the
>                     overload report (with the host implicitly
>                     determined from the Origin-Host AVP of the answer
>                     message carrying the overload report).
>
>                     - Realm -- Impacting 100% of the requests with a
>                     Destination-Realm AVP matching the realm in the
>                     overload report (with the realm implicitly
>                     determine from the Origin-Realm of the answer
>                     message carrying the overload report).
>
>                     The action Ben and I took was to come back with an
>                     opinion on whether RRR reports should also be
>                     supported.
>
>                     My summary of the discussion is that we recommend
>                     to NOT include RRR reports in the current version
>                     of the base DOIC draft. 
>
>                     We still have some concerns with the granularity
>                     of control enabled by having just the two report
>                     types but the analysis of whether RRR reports are
>                     still needed can occur independent of the base
>                     DOIC draft.  If there is a determination that RRRs
>                     are needed in time to include in the base draft
>                     then it can be considered at that time.
>
>                     Based on this, I propose the following
>
>                     - Resolution to issue #23 is to remove RRR reports
>                     from the document.
>                     - Resolution to issue #55 is to add Realm reports
>                     (actually to redefine them per the above definition).
>                     - Resolution to issue #57 is that it no longer
>                     applies (as it deals with RRRs).
>
>                     There is also need for text describing the
>                     interaction between host and the realm reports.  I
>                     don't expect we will have consensus on this
>                     wording prior to the -02 draft being submitted. 
>                     To this end, I'll open a new issue to deal with
>                     the need for wording on the interaction.
>
>                     Regards,
>
>                     Steve
>
>
>
>
>                 _______________________________________________
>
>                 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


--------------020209020009080200000906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    I disagree with keeping
      the name Realm.  We had consensus on the name change a long time
      ago.  

      

      In addition, Lionel's email is not internally consistent.  I have
      responded with proposed clarifications.

      

      Steve

      

    
    
On 3/26/14 6:56 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi
            

        
 

        
With
            others, I share Lionel summary on this topic, and the v02
            draft should be on this statement. I also agree with  Mcruz,
            for the meantime to keep the the “realm” report   name as it
            is in current  draft 

        
Then
            there can be a ticket about other ways to understand the
             realm  report
            

        
 

        
Best
            regards
            

        
 

        
JJacques
            

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de lionel.morand@orange.com

                Envoyé : mercredi 26 mars 2014 07:35

                À : Maria Cruz Bartolome; Wiehe, Ulrich (NSN -
                DE/Munich); dime@ietf.org; Steve Donovan

                Objet : Re: [Dime] Resolution on action to
                discuss the need for Realm-Routed-Reports

          

        

        
 

        
Hi Steve,

        
 

        
In London, we ended up with the following proposal:

        
 

        
- ONLY two report types

        
- "Host" that applies when destination-host is present in the request.

        
- "Realm" that applies to any request sent to a realm, except when a destination-host is present in the request AND a "Host" applies for this destination-host.

        
 

        
About renaming "Realm" as "Realm-Routed-Request", no strong issue as soon as the principle above are kept.

        
 

        
The need for realm-based type that would apply to any request (even if a "Host" exists for a destination-host in the request) was challenged and not retained. Ben was supposed to lock you in a room and to convince you that this last report type was not needed.

        
 

        
Lionel 

        
 

        
Envoyé depuis mon Sony Xperia SP d'Orange

        
 

        
Steve Donovan <srdonovan@usdonovans.com> a écrit :

        
 

        

          
Consensus is
            obviously a fleeting and temporary thing.

            

            Let us make sure that we are precise in our definitions of
            the report types we are discussing.

            

            Host report - Applies when the destination-host AVP is
            present in the request.

            Realm-Routed-Request (RRR) - Applies when there is no
            destination-host AVP in the request.

            Realm - Applies to 100% of requests sent to the realm.

            

            These are the definitions used in our discussions in London
            and in various places in our email discussions. 
            

            

            Can we please agree to use these definitions going forward
            so we are all talking about the same thing.

            

            Regards,

            

            Steve

          

            
On 3/25/14 10:27 AM, 
                lionel.morand@orange.com wrote:

          

          

            

              
Hi
                  Maria Cruz, All,

              
 

              
In
                  the previous mail, you wrote:

              
 

              
That
                    is, we have two reports, host and realm.
                  

              
Host
                    applies when Destination_host is present, and then
                    it takes precedence over Realm. If both are present,
                    only Host is applied.

              
Realm
                    applies when only Destination_realm is present.

              
 

              
And
                  I agree with this statement. But I'm not sure that
                  this is the case discussed by Ulrich.

              
 

              
Whatever
                  the name of the realm report type, is there an
                  agreement on the description given above by Maria Cruz
                  and discussed in London?

              
 

              
Regards,

              
 

              
Lionel

              
 

              

                

                  
De :
                      DiME [mailto:dime-bounces@ietf.org]
                      De la part de Maria Cruz Bartolome

                      Envoyé : mardi 25 mars 2014 16:21

                      À : Wiehe, Ulrich (NSN - DE/Munich); ext
                      Steve Donovan; 
                        dime@ietf.org

                      Objet : Re: [Dime] Resolution on action to
                      discuss the need for Realm-Routed-Reports

                

              

              
 

              
Dear
                  all,

              
 

              
I
                  support option 1 a well

              
Cheers

              
/MCruz

              
 

              

                

                  
From:
                      DiME [mailto:dime-bounces@ietf.org]
                      On Behalf Of Wiehe, Ulrich (NSN -
                      DE/Munich)

                      Sent: martes, 25 de marzo de 2014 16:15

                      To: ext Steve Donovan; dime@ietf.org

                      Subject: Re: [Dime] Resolution on action to
                      discuss the need for Realm-Routed-Reports

                

              

              
 

              
Steve,

              
Thank
                  you for this summary.

              
Please
                  see inline.

              
 

              
Ulrich

              
 

              

                

                  
From:
                      ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                      

                      Sent: Tuesday, March 25, 2014 2:49 PM

                      To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

                      Subject: Re: [Dime] Resolution on action to
                      discuss the need for Realm-Routed-Reports

                

              

              
 

              
Ulrich,

                  

                  I mean going backwards from where I thought we were
                  after the London meeting.

                  

                  We are clearly out of sync but hopefully we can fix
                  that.

                  

                  Here's my understanding of the status of #23 and #55.

                  

                Prior to London meeting:

                

                #23 status:

                 - Agreement to change the name of existing realm
                reports to realm-routed-reports (RRR).

              
<Ulrich>this
                  includes agreement to keep the (newly called)
                  realm-routed-reports</Ulrich>

                 - Discussions were ongoing as to the need for both
                realm reports and RRR reports.

              
<Ulrich>I
                  would say “…as to the need for realm reports in
                  addition to realm-routed-reports” </Ulrich>

              


                

                #55 status:

                  - Agreement on adding Realm reports based on the
                definition that realm reports apply to all traffic sent
                to the realm.

              
<Ulrich>This
                  is what I’m missing. The issue has been very briefly
                  discussed under #34 without conclusion. There was no
                  discussion under #55</Ulrich>

              


                  - Limited discussion on the interaction between the
                new realm reports and the existing host and RRR reports.

                

                After London meeting:

                  

                  #23 status:

                    - Tentative agreement in London meeting to remove
                  RRR reports.

              
<Ulrich>What
                  was the technical argument?</Ulrich>

              


                  - Ben expressed the strongest concern with this plan. 
                Steve and Ben took action to discuss and
                  come back with a recommendation. 
                  

                  

                  #55 status:

                    - No change

                  

                  Summary:

                    - Tentative consensus reached to move forward with
                  two report types - host and realm, with realm having
                  the new definition.

                <Ulrich>What
                  was the technical argument?</Ulrich>

              


                  Current status:

                  

                  #23 status:

                   - Change the name to RRR

                   - Whether or not to remove RRR and revisit later or
                  keep RRR and revisit later is an open issue.

                  

                  #55 status:

                    - My opinion is that we have at least rough
                  consensus on the need to support realm reports. 
                  Others might have a different opinion.

              
<Ulrich>
                  There was no comment posted to issue #55, also no
                  proposed solution, so I cannot see where the consensus
                  came from</Ulrich>

              


                

                Summary:

                  - I believe we have three options:

                

                   1) Support host and RRR reports

                   2) Support host and Realm reports -- This was the
                tentative plan coming out of the London meeting

              
<
                  Ulrich> There is not even an issue number
                  identifying problems with RRR and proposing to remove
                  RRR</Ulrich>

              


                   3) Support host, RRR and Realm reports

              
<Ulrich>
                  I support option 1</Ulrich>

              


                Regards,

                

                Steve

              

                
On 3/25/14 6:44 AM,
                    Wiehe, Ulrich (NSN - DE/Munich) wrote:

              

              

                
Steve,

                
I
                    don’t think we are going backwards (we may be out of
                    synch though)

                
 

                
Can
                    you please summarize the status of #23 and #55.

                
 

                
Ulrich

                
 

                
 

                

                  

                    
From:
                        ext Steve Donovan [mailto:srdonovan@usdonovans.com]
                        

                        Sent: Monday, March 24, 2014 7:38 PM

                        To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org

                        Subject: Re: [Dime] Resolution on action
                        to discuss the need for Realm-Routed-Reports

                  

                

                
 

                
Ok, we are going backwards on this one.

                    

                    I did not include option three because we had moved
                    past that option in our discussions, both on the
                    list (I thought), and in the meeting.
                    

                    

                    I believe that we had come to rough consensus on the
                    need for a realm report and the only remaining issue
                    was whether we also included the RRR report type.

                    

                    At this point, the only option is to leave all of
                    the issues related to the report types open and
                    attempt to resolve them in the -03 draft.

                    

                    Steve

                

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

                

                

                  
Steve,

                  
 

                  
I do not agree.

                  
 

                  
We
                      should still have the option
                    

                  
3)
                      support report type 0 (this is called host report)
                      and support of report type 1 (this has been called
                      relam report but people argued it should better be
                      called realm routed request report).

                  
 

                  
Whether
                      or not we need in addition to type 0 and type 1
                      (or as a replacement of type 1) a
                      realm-no-matter-whether-destination-host-is
                      present-or-not report   is an open issue (see
                      #55).

                  
There
                      are a lot of open questions  with regard to #55
                      and I have not seen a conclusion.

                  
Where
                      I have seen a conclusion is issue #34 and that is
                      inline with option 3).

                  
 

                  
Unless
                      we conclude on #55, or decide to re-open #34,
                      option 3) is what should go in the -02 draft.

                  
 

                  
 

                  
Ulrich

                  
 

                  

                    

                      
From:
                          DiME [mailto:dime-bounces@ietf.org]
                          On Behalf Of ext Steve Donovan

                          Sent: Monday, March 24, 2014 2:57 PM

                          To: dime@ietf.org

                          Subject: Re: [Dime] Resolution on
                          action to discuss the need for
                          Realm-Routed-Reports

                    

                  

                  
 

                  
Ulrich,

                      All,

                      

                      We have two options for the -02 draft.

                      

                      1) Support Host and Realm as proposed below,
                      removing RRR reports.

                      2) Support Host, Realm and RRR reports.

                      

                      The default plan is to go with option 1 in the -02
                      draft, as that was the proposal that came out of
                      the meeting in London.  RRR reports can be added
                      back in if and when we are convinced of the need. 
                      

                      

                      If there are strong objections to this then I will
                      update the -02 draft to reflect all three report
                      types.

                      

                      I plan to make these updates Wednesday morning,
                      Dallas, Texas time.

                      

                      Either way I do not expect we will have agreed to
                      wording on the interaction between the report
                      types when a reacting node has multiple report
                      types, all of which apply to individual requests. 
                      This will need to be addressed in the -03 draft.

                      

                      Regards,

                      

                      Steve

                  

                    
On 3/21/14 4:05
                        PM, Steve Donovan wrote:

                  

                  

                    
Ulrich,

                        

                        The discussion should be captured in the minutes
                        to the meeting.  I wasn't able to find them
                        posted yet.

                        

                        Jouni, Lionel, what is the status of the minutes
                        for the meeting?

                        

                        My reading of emails prior to the London meeting
                        is different from yours.  I believe we had come
                        to the conclusion that we needed host and realm
                        (with the definition of realm as outlined
                        below).  We were still discussing the need for
                        Realm-Routed-Request reports.

                        

                        Regards,

                        

                        Steve

                    

                      
On 3/21/14
                          10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
                          wrote:

                    

                    

                      
Steve,

                      
 

                      
I
                          don’t know what happend in London.

                      
Can
                          you please summarize the technical reasons
                          that led to the London agreement.
                        

                      
E-mail
                          discussions prior to London have clearly
                          directed towards a report type that requests
                          throttling of realm routed request messages
                          (i.e. not containing a destination host)
                          rather than a report type that requests
                          throttling of messages routed towards a realm
                          (no matter whether they contain a destination
                          host or not).   

                      
 

                      
Ulrich

                      
 

                      

                        

                          
From:
                              DiME [mailto:dime-bounces@ietf.org]
                              On Behalf Of ext Steve Donovan

                              Sent: Friday, March 21, 2014 3:33
                              PM

                              To: dime@ietf.org

                              Subject: [Dime] Resolution on
                              action to discuss the need for
                              Realm-Routed-Reports

                        

                      

                      
 

                      
All,

                          

                          Ben and I took the action item to discuss the
                          need for the Realm-Routed-Reports (RRR) report
                          type.

                          

                          As you may recall, the consensus coming out of
                          the DIME WG meeting in London was to support
                          two report types:

                          

                          - Host -- Impacting requests with a
                          Destination-Host AVP matching the host in the
                          overload report (with the host implicitly
                          determined from the Origin-Host AVP of the
                          answer message carrying the overload report).

                          

                          - Realm -- Impacting 100% of the requests with
                          a Destination-Realm AVP matching the realm in
                          the overload report (with the realm implicitly
                          determine from the Origin-Realm of the answer
                          message carrying the overload report).

                          

                          The action Ben and I took was to come back
                          with an opinion on whether RRR reports should
                          also be supported.

                          

                          My summary of the discussion is that we
                          recommend to NOT include RRR reports in the
                          current version of the base DOIC draft. 
                          

                          

                          We still have some concerns with the
                          granularity of control enabled by having just
                          the two report types but the analysis of
                          whether RRR reports are still needed can occur
                          independent of the base DOIC draft.  If there
                          is a determination that RRRs are needed in
                          time to include in the base draft then it can
                          be considered at that time.

                          

                          Based on this, I propose the following 

                          

                          - Resolution to issue #23 is to remove RRR
                          reports from the document.

                          - Resolution to issue #55 is to add Realm
                          reports (actually to redefine them per the
                          above definition).

                          - Resolution to issue #57 is that it no longer
                          applies (as it deals with RRRs).

                          

                          There is also need for text describing the
                          interaction between host and the realm
                          reports.  I don't expect we will have
                          consensus on this wording prior to the -02
                          draft being submitted.  To this end, I'll open
                          a new issue to deal with the need for wording
                          on the interaction.

                          

                          Regards,

                          

                          Steve 

                    

                    


                        

                        

                      

                    
_______________________________________________

                    
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


    

    

  


--------------020209020009080200000906--


From nobody Wed Mar 26 05:37:56 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 EEB6D1A032A for ; Wed, 26 Mar 2014 05:37:50 -0700 (PDT)
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 1GPpsLBA-IRL for ; Wed, 26 Mar 2014 05:37:46 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0851A0324 for ; Wed, 26 Mar 2014 05:37:46 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2QCbh2F008060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Mar 2014 07:37:44 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2QCbgGY013676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 13:37:42 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 13:37:42 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAAWgNwAAcxQhgADDx3RAAAVklwAABAxkAAAXouwAAAiVuwA==
Date: Wed, 26 Mar 2014 12:37:41 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net>  <5332C7B4.4060805@usdonovans.com>
In-Reply-To: <5332C7B4.4060805@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.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20267A7FEFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/09Z7V48avrZfZYUlgFau9ciky1U
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 12:37:51 -0000

--_000_E194C2E18676714DACA9C3A2516265D20267A7FEFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Steve

When reading your draft  about Rate control, we have
        The server must allocate a portion of the
   target Diameter request rate to each of its reacting nodes.  The
   server may set the same rate for every reacting node, or may set
   different rates for different reacting node.
I am OK with this statement. For me it implies  the reporting node (server)=
  to have a n OCS per reacting node if the rates are different .
So  I am a bit surprised you do not take this example  into account in the =
draft that should be future proof in its wording even if the OCS is not nor=
mative, but has a general meaning applicable to various algorithm and not o=
nly to the loss algorithm.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 26 mars 2014 13:28
=C0 : dime@ietf.org
Objet : Re: [Dime] issue #56 proposed conclusion

JJ,

I am not in favor of your suggestion.  I won't restate -- its in my previou=
s email.

Steve
On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi Ulrich



1) I understand and agree it is good to have a text in v02 on OCS definitio=
n. #35 will deal on the protocol aspects about DOIC information transfer fo=
r client mitigation in te loss algorithm context .  But regarding OCS defin=
ition I prefer to have the OCS definition currently covering a larger scope=
 that may be reviewed if needed in 03 than to do the reverse. For loss algo=
rithm, in the dedicated part for loss that Ben mentioned, we can later add =
that the per client OCS case would be used for a specific client mitigation=
. For  other algorithms (eg rate control) we will see which type of OCS to =
apply , but it will remain compliant with the general definition. So I rema=
in in favor of my proposal, why not to introduce it?



2) about realm OCS, it is to identify the OCS associated to the generation =
of a realm OLR, as this OCS will store the

Reduction percentage for the realm.



Best regards



JJacques





-----Message d'origine-----

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Envoy=E9 : mercredi 26 mars 2014 09:26

=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

Objet : RE: issue #56 proposed conclusion



Hi JJacques,



In order to meet Steve's deadline for the 02-draft I would like to close #5=
6 as proposed by Steve.

This does not mean that we cannot improve text for 03.



Ad 1) I don't think that the definition of OCS is Loss specific. Whether we=
 need client-specific OCS should be discussed under #35. As we have it now =
there is one OCS shared for all reacting nodes with which the same algorith=
m was negotiated.

This of course limits agents taking the role of a reacting node for two cli=
ents C1 and C2 to advertize the same set of algorithm, and reacting nodes t=
o select the algorithm based on the set of advertized algorithm and not bas=
ed on the client.



Ad 2) The current text assumes that a reporting node is located in just one=
 realm. If that is not the case OCSs need to be maintained per realm. We ma=
y want to look at this when working on 03.



Best regards

Ulrich





-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)

Sent: Wednesday, March 26, 2014 8:59 AM

To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion



Hi Ulrich



1) My point is that the definition of OCS should be sufficiently generic so=
 to apply to various algorithms. The current definition applies to the defa=
ult algorithm, but will need to be extended to support the overload mitigat=
ion for a specific  client.

For other algorithms, I mentioned the rate control as we will work on it. A=
nd in my previous mail example, with all clients and the server supporting =
selecting the rate control, I currently do not see how to not introduce OCS=
 per client somewhere (in the server or in a DA) to be able to run the rate=
 control.



So I propose  to evolve your definition



A reporting node maintains per supported Diameter application, per

    selected Abatement Algorithm and eventually per client if relevant an O=
verload

    Control State



Such a definition would be more generic and applicable to future algorithms=
. I think the draft should be future proof.





2) I am also questioning, if we have not the need to define an OCS per appl=
ication  per selected algorithm and per realm for a reporting node (eg  in =
the DA that is generating Realm reports for request without destination hos=
ts; realm OCS is only defined for reacting nodes in your proposal. Here aga=
in I would have  the additional question OCS eventually per client





Best regards



JJacques



-----Message d'origine-----

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy=E9=
 : mardi 25 mars 2014 09:24 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dim=
e@ietf.org Objet : RE: issue #56 proposed conclusion



Hi JJacques



Your concern is related to issue #35. For #35 we almost reached the conclus=
ion not to address client specific throttling in the 02-draft.



The latest proposal to solve #35 was to let clients indicate in OC-Supporte=
d-Features that they are clients; agents taking the role of reacting nodes =
on behalf of clients would not indicate  so. Servers must not request clien=
t specific throtting from reacting nodes that did not indicate that they ar=
e clients.

With this (partial) solution of #35 there would not be any impact to my pro=
posal for #56.



Best regards

Ulrich







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)

Sent: Monday, March 24, 2014 7:43 PM

To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion



Hi Ulrich and all



Still to complement my remark about question of the mitigation for a given =
client



Your description of state is defined per Application and Abatement, so not =
including the mitigation case of a state for a client (cf my previous mail)



I al trying to se how it would apply to another abatement algorithm. There =
is the rate control algorithm that we will study, and here I am questioning=
 if we will not be driven to have a state per client, as the requested rate=
 will be rather specific to a client, some clients may have a small traffic=
  and others a large traffic, meaning to define a requested rate per client=
 somewhere.



So I may again repeat myself that the normal state would be per client in g=
eneral, which does not exclude to group all clients and consider a state co=
mmon to all clients when relevant.



This may require some more thinking, but I prefer to remind this point, but=
 it also concern other tickets.



Best regards



JJacques





-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES) Envoy=E9 : lundi 24 mars 2014 19:08 =C0 : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion



Hi Ulrich



In 5.5.1.2 you wrote:

  A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State



but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become



     ...per supported Diameter application and for the

    selected Abatement Algorithm....





I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client



Interest of this text is that it clarifies the node behaviors.



Best regards



JJacques





-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich) Envoy=E9 : lundi 24 mars 2014 18:24 =C0 : Wiehe, Ulrich (NSN - =
DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #5=
6 proposed conclusion



Dear all,



I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".



I'm fine with not abbreviating "Overload Control State".



I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.



Ulrich



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich)

Sent: Thursday, March 20, 2014 2:08 PM

To: dime@ietf.org

Subject: issue #56 proposed conclusion



#56: Bad Description of Overload Control State





Dear all,



I have received comments from Steve, MCruz and Jouni.



I believe all comments are covered by the following proposed text:







    5.5.1.  Overload Control State (OCS)



    5.5.1.1   Overload Control States for reacting nodes



    A reacting node 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=
s

      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 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

    following information:

    - Sequence number (as reveived in OC-OLR)

    - Time of expiry  (deviated from validity duration as received in OC-OL=
R

      and time of reception)

    - Selected Abatement Algorithm (as received in OC-Supported-Features)

    - Algorithm specific input data (as received within OC-OLR, e.g.

      Reduction Percentage for Loss)





    5.5.1.2   Overload Control States for reporting nodes



    A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State.



    An Overload Control State may be identified by the pair of Application-=
Id

    and supported Abatement Algorithm.



    The Overload Control State for a given pair of Application and Abatemen=
t

    Algorithm could include the information:

    - Sequence number

    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Percentage for Loss)





    5.5.1.3  Maintaining Overload Control States



    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving

    an answer message of application app-id containing an Orig-Host of host=
-id and a

    host-type OC-OLR AVP unless such host-type OCS already exists.



    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving

    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a

    realm-type OC-OLR AVP unless such realm type OCS already exists.



    Reacting nodes delete an OCS when it expires (i.e. when current time

    minus reception time is greater than validity duration).



    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when

    receiving an answer message of application app-id containing an Orig-Ho=
st of

    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he

    stored sequence number.



    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when

    receiving an answer message of application app-id containing an Orig-Re=
alm of

    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the

    stored sequence number.



    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a

    request of application app-id containing an OC-Supported-Features AVP

    indicating support of the Abatement Algorithm Alg (which the reporting

    node selects) while being overloaded, unless such OCS already exists.



    Reporting nodes delete an OCS when it expires.



    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the

    need to modify the requested amount of application app-id traffic reduc=
tion.



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



_______________________________________________

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_E194C2E18676714DACA9C3A2516265D20267A7FEFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Steve


 <=
/p>

When reading your draft &=
nbsp;about Rate control, we have


       =
; The server must allocate a portion of the


   target Diameter request rate=
 to each of its reacting nodes.  The


   server may set the same rate=
 for every reacting node, or may set


   different rates for differen=
t reacting node.


I am OK with this stateme=
nt. For me it implies  the reporting node (server)  to have a n O=
CS per reacting node if the rates are different .


So  I am a bit surpr=
ised you do not take this example  into account in the draft that shou=
ld be future proof in its wording even if the OCS is not normative,
 but has a general meaning applicable to various algorithm and not only to =
the loss algorithm.


 <=
/p>

Best regards


 <=
/p>

JJacques



   


 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 26 mars 2014 13:28

=C0 : dime@ietf.org

Objet : Re: [Dime] issue #56 proposed conclusion






 


JJ,



I am not in favor of your suggestion.  I won't restate -- its in my pr=
evious email.



Steve




On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES) wrote:






Hi Ulrich


 


1) I understand and agree it is good to have a text in v02 on OCS defi=
nition. #35 will deal on the protocol aspects about DOIC information transf=
er for client mitigation in te loss algorithm context .  But regarding=
 OCS definition I prefer to have the OCS definition currently covering a la=
rger scope that may be reviewed if needed in 03 than to do the reverse. For=
 loss algorithm, in the dedicated part for loss that Ben mentioned, we can =
later add that the per client OCS case would be used for a specific client =
mitigation. For  other algorithms (eg rate control) we will see which =
type of OCS to apply , but it will remain compliant with the general defini=
tion. So I remain in favor of my proposal, why not to introduce it?


 


2) about realm OCS, it is to identify the OCS associated to the genera=
tion of a realm OLR, as this OCS will store the 


Reduction percentage for the realm.


 


Best regards


 


JJacques   


 


 


-----Message d'origine-----


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Envoy=E9 : mercredi 26 mars 2014 09:26


=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org


Objet : RE: issue #56 proposed conclusion


 


Hi JJacques,


 


In order to meet Steve's deadline for the 02-draft I would like to clo=
se #56 as proposed by Steve.


This does not mean that we cannot improve text for 03.

 


Ad 1) I don't think that the definition of OCS is Loss specific. Wheth=
er we need client-specific OCS should be discussed under #35. As we have it=
 now there is one OCS shared for all reacting nodes with which the same alg=
orithm was negotiated.


This of course limits agents taking the role of a reacting node for tw=
o clients C1 and C2 to advertize the same set of algorithm, and reacting no=
des to select the algorithm based on the set of advertized algorithm and no=
t based on the client.


 


Ad 2) The current text assumes that a reporting node is located in jus=
t one realm. If that is not the case OCSs need to be maintained per realm. =
We may want to look at this when working on 03.


 


Best regards


Ulrich


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: Wednesday, March 26, 2014 8:59 AM


To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion


 


Hi Ulrich


 


1) My point is that the definition of OCS should be sufficiently gener=
ic so to apply to various algorithms. The current definition applies to the=
 default algorithm, but will need to be extended to support the overload mi=
tigation for a specific  client.


For other algorithms, I mentioned the rate control as we will work on =
it. And in my previous mail example, with all clients and the server suppor=
ting selecting the rate control, I currently do not see how to not introduc=
e OCS per client somewhere (in the server or in a DA) to be able to run the=
 rate control.


 


So I propose  to evolve your definition


   


A reporting node maintains per supported Diameter application, per


    selected Abatement Algorithm and eventually per cli=
ent if relevant an Overload


    Control State


 


Such a definition would be more generic and applicable to future algor=
ithms. I think the draft should be future proof.


 


 


2) I am also questioning, if we have not the need to define an OCS per=
 application  per selected algorithm and per realm for a reporting nod=
e (eg  in the DA that is generating Realm reports for request without =
destination hosts; realm OCS is only defined for reacting nodes in your pro=
posal. Here again I would have  the additional question OCS eventually=
 per client    


 


 


Best regards 


 


JJacques 


 


-----Message d'origine-----


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy=E9 : mardi 25 mars=
 2014 09:24 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: issue #56 proposed co=
nclusion


 


Hi JJacques


 


Your concern is related to issue #35. For #35 we almost reached the co=
nclusion not to address client specific throttling in the 02-draft.


 


The latest proposal to solve #35 was to let clients indicate in OC-Sup=
ported-Features that they are clients; agents taking the role of reacting n=
odes on behalf of clients would not indicate  so. Servers must not req=
uest client specific throtting from reacting nodes that did not indicate th=
at they are clients.


With this (partial) solution of #35 there would not be any impact to m=
y proposal for #56.


 


Best regards


Ulrich


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: Monday, March 24, 2014 7:43 PM


To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion


 


Hi Ulrich and all


 


Still to complement my remark about question of the mitigation for a g=
iven client 


 


Your description of state is defined per Application and Abatement, so=
 not including the mitigation case of a state for a client (cf my previous =
mail)


 


I al trying to se how it would apply to another abatement algorithm. T=
here is the rate control algorithm that we will study, and here I am questi=
oning if we will not be driven to have a state per client, as the requested=
 rate will be rather specific to a client, some clients may have a small tr=
affic  and others a large traffic, meaning to define a requested rate =
per client somewhere. 


 


So I may again repeat myself that the normal state would be per client=
 in general, which does not exclude to group all clients and consider a sta=
te common to all clients when relevant.


 


This may require some more thinking, but I prefer to remind this point=
, but it also concern other tickets.


 


Best regards 


 


JJacques   


 


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Env=
oy=E9 : lundi 24 mars 2014 19:08 =C0 : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclus=
ion


 


Hi Ulrich


 


In 5.5.1.2 you wrote:


  A reporting node maintains per supported Diameter application a=
nd per


    supported (and eventually selected) Abatement Algor=
ithm an Overload


    Control State


 


but for another ticket, there is the conclusion that reporting node se=
lects one algorithm,  so your wording would become


 


     ...per supported Diameter application and for=
 the


    selected Abatement Algorithm.... 


 


 


I have also the question of the mitigation for a given  client wh=
ich may drives the reporting node to consider a state for a client 


 


Interest of this text is that it clarifies the node behaviors.


 


Best regards


 


JJacques  


 


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9=
 : lundi 24 mars 2014 18:24 =C0 : Wiehe, Ulrich (NSN - DE/Munich)=
; dime@ietf.org Objet : Re: [Dime=
] issue #56 proposed conclusion


 


Dear all,


 


I have received a further comment asking not to abbreviate "Overl=
oad Control State" as OCS is used for "Online Charging System&quo=
t;.


 


I'm fine with not abbreviating "Overload Control State".


 


I shall close issue #56 to meet Steve's deadline for the 02-draft, unl=
ess I receive more comments by tomorrow.


 


Ulrich


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich)


Sent: Thursday, March 20, 2014 2:08 PM


To: dime@ietf.org

Subject: issue #56 proposed conclusion


 


#56: Bad Description of Overload Control State


 


 


Dear all,


 


I have received comments from Steve, MCruz and Jouni.


 


I believe all comments are covered by the following proposed text:


 


 


 


    5.5.1.  Overload Control State (OCS)


 


    5.5.1.1   Overload Control States for rea=
cting nodes


 


    A reacting node maintains per supported Diameter ap=
plication


    - a host-type Overload Control State for each Desti=
nation-Host towards


      which it sends host-type requests and


    - a realm-type Overload Control State for each Dest=
ination-Realm towards


      which it sends realm-type requests.


 


    A host-type Overload Control State may be identifie=
d by the pair of


    Application-Id and Destination-Host.

    A realm-type Overload Control State may be identifi=
ed 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-Real=
m could include the


    following information:


    - Sequence number (as reveived in OC-OLR)


    - Time of expiry  (deviated from validity dura=
tion as received in OC-OLR


      and time of reception)


    - Selected Abatement Algorithm (as received in OC-S=
upported-Features)


    - Algorithm specific input data (as received within=
 OC-OLR, e.g.


      Reduction Percentage for Loss)


 


   


    5.5.1.2   Overload Control States fo=
r reporting nodes


 


    A reporting node maintains per supported Diameter a=
pplication and per


    supported (and eventually selected) Abatement Algor=
ithm an Overload


    Control State. 


 


    An Overload Control State may be identified by the =
pair of Application-Id


    and supported Abatement Algorithm.


 


    The Overload Control State for a given pair of Appl=
ication and Abatement


    Algorithm could include the information:=



    - Sequence number


    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Per=
centage for Loss)


 


    


    5.5.1.3  Maintaining Overload Control Sta=
tes


 


    Reacting nodes create a host-type OCS identified by=
 OCS-Id =3D (app-id,host-id) when receiving


    an answer message of application app-id containing =
an Orig-Host of host-id and a


    host-type OC-OLR AVP unless such host-type OCS alre=
ady exists.


 


    Reacting nodes create a realm-type OCS identified b=
y OCS-Id =3D (app-id,realm-id) when receiving


    an answer message of application app-id containing =
an Orig-Realm of realm-id and a


    realm-type OC-OLR AVP unless such realm type OCS al=
ready exists.


 


    Reacting nodes delete an OCS when it expires (i.e. =
when current time


    minus reception time is greater than validity durat=
ion).


 


    Reacting nodes update the host-type OCS identified =
by OCS-Id =3D (app-id,host-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Host of


    host-id and a host-type OC-OLR AVP with a sequence =
number higher than the


    stored sequence number.


 


    Reacting nodes update the realm-type OCS identified=
 by OCS-Id =3D (app-id,realm-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Realm of


    realm-id and a realm-type OC-OLR AVP with a sequenc=
e number higher than the


    stored sequence number.


 


    Reporting nodes create an OCS identified by OCS-Id =
=3D (app-id,Alg) when receiving a


    request of application app-id containing an OC-Supp=
orted-Features AVP


    indicating support of the Abatement Algorithm Alg (=
which the reporting


    node selects) while being overloaded, unless such O=
CS already exists.


 


    Reporting nodes delete an OCS when it expires.=



 


    Reporting nodes update the OCS identified by OCS-Id=
 =3D (app-id,Alg) when they detect the


    need to modify the requested amount of application =
app-id traffic reduction.


 


Ulrich


 


 


_______________________________________________


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


 


_______________________________________________


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_E194C2E18676714DACA9C3A2516265D20267A7FEFR712WXCHMBA12z_--


From nobody Wed Mar 26 05:50:32 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 938EC1A02DF for ; Wed, 26 Mar 2014 05:50:28 -0700 (PDT)
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 ccrls7AfiOa4 for ; Wed, 26 Mar 2014 05:50:25 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id C2E791A00E3 for ; Wed, 26 Mar 2014 05:50:21 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62397 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSnHd-0006sh-C7 for dime@ietf.org; Wed, 26 Mar 2014 05:50:19 -0700
Message-ID: <5332CD09.5050706@usdonovans.com>
Date: Wed, 26 Mar 2014 07:50:17 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net>  <5332C7B4.4060805@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050501020803060506060300"
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/F4iBOqtjv2oXhGkTQrZksdkDVac
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 12:50:28 -0000

This is a multi-part message in MIME format.
--------------050501020803060506060300
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

There is nothing in the draft that prevents extending the amount of
state saved by a reporting node.

We do probably need to add more on extensibility into the draft and one
of the suggestions for any extension should be to expand on the
discussion of how OCS is impacted by the extension.

Regards,

Steve

On 3/26/14 7:37 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Hi Steve
>
>  
>
> When reading your draft  about Rate control, we have
>
>         The server must allocate a portion of the
>
>    target Diameter request rate to each of its reacting nodes.  The
>
>    server may set the same rate for every reacting node, or may set
>
>    different rates for different reacting node.
>
> I am OK with this statement. For me it implies  the reporting node
> (server)  to have a n OCS per reacting node if the rates are different .
>
> So  I am a bit surprised you do not take this example  into account in
> the draft that should be future proof in its wording even if the OCS
> is not normative, but has a general meaning applicable to various
> algorithm and not only to the loss algorithm.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>    
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* mercredi 26 mars 2014 13:28
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] issue #56 proposed conclusion
>
>  
>
> JJ,
>
> I am not in favor of your suggestion.  I won't restate -- its in my
> previous email.
>
> Steve
>
> On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>     Hi Ulrich
>
>      
>
>     1) I understand and agree it is good to have a text in v02 on OCS definition. #35 will deal on the protocol aspects about DOIC information transfer for client mitigation in te loss algorithm context .  But regarding OCS definition I prefer to have the OCS definition currently covering a larger scope that may be reviewed if needed in 03 than to do the reverse. For loss algorithm, in the dedicated part for loss that Ben mentioned, we can later add that the per client OCS case would be used for a specific client mitigation. For  other algorithms (eg rate control) we will see which type of OCS to apply , but it will remain compliant with the general definition. So I remain in favor of my proposal, why not to introduce it?
>
>      
>
>     2) about realm OCS, it is to identify the OCS associated to the generation of a realm OLR, as this OCS will store the 
>
>     Reduction percentage for the realm.
>
>      
>
>     Best regards
>
>      
>
>     JJacques   
>
>      
>
>      
>
>     -----Message d'origine-----
>
>     De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>
>     Envoyé : mercredi 26 mars 2014 09:26
>
>     À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org 
>
>     Objet : RE: issue #56 proposed conclusion
>
>      
>
>     Hi JJacques,
>
>      
>
>     In order to meet Steve's deadline for the 02-draft I would like to close #56 as proposed by Steve.
>
>     This does not mean that we cannot improve text for 03.
>
>      
>
>     Ad 1) I don't think that the definition of OCS is Loss specific. Whether we need client-specific OCS should be discussed under #35. As we have it now there is one OCS shared for all reacting nodes with which the same algorithm was negotiated.
>
>     This of course limits agents taking the role of a reacting node for two clients C1 and C2 to advertize the same set of algorithm, and reacting nodes to select the algorithm based on the set of advertized algorithm and not based on the client.
>
>      
>
>     Ad 2) The current text assumes that a reporting node is located in just one realm. If that is not the case OCSs need to be maintained per realm. We may want to look at this when working on 03.
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>     Sent: Wednesday, March 26, 2014 8:59 AM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] issue #56 proposed conclusion
>
>      
>
>     Hi Ulrich
>
>      
>
>     1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.
>
>     For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.
>
>      
>
>     So I propose  to evolve your definition
>
>        
>
>     A reporting node maintains per supported Diameter application, per
>
>         selected Abatement Algorithm and eventually per client if relevant an Overload
>
>         Control State
>
>      
>
>     Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.
>
>      
>
>      
>
>     2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    
>
>      
>
>      
>
>     Best regards 
>
>      
>
>     JJacques 
>
>      
>
>     -----Message d'origine-----
>
>     De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org  Objet : RE: issue #56 proposed conclusion
>
>      
>
>     Hi JJacques
>
>      
>
>     Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.
>
>      
>
>     The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.
>
>     With this (partial) solution of #35 there would not be any impact to my proposal for #56.
>
>      
>
>     Best regards
>
>     Ulrich
>
>      
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>     Sent: Monday, March 24, 2014 7:43 PM
>
>     To: dime@ietf.org 
>
>     Subject: Re: [Dime] issue #56 proposed conclusion
>
>      
>
>     Hi Ulrich and all
>
>      
>
>     Still to complement my remark about question of the mitigation for a given client 
>
>      
>
>     Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)
>
>      
>
>     I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 
>
>      
>
>     So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.
>
>      
>
>     This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.
>
>      
>
>     Best regards 
>
>      
>
>     JJacques   
>
>      
>
>      
>
>     -----Message d'origine-----
>
>     De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org  Objet : Re: [Dime] issue #56 proposed conclusion
>
>      
>
>     Hi Ulrich
>
>      
>
>     In 5.5.1.2 you wrote:
>
>       A reporting node maintains per supported Diameter application and per
>
>         supported (and eventually selected) Abatement Algorithm an Overload
>
>         Control State
>
>      
>
>     but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become
>
>      
>
>          ...per supported Diameter application and for the
>
>         selected Abatement Algorithm.... 
>
>      
>
>      
>
>     I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 
>
>      
>
>     Interest of this text is that it clarifies the node behaviors.
>
>      
>
>     Best regards
>
>      
>
>     JJacques  
>
>      
>
>      
>
>     -----Message d'origine-----
>
>     De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org  Objet : Re: [Dime] issue #56 proposed conclusion
>
>      
>
>     Dear all,
>
>      
>
>     I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
>      
>
>     I'm fine with not abbreviating "Overload Control State".
>
>      
>
>     I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
>      
>
>     Ulrich
>
>      
>
>     -----Original Message-----
>
>     From: Wiehe, Ulrich (NSN - DE/Munich)
>
>     Sent: Thursday, March 20, 2014 2:08 PM
>
>     To: dime@ietf.org 
>
>     Subject: issue #56 proposed conclusion
>
>      
>
>     #56: Bad Description of Overload Control State
>
>      
>
>      
>
>     Dear all,
>
>      
>
>     I have received comments from Steve, MCruz and Jouni.
>
>      
>
>     I believe all comments are covered by the following proposed text:
>
>      
>
>      
>
>      
>
>         5.5.1.  Overload Control State (OCS)
>
>      
>
>         5.5.1.1   Overload Control States for reacting nodes
>
>      
>
>         A reacting node 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 towards
>
>           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 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
>
>         following information:
>
>         - Sequence number (as reveived in OC-OLR)
>
>         - Time of expiry  (deviated from validity duration as received in OC-OLR
>
>           and time of reception)
>
>         - Selected Abatement Algorithm (as received in OC-Supported-Features)
>
>         - Algorithm specific input data (as received within OC-OLR, e.g.
>
>           Reduction Percentage for Loss)
>
>      
>
>        
>
>         5.5.1.2   Overload Control States for reporting nodes
>
>      
>
>         A reporting node maintains per supported Diameter application and per
>
>         supported (and eventually selected) Abatement Algorithm an Overload
>
>         Control State. 
>
>      
>
>         An Overload Control State may be identified by the pair of Application-Id
>
>         and supported Abatement Algorithm.
>
>      
>
>         The Overload Control State for a given pair of Application and Abatement
>
>         Algorithm could include the information:
>
>         - Sequence number
>
>         - Validity Duration and Expiry Time
>
>         - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>      
>
>         
>
>         5.5.1.3  Maintaining Overload Control States
>
>      
>
>         Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>
>         an answer message of application app-id containing an Orig-Host of host-id and a
>
>         host-type OC-OLR AVP unless such host-type OCS already exists.
>
>      
>
>         Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>
>         an answer message of application app-id containing an Orig-Realm of realm-id and a
>
>         realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>      
>
>         Reacting nodes delete an OCS when it expires (i.e. when current time
>
>         minus reception time is greater than validity duration).
>
>      
>
>         Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>
>         receiving an answer message of application app-id containing an Orig-Host of
>
>         host-id and a host-type OC-OLR AVP with a sequence number higher than the
>
>         stored sequence number.
>
>      
>
>         Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>
>         receiving an answer message of application app-id containing an Orig-Realm of
>
>         realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>
>         stored sequence number.
>
>      
>
>         Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>
>         request of application app-id containing an OC-Supported-Features AVP
>
>         indicating support of the Abatement Algorithm Alg (which the reporting
>
>         node selects) while being overloaded, unless such OCS already exists.
>
>      
>
>         Reporting nodes delete an OCS when it expires.
>
>      
>
>         Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>
>         need to modify the requested amount of application app-id traffic reduction.
>
>      
>
>     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
>
>      
>
>     _______________________________________________
>
>     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


--------------050501020803060506060300
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      There is nothing in the draft that prevents extending the amount
      of state saved by a reporting node.

      

      We do probably need to add more on extensibility into the draft
      and one of the suggestions for any extension should be to expand
      on the discussion of how OCS is impacted by the extension.

      

      Regards,

      

      Steve

      

    
    
On 3/26/14 7:37 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Hi
            Steve

        
 

        
When
            reading your draft  about Rate control, we have

        
        The server must allocate
            a portion of the

        
   target Diameter request rate
            to each of its reacting nodes.  The

        
   server may set the same rate
            for every reacting node, or may set

        
   different rates for different
            reacting node.

        
I
            am OK with this statement. For me it implies  the reporting
            node (server)  to have a n OCS per reacting node if the
            rates are different .

        
So
             I am a bit surprised you do not take this example  into
            account in the draft that should be future proof in its
            wording even if the OCS is not normative, but has a general
            meaning applicable to various algorithm and not only to the
            loss algorithm.

        
 

        
Best
            regards

        
 

        
JJacques
            

        
   

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : mercredi 26 mars 2014 13:28

                À : dime@ietf.org

                Objet : Re: [Dime] issue #56 proposed conclusion

          

        

        
 

        
JJ,

          

          I am not in favor of your suggestion.  I won't restate -- its
          in my previous email.

          

          Steve

        

          
On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES
            (JEAN-JACQUES) wrote:

        

        

          
Hi Ulrich

          
 

          
1) I understand and agree it is good to have a text in v02 on OCS definition. #35 will deal on the protocol aspects about DOIC information transfer for client mitigation in te loss algorithm context .  But regarding OCS definition I prefer to have the OCS definition currently covering a larger scope that may be reviewed if needed in 03 than to do the reverse. For loss algorithm, in the dedicated part for loss that Ben mentioned, we can later add that the per client OCS case would be used for a specific client mitigation. For  other algorithms (eg rate control) we will see which type of OCS to apply , but it will remain compliant with the general definition. So I remain in favor of my proposal, why not to introduce it?

          
 

          
2) about realm OCS, it is to identify the OCS associated to the generation of a realm OLR, as this OCS will store the 

          
Reduction percentage for the realm.

          
 

          
Best regards

          
 

          
JJacques   

          
 

          
 

          
-----Message d'origine-----

          
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

          
Envoyé : mercredi 26 mars 2014 09:26

          
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

          
Objet : RE: issue #56 proposed conclusion

          
 

          
Hi JJacques,

          
 

          
In order to meet Steve's deadline for the 02-draft I would like to close #56 as proposed by Steve.

          
This does not mean that we cannot improve text for 03.

          
 

          
Ad 1) I don't think that the definition of OCS is Loss specific. Whether we need client-specific OCS should be discussed under #35. As we have it now there is one OCS shared for all reacting nodes with which the same algorithm was negotiated.

          
This of course limits agents taking the role of a reacting node for two clients C1 and C2 to advertize the same set of algorithm, and reacting nodes to select the algorithm based on the set of advertized algorithm and not based on the client.

          
 

          
Ad 2) The current text assumes that a reporting node is located in just one realm. If that is not the case OCSs need to be maintained per realm. We may want to look at this when working on 03.

          
 

          
Best regards

          
Ulrich

          
 

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

          
Sent: Wednesday, March 26, 2014 8:59 AM

          
To: dime@ietf.org

          
Subject: Re: [Dime] issue #56 proposed conclusion

          
 

          
Hi Ulrich

          
 

          
1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.

          
For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.

          
 

          
So I propose  to evolve your definition

          
   

          
A reporting node maintains per supported Diameter application, per

          
    selected Abatement Algorithm and eventually per client if relevant an Overload

          
    Control State

          
 

          
Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.

          
 

          
 

          
2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    

          
 

          
 

          
Best regards 

          
 

          
JJacques 

          
 

          
-----Message d'origine-----

          
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: issue #56 proposed conclusion

          
 

          
Hi JJacques

          
 

          
Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.

          
 

          
The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.

          
With this (partial) solution of #35 there would not be any impact to my proposal for #56.

          
 

          
Best regards

          
Ulrich

          
 

          
 

          
 

          
-----Original Message-----

          
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

          
Sent: Monday, March 24, 2014 7:43 PM

          
To: dime@ietf.org

          
Subject: Re: [Dime] issue #56 proposed conclusion

          
 

          
Hi Ulrich and all

          
 

          
Still to complement my remark about question of the mitigation for a given client 

          
 

          
Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)

          
 

          
I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 

          
 

          
So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.

          
 

          
This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.

          
 

          
Best regards 

          
 

          
JJacques   

          
 

          
 

          
-----Message d'origine-----

          
De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

          
 

          
Hi Ulrich

          
 

          
In 5.5.1.2 you wrote:

          
  A reporting node maintains per supported Diameter application and per

          
    supported (and eventually selected) Abatement Algorithm an Overload

          
    Control State

          
 

          
but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become

          
 

          
     ...per supported Diameter application and for the

          
    selected Abatement Algorithm.... 

          
 

          
 

          
I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 

          
 

          
Interest of this text is that it clarifies the node behaviors.

          
 

          
Best regards

          
 

          
JJacques  

          
 

          
 

          
-----Message d'origine-----

          
De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

          
 

          
Dear all,

          
 

          
I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

          
 

          
I'm fine with not abbreviating "Overload Control State".

          
 

          
I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

          
 

          
Ulrich

          
 

          
-----Original Message-----

          
From: Wiehe, Ulrich (NSN - DE/Munich)

          
Sent: Thursday, March 20, 2014 2:08 PM

          
To: dime@ietf.org

          
Subject: issue #56 proposed conclusion

          
 

          
#56: Bad Description of Overload Control State

          
 

          
 

          
Dear all,

          
 

          
I have received comments from Steve, MCruz and Jouni.

          
 

          
I believe all comments are covered by the following proposed text:

          
 

          
 

          
 

          
    5.5.1.  Overload Control State (OCS)

          
 

          
    5.5.1.1   Overload Control States for reacting nodes

          
 

          
    A reacting node 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 towards

          
      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 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

          
    following information:

          
    - Sequence number (as reveived in OC-OLR)

          
    - Time of expiry  (deviated from validity duration as received in OC-OLR

          
      and time of reception)

          
    - Selected Abatement Algorithm (as received in OC-Supported-Features)

          
    - Algorithm specific input data (as received within OC-OLR, e.g.

          
      Reduction Percentage for Loss)

          
 

          
   

          
    5.5.1.2   Overload Control States for reporting nodes

          
 

          
    A reporting node maintains per supported Diameter application and per

          
    supported (and eventually selected) Abatement Algorithm an Overload

          
    Control State. 

          
 

          
    An Overload Control State may be identified by the pair of Application-Id

          
    and supported Abatement Algorithm.

          
 

          
    The Overload Control State for a given pair of Application and Abatement

          
    Algorithm could include the information:

          
    - Sequence number

          
    - Validity Duration and Expiry Time

          
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

          
 

          
    

          
    5.5.1.3  Maintaining Overload Control States

          
 

          
    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving

          
    an answer message of application app-id containing an Orig-Host of host-id and a

          
    host-type OC-OLR AVP unless such host-type OCS already exists.

          
 

          
    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving

          
    an answer message of application app-id containing an Orig-Realm of realm-id and a

          
    realm-type OC-OLR AVP unless such realm type OCS already exists.

          
 

          
    Reacting nodes delete an OCS when it expires (i.e. when current time

          
    minus reception time is greater than validity duration).

          
 

          
    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when

          
    receiving an answer message of application app-id containing an Orig-Host of

          
    host-id and a host-type OC-OLR AVP with a sequence number higher than the

          
    stored sequence number.

          
 

          
    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when

          
    receiving an answer message of application app-id containing an Orig-Realm of

          
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the

          
    stored sequence number.

          
 

          
    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a

          
    request of application app-id containing an OC-Supported-Features AVP

          
    indicating support of the Abatement Algorithm Alg (which the reporting

          
    node selects) while being overloaded, unless such OCS already exists.

          
 

          
    Reporting nodes delete an OCS when it expires.

          
 

          
    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the

          
    need to modify the requested amount of application app-id traffic reduction.

          
 

          
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

          
 

          
_______________________________________________

          
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


    

    

  


--------------050501020803060506060300--


From nobody Wed Mar 26 05:53: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 2098A1A00CA for ; Wed, 26 Mar 2014 05:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 e0-r_pGhrFSB for ; Wed, 26 Mar 2014 05:53:47 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DC7151A0089 for ; Wed, 26 Mar 2014 05:53:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEY77280; Wed, 26 Mar 2014 12:53:43 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 12:53:16 +0000
Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 26 Mar 2014 12:53:40 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Wed, 26 Mar 2014 20:53:29 +0800
From: "Shishufeng (Susan)" 
To: Steve Donovan , "lionel.morand@orange.com" , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcA==
Date: Wed, 26 Mar 2014 12:53:27 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com>
In-Reply-To: <5332C60E.2060805@usdonovans.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3E932SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/OEx787OK1ufYB3XPTkYoFjkofbA
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 12:53:57 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3E932SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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_26C84DFD55BC3040A45BF70926E55F2587C3E932SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Stev=
e,


 =
;


Ok, let=
217;s come back with technical discussion then.


 =
;



-Fi=
rst a not always needed AVP cannot justify why it shall be mandatory.




-Se=
condly, in my view, having a not always needed AVP as mandatory cannot be l=
ess error prone. On the contrary, it would introduce more
 error cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSIN=
G_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with t=
he possible error cases. All the handling with this AVP consumes the resour=
ce of both reporting nodes and reacting
 nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan=



 =
;


 =
;






From:=
 Steve Donovan [mail=
to:srdonovan@usdonovans.com]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.<=
/p>

 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.=



 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 =



Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,=



 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. =



 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,

 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 


 


Best Regards,

Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  =



 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards

/MCruz


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?

 


If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?


 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 


 


Hello all,

 


I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 


I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 


Best regards

/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 


I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.=



 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
span lang=3D"EN-US">


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 


Best regards

 


JJacques


 


 


 


 


-----Message d'origine-----<=
/o:p>


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 


lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] <=
/pre>

[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,<=
/pre>

 


I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?

 


So instead of:<=
/pre>

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]

         * [ AVP ]


 


You would prefer:


 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]

         * [ AVP ]


 


And I'm fine with this proposal.<=
o:p>


 


Cheers,


 


Lionel


 


-----Message d'origine-----<=
/o:p>


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 

[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP


 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 


This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 


--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz

  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new<=
/pre>

Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>=



 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_____________________________________________________________=
________


____________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.=



If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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


 


 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 




 






_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.

________________________________________________________________=
_________________________________________________________


 


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.

 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.




 






--_000_26C84DFD55BC3040A45BF70926E55F2587C3E932SZXEMA512MBXchi_--


From nobody Wed Mar 26 06:08: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 1F3861A0345 for ; Wed, 26 Mar 2014 06:07:55 -0700 (PDT)
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 kHZMzZSkKPCD for ; Wed, 26 Mar 2014 06:07:44 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 71D801A00CA for ; Wed, 26 Mar 2014 06:07:44 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2QD7eTh009750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 26 Mar 2014 08:07:42 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2QD7eOx005927 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 26 Mar 2014 14:07:40 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 14:07:40 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAAWgNwAAcxQhgADDx3RAAAVklwAABAxkAAAXouwAAAiVuwP//9S+A///uICA=
Date: Wed, 26 Mar 2014 13:07:40 +0000
Message-ID: 
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net>  <5332C7B4.4060805@usdonovans.com>  <5332CD09.5050706@usdonovans.com>
In-Reply-To: <5332CD09.5050706@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.38]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20267A82DFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XecOAQodPgB4Y97IcprQd7bsr_A
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 13:07:55 -0000

--_000_E194C2E18676714DACA9C3A2516265D20267A82DFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Steve

A sentence about extensibility of the OSC is for me necessary, not only on =
 the information it can store but also on the access keys (eg per reacting =
nodes), otherwise the OCS as currently described for which it should have a=
 large appliance perimeter has already two exceptions, the specific client =
% reduction percentage  with the loss algorithm and your control rate case.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 26 mars 2014 13:50
=C0 : dime@ietf.org
Objet : Re: [Dime] issue #56 proposed conclusion

JJ,

There is nothing in the draft that prevents extending the amount of state s=
aved by a reporting node.

We do probably need to add more on extensibility into the draft and one of =
the suggestions for any extension should be to expand on the discussion of =
how OCS is impacted by the extension.

Regards,

Steve
On 3/26/14 7:37 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
Hi Steve

When reading your draft  about Rate control, we have
        The server must allocate a portion of the
   target Diameter request rate to each of its reacting nodes.  The
   server may set the same rate for every reacting node, or may set
   different rates for different reacting node.
I am OK with this statement. For me it implies  the reporting node (server)=
  to have a n OCS per reacting node if the rates are different .
So  I am a bit surprised you do not take this example  into account in the =
draft that should be future proof in its wording even if the OCS is not nor=
mative, but has a general meaning applicable to various algorithm and not o=
nly to the loss algorithm.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 26 mars 2014 13:28
=C0 : dime@ietf.org
Objet : Re: [Dime] issue #56 proposed conclusion

JJ,

I am not in favor of your suggestion.  I won't restate -- its in my previou=
s email.

Steve
On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

Hi Ulrich



1) I understand and agree it is good to have a text in v02 on OCS definitio=
n. #35 will deal on the protocol aspects about DOIC information transfer fo=
r client mitigation in te loss algorithm context .  But regarding OCS defin=
ition I prefer to have the OCS definition currently covering a larger scope=
 that may be reviewed if needed in 03 than to do the reverse. For loss algo=
rithm, in the dedicated part for loss that Ben mentioned, we can later add =
that the per client OCS case would be used for a specific client mitigation=
. For  other algorithms (eg rate control) we will see which type of OCS to =
apply , but it will remain compliant with the general definition. So I rema=
in in favor of my proposal, why not to introduce it?



2) about realm OCS, it is to identify the OCS associated to the generation =
of a realm OLR, as this OCS will store the

Reduction percentage for the realm.



Best regards



JJacques





-----Message d'origine-----

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]

Envoy=E9 : mercredi 26 mars 2014 09:26

=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

Objet : RE: issue #56 proposed conclusion



Hi JJacques,



In order to meet Steve's deadline for the 02-draft I would like to close #5=
6 as proposed by Steve.

This does not mean that we cannot improve text for 03.



Ad 1) I don't think that the definition of OCS is Loss specific. Whether we=
 need client-specific OCS should be discussed under #35. As we have it now =
there is one OCS shared for all reacting nodes with which the same algorith=
m was negotiated.

This of course limits agents taking the role of a reacting node for two cli=
ents C1 and C2 to advertize the same set of algorithm, and reacting nodes t=
o select the algorithm based on the set of advertized algorithm and not bas=
ed on the client.



Ad 2) The current text assumes that a reporting node is located in just one=
 realm. If that is not the case OCSs need to be maintained per realm. We ma=
y want to look at this when working on 03.



Best regards

Ulrich





-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)

Sent: Wednesday, March 26, 2014 8:59 AM

To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion



Hi Ulrich



1) My point is that the definition of OCS should be sufficiently generic so=
 to apply to various algorithms. The current definition applies to the defa=
ult algorithm, but will need to be extended to support the overload mitigat=
ion for a specific  client.

For other algorithms, I mentioned the rate control as we will work on it. A=
nd in my previous mail example, with all clients and the server supporting =
selecting the rate control, I currently do not see how to not introduce OCS=
 per client somewhere (in the server or in a DA) to be able to run the rate=
 control.



So I propose  to evolve your definition



A reporting node maintains per supported Diameter application, per

    selected Abatement Algorithm and eventually per client if relevant an O=
verload

    Control State



Such a definition would be more generic and applicable to future algorithms=
. I think the draft should be future proof.





2) I am also questioning, if we have not the need to define an OCS per appl=
ication  per selected algorithm and per realm for a reporting node (eg  in =
the DA that is generating Realm reports for request without destination hos=
ts; realm OCS is only defined for reacting nodes in your proposal. Here aga=
in I would have  the additional question OCS eventually per client





Best regards



JJacques



-----Message d'origine-----

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy=E9=
 : mardi 25 mars 2014 09:24 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dim=
e@ietf.org Objet : RE: issue #56 proposed conclusion



Hi JJacques



Your concern is related to issue #35. For #35 we almost reached the conclus=
ion not to address client specific throttling in the 02-draft.



The latest proposal to solve #35 was to let clients indicate in OC-Supporte=
d-Features that they are clients; agents taking the role of reacting nodes =
on behalf of clients would not indicate  so. Servers must not request clien=
t specific throtting from reacting nodes that did not indicate that they ar=
e clients.

With this (partial) solution of #35 there would not be any impact to my pro=
posal for #56.



Best regards

Ulrich







-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JA=
CQUES (JEAN-JACQUES)

Sent: Monday, March 24, 2014 7:43 PM

To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion



Hi Ulrich and all



Still to complement my remark about question of the mitigation for a given =
client



Your description of state is defined per Application and Abatement, so not =
including the mitigation case of a state for a client (cf my previous mail)



I al trying to se how it would apply to another abatement algorithm. There =
is the rate control algorithm that we will study, and here I am questioning=
 if we will not be driven to have a state per client, as the requested rate=
 will be rather specific to a client, some clients may have a small traffic=
  and others a large traffic, meaning to define a requested rate per client=
 somewhere.



So I may again repeat myself that the normal state would be per client in g=
eneral, which does not exclude to group all clients and consider a state co=
mmon to all clients when relevant.



This may require some more thinking, but I prefer to remind this point, but=
 it also concern other tickets.



Best regards



JJacques





-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUE=
S (JEAN-JACQUES) Envoy=E9 : lundi 24 mars 2014 19:08 =C0 : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion



Hi Ulrich



In 5.5.1.2 you wrote:

  A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State



but for another ticket, there is the conclusion that reporting node selects=
 one algorithm,  so your wording would become



     ...per supported Diameter application and for the

    selected Abatement Algorithm....





I have also the question of the mitigation for a given  client which may dr=
ives the reporting node to consider a state for a client



Interest of this text is that it clarifies the node behaviors.



Best regards



JJacques





-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich) Envoy=E9 : lundi 24 mars 2014 18:24 =C0 : Wiehe, Ulrich (NSN - =
DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #5=
6 proposed conclusion



Dear all,



I have received a further comment asking not to abbreviate "Overload Contro=
l State" as OCS is used for "Online Charging System".



I'm fine with not abbreviating "Overload Control State".



I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I=
 receive more comments by tomorrow.



Ulrich



-----Original Message-----

From: Wiehe, Ulrich (NSN - DE/Munich)

Sent: Thursday, March 20, 2014 2:08 PM

To: dime@ietf.org

Subject: issue #56 proposed conclusion



#56: Bad Description of Overload Control State





Dear all,



I have received comments from Steve, MCruz and Jouni.



I believe all comments are covered by the following proposed text:







    5.5.1.  Overload Control State (OCS)



    5.5.1.1   Overload Control States for reacting nodes



    A reacting node 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=
s

      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 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

    following information:

    - Sequence number (as reveived in OC-OLR)

    - Time of expiry  (deviated from validity duration as received in OC-OL=
R

      and time of reception)

    - Selected Abatement Algorithm (as received in OC-Supported-Features)

    - Algorithm specific input data (as received within OC-OLR, e.g.

      Reduction Percentage for Loss)





    5.5.1.2   Overload Control States for reporting nodes



    A reporting node maintains per supported Diameter application and per

    supported (and eventually selected) Abatement Algorithm an Overload

    Control State.



    An Overload Control State may be identified by the pair of Application-=
Id

    and supported Abatement Algorithm.



    The Overload Control State for a given pair of Application and Abatemen=
t

    Algorithm could include the information:

    - Sequence number

    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Percentage for Loss)





    5.5.1.3  Maintaining Overload Control States



    Reacting nodes create a host-type OCS identified by OCS-Id =3D (app-id,=
host-id) when receiving

    an answer message of application app-id containing an Orig-Host of host=
-id and a

    host-type OC-OLR AVP unless such host-type OCS already exists.



    Reacting nodes create a realm-type OCS identified by OCS-Id =3D (app-id=
,realm-id) when receiving

    an answer message of application app-id containing an Orig-Realm of rea=
lm-id and a

    realm-type OC-OLR AVP unless such realm type OCS already exists.



    Reacting nodes delete an OCS when it expires (i.e. when current time

    minus reception time is greater than validity duration).



    Reacting nodes update the host-type OCS identified by OCS-Id =3D (app-i=
d,host-id) when

    receiving an answer message of application app-id containing an Orig-Ho=
st of

    host-id and a host-type OC-OLR AVP with a sequence number higher than t=
he

    stored sequence number.



    Reacting nodes update the realm-type OCS identified by OCS-Id =3D (app-=
id,realm-id) when

    receiving an answer message of application app-id containing an Orig-Re=
alm of

    realm-id and a realm-type OC-OLR AVP with a sequence number higher than=
 the

    stored sequence number.



    Reporting nodes create an OCS identified by OCS-Id =3D (app-id,Alg) whe=
n receiving a

    request of application app-id containing an OC-Supported-Features AVP

    indicating support of the Abatement Algorithm Alg (which the reporting

    node selects) while being overloaded, unless such OCS already exists.



    Reporting nodes delete an OCS when it expires.



    Reporting nodes update the OCS identified by OCS-Id =3D (app-id,Alg) wh=
en they detect the

    need to modify the requested amount of application app-id traffic reduc=
tion.



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



_______________________________________________

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


--_000_E194C2E18676714DACA9C3A2516265D20267A82DFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Steve

 <=
/p>

A sentence about extensib=
ility of the OSC is for me necessary, not only on  the information it =
can store but also on the access keys (eg per reacting nodes),
 otherwise the OCS as currently described for which it should have a large =
appliance perimeter has already two exceptions, the specific client % reduc=
tion percentage  with the loss algorithm and your control rate case.



 <=
/p>

Best regards


 <=
/p>

JJacques



 <=
/p>

 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 26 mars 2014 13:50

=C0 : dime@ietf.org

Objet : Re: [Dime] issue #56 proposed conclusion






 


JJ,



There is nothing in the draft that prevents extending the amount of state s=
aved by a reporting node.



We do probably need to add more on extensibility into the draft and one of =
the suggestions for any extension should be to expand on the discussion of =
how OCS is impacted by the extension.



Regards,



Steve




On 3/26/14 7:37 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES) wrote:






Hi Steve


 <=
/p>

When reading your draft &=
nbsp;about Rate control, we have


   &nbs=
p;    The server must allocate a portion of the<=
/o:p>


   target Di=
ameter request rate to each of its reacting nodes.  The


   server ma=
y set the same rate for every reacting node, or may set

   different=
 rates for different reacting node.


I am OK with this stateme=
nt. For me it implies  the reporting node (server)  to have a n O=
CS per reacting node if the rates are different .


So  I am a bit surpr=
ised you do not take this example  into account in the draft that shou=
ld be future proof in its wording even if the OCS is not normative,
 but has a general meaning applicable to various algorithm and not only to =
the loss algorithm.


 <=
/p>

Best regards<=
/o:p>


 <=
/p>

JJacques



   =



 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Steve Donovan

Envoy=E9 : mercredi 26 mars 2014 13:28

=C0 : dime@ietf.org

Objet : Re: [Dime] issue #56 proposed conclusion






 


JJ,



I am not in favor of your suggestion.  I won't restate -- its in my pr=
evious email.



Steve




On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQ=
UES) wrote:






Hi Ulrich


 


1) I understand and agree it is good to have a text in v02 on OCS defi=
nition. #35 will deal on the protocol aspects about DOIC information transf=
er for client mitigation in te loss algorithm context .  But regarding=
 OCS definition I prefer to have the OCS definition currently covering a la=
rger scope that may be reviewed if needed in 03 than to do the reverse. For=
 loss algorithm, in the dedicated part for loss that Ben mentioned, we can =
later add that the per client OCS case would be used for a specific client =
mitigation. For  other algorithms (eg rate control) we will see which =
type of OCS to apply , but it will remain compliant with the general defini=
tion. So I remain in favor of my proposal, why not to introduce it?


 


2) about realm OCS, it is to identify the OCS associated to the genera=
tion of a realm OLR, as this OCS will store the 


Reduction percentage for the realm.


 


Best regards


 


JJacques   


 


 


-----Message d'origine-----


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 


Envoy=E9 : mercredi 26 mars 2014 09:26


=C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org


Objet : RE: issue #56 proposed conclusion


 


Hi JJacques,


 


In order to meet Steve's deadline for the 02-draft I would like to clo=
se #56 as proposed by Steve.


This does not mean that we cannot improve text for 03.

 


Ad 1) I don't think that the definition of OCS is Loss specific. Wheth=
er we need client-specific OCS should be discussed under #35. As we have it=
 now there is one OCS shared for all reacting nodes with which the same alg=
orithm was negotiated.


This of course limits agents taking the role of a reacting node for tw=
o clients C1 and C2 to advertize the same set of algorithm, and reacting no=
des to select the algorithm based on the set of advertized algorithm and no=
t based on the client.


 


Ad 2) The current text assumes that a reporting node is located in jus=
t one realm. If that is not the case OCSs need to be maintained per realm. =
We may want to look at this when working on 03.


 


Best regards


Ulrich


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: Wednesday, March 26, 2014 8:59 AM


To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion


 


Hi Ulrich


 


1) My point is that the definition of OCS should be sufficiently gener=
ic so to apply to various algorithms. The current definition applies to the=
 default algorithm, but will need to be extended to support the overload mi=
tigation for a specific  client.


For other algorithms, I mentioned the rate control as we will work on =
it. And in my previous mail example, with all clients and the server suppor=
ting selecting the rate control, I currently do not see how to not introduc=
e OCS per client somewhere (in the server or in a DA) to be able to run the=
 rate control.


 


So I propose  to evolve your definition


   


A reporting node maintains per supported Diameter application, per


    selected Abatement Algorithm and eventually per cli=
ent if relevant an Overload


    Control State


 


Such a definition would be more generic and applicable to future algor=
ithms. I think the draft should be future proof.


 


 


2) I am also questioning, if we have not the need to define an OCS per=
 application  per selected algorithm and per realm for a reporting nod=
e (eg  in the DA that is generating Realm reports for request without =
destination hosts; realm OCS is only defined for reacting nodes in your pro=
posal. Here again I would have  the additional question OCS eventually=
 per client    


 


 


Best regards 


 


JJacques 


 


-----Message d'origine-----


De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoy=E9 : mardi 25 mars=
 2014 09:24 =C0 : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: issue #56 proposed co=
nclusion


 


Hi JJacques


 


Your concern is related to issue #35. For #35 we almost reached the co=
nclusion not to address client specific throttling in the 02-draft.


 


The latest proposal to solve #35 was to let clients indicate in OC-Sup=
ported-Features that they are clients; agents taking the role of reacting n=
odes on behalf of clients would not indicate  so. Servers must not req=
uest client specific throtting from reacting nodes that did not indicate th=
at they are clients.


With this (partial) solution of #35 there would not be any impact to m=
y proposal for #56.


 


Best regards


Ulrich


 


 


 


-----Original Message-----


From: DiME [mailto:dime-bounc=
es@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)=



Sent: Monday, March 24, 2014 7:43 PM


To: dime@ietf.org

Subject: Re: [Dime] issue #56 proposed conclusion


 


Hi Ulrich and all


 


Still to complement my remark about question of the mitigation for a g=
iven client 


 


Your description of state is defined per Application and Abatement, so=
 not including the mitigation case of a state for a client (cf my previous =
mail)


 


I al trying to se how it would apply to another abatement algorithm. T=
here is the rate control algorithm that we will study, and here I am questi=
oning if we will not be driven to have a state per client, as the requested=
 rate will be rather specific to a client, some clients may have a small tr=
affic  and others a large traffic, meaning to define a requested rate =
per client somewhere. 


 


So I may again repeat myself that the normal state would be per client=
 in general, which does not exclude to group all clients and consider a sta=
te common to all clients when relevant.


 


This may require some more thinking, but I prefer to remind this point=
, but it also concern other tickets.


 


Best regards 


 


JJacques   


 


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Env=
oy=E9 : lundi 24 mars 2014 19:08 =C0 : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclus=
ion


 


Hi Ulrich


 


In 5.5.1.2 you wrote:


  A reporting node maintains per supported Diameter application a=
nd per


    supported (and eventually selected) Abatement Algor=
ithm an Overload


    Control State


 


but for another ticket, there is the conclusion that reporting node se=
lects one algorithm,  so your wording would become


 


     ...per supported Diameter application and for=
 the


    selected Abatement Algorithm.... 


 


 


I have also the question of the mitigation for a given  client wh=
ich may drives the reporting node to consider a state for a client 


 


Interest of this text is that it clarifies the node behaviors.


 


Best regards


 


JJacques  


 


 


-----Message d'origine-----


De : DiME [mailto:dime-b=
ounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoy=E9=
 : lundi 24 mars 2014 18:24 =C0 : Wiehe, Ulrich (NSN - DE/Munich)=
; dime@ietf.org Objet : Re: [Dime=
] issue #56 proposed conclusion


 


Dear all,


 


I have received a further comment asking not to abbreviate "Overl=
oad Control State" as OCS is used for "Online Charging System&quo=
t;.


 


I'm fine with not abbreviating "Overload Control State".


 


I shall close issue #56 to meet Steve's deadline for the 02-draft, unl=
ess I receive more comments by tomorrow.


 


Ulrich


 


-----Original Message-----


From: Wiehe, Ulrich (NSN - DE/Munich)


Sent: Thursday, March 20, 2014 2:08 PM


To: dime@ietf.org

Subject: issue #56 proposed conclusion


 


#56: Bad Description of Overload Control State


 


 


Dear all,


 


I have received comments from Steve, MCruz and Jouni.


 


I believe all comments are covered by the following proposed text:


 


 


 


    5.5.1.  Overload Control State (OCS)


 


    5.5.1.1   Overload Control States for rea=
cting nodes


 


    A reacting node maintains per supported Diameter ap=
plication


    - a host-type Overload Control State for each Desti=
nation-Host towards


      which it sends host-type requests and


    - a realm-type Overload Control State for each Dest=
ination-Realm towards


      which it sends realm-type requests.


 


    A host-type Overload Control State may be identifie=
d by the pair of


    Application-Id and Destination-Host.

    A realm-type Overload Control State may be identifi=
ed 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-Real=
m could include the


    following information:


    - Sequence number (as reveived in OC-OLR)


    - Time of expiry  (deviated from validity dura=
tion as received in OC-OLR


      and time of reception)


    - Selected Abatement Algorithm (as received in OC-S=
upported-Features)


    - Algorithm specific input data (as received within=
 OC-OLR, e.g.


      Reduction Percentage for Loss)


 


   


    5.5.1.2   Overload Control States fo=
r reporting nodes


 


    A reporting node maintains per supported Diameter a=
pplication and per


    supported (and eventually selected) Abatement Algor=
ithm an Overload


    Control State. 


 


    An Overload Control State may be identified by the =
pair of Application-Id


    and supported Abatement Algorithm.


 


    The Overload Control State for a given pair of Appl=
ication and Abatement


    Algorithm could include the information:=



    - Sequence number


    - Validity Duration and Expiry Time

    - Algorithm specific input data (e.g. Reduction Per=
centage for Loss)


 


    


    5.5.1.3  Maintaining Overload Control Sta=
tes


 


    Reacting nodes create a host-type OCS identified by=
 OCS-Id =3D (app-id,host-id) when receiving


    an answer message of application app-id containing =
an Orig-Host of host-id and a


    host-type OC-OLR AVP unless such host-type OCS alre=
ady exists.


 


    Reacting nodes create a realm-type OCS identified b=
y OCS-Id =3D (app-id,realm-id) when receiving


    an answer message of application app-id containing =
an Orig-Realm of realm-id and a


    realm-type OC-OLR AVP unless such realm type OCS al=
ready exists.


 


    Reacting nodes delete an OCS when it expires (i.e. =
when current time


    minus reception time is greater than validity durat=
ion).


 


    Reacting nodes update the host-type OCS identified =
by OCS-Id =3D (app-id,host-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Host of


    host-id and a host-type OC-OLR AVP with a sequence =
number higher than the


    stored sequence number.


 


    Reacting nodes update the realm-type OCS identified=
 by OCS-Id =3D (app-id,realm-id) when


    receiving an answer message of application app-id c=
ontaining an Orig-Realm of


    realm-id and a realm-type OC-OLR AVP with a sequenc=
e number higher than the


    stored sequence number.


 


    Reporting nodes create an OCS identified by OCS-Id =
=3D (app-id,Alg) when receiving a


    request of application app-id containing an OC-Supp=
orted-Features AVP


    indicating support of the Abatement Algorithm Alg (=
which the reporting


    node selects) while being overloaded, unless such O=
CS already exists.


 


    Reporting nodes delete an OCS when it expires.=



 


    Reporting nodes update the OCS identified by OCS-Id=
 =3D (app-id,Alg) when they detect the


    need to modify the requested amount of application =
app-id traffic reduction.


 


Ulrich


 


 


_______________________________________________


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


 


_______________________________________________


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_E194C2E18676714DACA9C3A2516265D20267A82DFR712WXCHMBA12z_--


From nobody Wed Mar 26 06:16: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 A66F61A00FB for ; Wed, 26 Mar 2014 06:16:11 -0700 (PDT)
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 lpXKRJzNrGmL for ; Wed, 26 Mar 2014 06:16:03 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C58501A00DB for ; Wed, 26 Mar 2014 06:16:02 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id ECC5D22C27C; Wed, 26 Mar 2014 14:16:00 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id C9CBC4C015; Wed, 26 Mar 2014 14:16:00 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 14:16:00 +0100
From: 
To: Steve Donovan , Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPSO0AscXj4P/C40GW6f1v1eWv+5rzV1mg
Date: Wed, 26 Mar 2014 13:15:59 +0000
Message-ID: <16679_1395839760_5332D310_16679_7554_1_6B7134B31289DC4FAF731D844122B36E51D0A2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5331B195.9020402@usdonovans.com> <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com> <5332C4C1.9010801@usdonovans.com>
In-Reply-To: <5332C4C1.9010801@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51D0A2PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.26.121816
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/VY8KiHQPqSl8PFCNeKTSFEs2qws
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Wed, 26 Mar 2014 13:16:12 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51D0A2PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

When determining if a request should be throttled, there are three cases:

- Only a Realm report (based on the definition from the meeting) matches th=
e message -- In this case the Realm report MUST be used to determine if the=
 message is throttled.
- Only a Host report matches the message -- In this case the Host report MU=
ST be used to determine if the message is throttled.
- Both a Realm and Host report match the message -- In this case the Host r=
eport MUST be used to determine if the message is throttled and throttling =
based on the Realm report MUST NOT also be applied to the message.

I'm ok at the moment with this wording, but I don't think we've thought thr=
ough the implications of prioritizing Host reports over Realm reports when =
both apply.  As such, this is open to change in a future version of the dra=
ft.

[LM] OK

>

      > About renaming "Realm" as "Realm-Routed-Request", no strong
      issue as

      > soon as the principle above are kept.

SRD> If we go with your proposal above then there is no name change but rat=
her a change in the definition of Realm report.

[LM] don't think that the current definition needs to be changed. However t=
he behavior of the reacting node should be clarified when both Host and Rea=
lm report type are applicable to a single message.

If we go with Ulrich's proposal then we should change the name from Realm t=
o RRR (or some other name yet to be suggested).

If we go with three reports then we also need to change the name of the exi=
sting Realm report to RRR and redefine Realm to match the above logic.

[LM] let's play with only two for now.

>

      > The need for realm-based type that would apply to any request
      (even

      > if a "Host" exists for a destination-host in the request) was


      > challenged and not retained. Ben was supposed to lock you in
      a room

      > and to convince you that this last report type was not
      needed.

This is NOT my recollection of the decision and is NOT what is reflected in=
 the minutes.  This is also NOT what you say above.

Here's the relevant portion of the minutes:

Report types - there was consensus that Host and Realm report types needed =
to be retained. Ben suggested that if a node sent a Realm report, it needed=
 to be an absolute authority for the realm. Dave did not agree that agents =
needed to be authoritative and felt that clients should be able to make the=
ir own decisions on conflicting realm reports, which Lionel disagreed with.=
 Maria Cruz agreed with both proposals because it would be deployment depen=
dent. Steve said that the draft should provide guidance that a sender of th=
e realm report should be an authority and that realm reports should not con=
tradict. It should provide guidance on what the client should do if does re=
ceive different realm reports. Ben pointed out that, in the case where a re=
alm was sending overload reports, individual servers could send Reductions =
of 0% in their reports to provide more information to clients.


ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a pr=
oposal on whether to remove or to incorporate.

ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Route=
d-Request an open issue.

ACTION: Clarify precedence of the host and realm report types and what acti=
ons to take when they are received.

[LM] ok



>

      > Lionel

      >

      > Envoy=E9 depuis mon Sony Xperia SP d'Orange

      >

      > Steve Donovan  a =E9crit :

      >

      > Consensus is obviously a fleeting and temporary thing.

      >

      > Let us make sure that we are precise in our definitions of
      the

      > report types we are discussing.

      >

      > Host report - Applies when the destination-host AVP is
      present in

      > the request. Realm-Routed-Request (RRR) - Applies when there
      is no

      > destination-host AVP in the request. Realm - Applies to 100%
      of

      > requests sent to the realm.

      >

      > These are the definitions used in our discussions in London
      and in

      > various places in our email discussions.

      >

      > Can we please agree to use these definitions going forward so
      we are

      > all talking about the same thing.

      >

      > Regards,

      >

      > Steve

      >

      > On 3/25/14 10:27 AM, lionel.morand@orange.com wrote:

      >>

      >> Hi Maria Cruz, All,

      >>

      >>

      >>

      >> In the previous mail, you wrote:

      >>

      >>

      >>

      >> /That is, we have two reports, host and realm. /

      >>

      >> /Host applies when Destination_host is present, and then
      it takes

      >> precedence over Realm. If both are present, only Host is
      applied./

      >>

      >> /Realm applies when only Destination_realm is present./

      >>

      >>

      >>

      >> And I agree with this statement. But I'm not sure that
      this is the

      >> case discussed by Ulrich.

      >>

      >>

      >>

      >> Whatever the name of the realm report type, is there an
      agreement

      >> on the description given above by Maria Cruz and
      discussed in

      >> London?

      >>

      >>

      >>

      >> Regards,

      >>

      >>

      >>

      >> Lionel

      >>

      >>

      >>

      >> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
      Maria

      >> Cruz Bartolome *Envoy=E9 :* mardi 25 mars 2014 16:21 *=C0 :*
      Wiehe,

      >> Ulrich (NSN - DE/Munich); ext Steve Donovan;
      dime@ietf.org *Objet

      >> :* Re: [Dime] Resolution on action to discuss the need
      for

      >> Realm-Routed-Reports

      >>

      >>

      >>

      >> Dear all,

      >>

      >>

      >>

      >> I support option 1 a well

      >>

      >> Cheers

      >>

      >> /MCruz

      >>

      >>

      >>

      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *Wiehe,

      >> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de
      2014 16:15

      >>  *To:* ext Steve Donovan; dime@ietf.org *Sub=
ject:* Re:
      [Dime]

      >> Resolution on action to discuss the need for
      Realm-Routed-Reports

      >>

      >>

      >>

      >> Steve,

      >>

      >> Thank you for this summary.

      >>

      >> Please see inline.

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >> *From:*ext Steve Donovan
      [mailto:srdonovan@usdonovans.com] *Sent:*

      >> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN
      -

      >> DE/Munich); dime@ietf.org 
      *Subject:* Re:

      >> [Dime] Resolution on action to discuss the need for

      >> Realm-Routed-Reports

      >>

      >>

      >>

      >> Ulrich,

      >>

      >> I mean going backwards from where I thought we were after
      the

      >> London meeting.

      >>

      >> We are clearly out of sync but hopefully we can fix that.

      >>

      >> Here's my understanding of the status of #23 and #55.

      >>

      >> Prior to London meeting:

      >>

      >> #23 status: - Agreement to change the name of existing
      realm

      >> reports to realm-routed-reports (RRR).

      >>

      >> this includes agreement to keep the (newly
      called)

      >> realm-routed-reports - Discussions were
      ongoing as to the

      >> need for both realm reports and RRR reports.

      >>

      >> I would say "...as to the need for realm
      reports in addition

      >> to realm-routed-reports" 

      >>

      >>

      >>

      >> #55 status: - Agreement on adding Realm reports based on
      the

      >> definition that realm reports apply to all traffic sent
      to the

      >> realm.

      >>

      >> This is what I'm missing. The issue has
      been very briefly

      >> discussed under #34 without conclusion. There was no
      discussion

      >> under #55

      >>

      >>

      >> - Limited discussion on the interaction between the new
      realm

      >> reports and the existing host and RRR reports.

      >>

      >> After London meeting:

      >>

      >> #23 status: - Tentative agreement in London meeting to
      remove RRR

      >> reports.

      >>

      >> What was the technical
      argument?

      >>

      >>

      >> - Ben expressed the strongest concern with this plan.
      Steve and

      >> Ben took action to discuss and come back with a
      recommendation.

      >>

      >> #55 status: - No change

      >>

      >> Summary: - Tentative consensus reached to move forward
      with two

      >> report types - host and realm, with realm having the new


      >> definition. What was the technical
      argument?

      >>

      >>

      >> Current status:

      >>

      >> #23 status: - Change the name to RRR - Whether or not to
      remove

      >> RRR and revisit later or keep RRR and revisit later is an
      open

      >> issue.

      >>

      >> #55 status: - My opinion is that we have at least rough
      consensus

      >> on the need to support realm reports.  Others might have
      a

      >> different opinion.

      >>

      >>  There was no comment posted to issue #55,
      also no

      >> proposed solution, so I cannot see where the consensus
      came

      >> from

      >>

      >>

      >>

      >> Summary: - I believe we have three options:

      >>

      >> 1) Support host and RRR reports 2) Support host and Realm
      reports

      >> -- This was the tentative plan coming out of the London
      meeting

      >>

      >> < Ulrich> There is not even an issue number
      identifying problems

      >> with RRR and proposing to remove RRR

      >>

      >>

      >> 3) Support host, RRR and Realm reports

      >>

      >>  I support option 1

      >>

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >>

      >> Steve,

      >>

      >> I don't think we are going backwards (we may be out of
      synch

      >> though)

      >>

      >>

      >>

      >> Can you please summarize the status of #23 and #55.

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >>

      >>

      >> *From:*ext Steve Donovan
      [mailto:srdonovan@usdonovans.com] *Sent:*

      >> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -


      >> DE/Munich); dime@ietf.org 
      *Subject:* Re:

      >> [Dime] Resolution on action to discuss the need for

      >> Realm-Routed-Reports

      >>

      >>

      >>

      >> Ok, we are going backwards on this one.

      >>

      >> I did not include option three because we had moved past
      that

      >> option in our discussions, both on the list (I thought),
      and in

      >> the meeting.

      >>

      >> I believe that we had come to rough consensus on the need
      for a

      >> realm report and the only remaining issue was whether we
      also

      >> included the RRR report type.

      >>

      >> At this point, the only option is to leave all of the
      issues

      >> related to the report types open and attempt to resolve
      them in

      >> the -03 draft.

      >>

      >> Steve

      >>

      >> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >>

      >> Steve,

      >>

      >>

      >>

      >> I do not agree.

      >>

      >>

      >>

      >> We should still have the option

      >>

      >> 3) support report type 0 (this is called host report) and
      support

      >> of report type 1 (this has been called relam report but
      people

      >> argued it should better be called realm routed request
      report).

      >>

      >>

      >>

      >> Whether or not we need in addition to type 0 and type 1
      (or as a

      >> replacement of type 1) a

      >> realm-no-matter-whether-destination-host-is
      present-or-not report

      >> is an open issue (see #55).

      >>

      >> There are a lot of open questions  with regard to #55 and
      I have

      >> not seen a conclusion.

      >>

      >> Where I have seen a conclusion is issue #34 and that is
      inline

      >> with option 3).

      >>

      >>

      >>

      >> Unless we conclude on #55, or decide to re-open #34,
      option 3) is

      >> what should go in the -02 draft.

      >>

      >>

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *ext

      >> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM
      *To:*

      >> dime@ietf.org  *Subject:* Re:
      [Dime]

      >> Resolution on action to discuss the need for
      Realm-Routed-Reports

      >>

      >>

      >>

      >> Ulrich, All,

      >>

      >> We have two options for the -02 draft.

     >>

      >> 1) Support Host and Realm as proposed below, removing RRR
      reports.

      >>  2) Support Host, Realm and RRR reports.

      >>

      >> The default plan is to go with option 1 in the -02 draft,
      as that

      >> was the proposal that came out of the meeting in London.
      RRR

      >> reports can be added back in if and when we are convinced
      of the

      >> need.

      >>

      >> If there are strong objections to this then I will update
      the -02

      >> draft to reflect all three report types.

      >>

      >> I plan to make these updates Wednesday morning, Dallas,
      Texas

      >> time.

      >>

      >> Either way I do not expect we will have agreed to wording
      on the

      >> interaction between the report types when a reacting node
      has

      >> multiple report types, all of which apply to individual
      requests.

      >> This will need to be addressed in the -03 draft.

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >> On 3/21/14 4:05 PM, Steve Donovan wrote:

      >>

      >> Ulrich,

      >>

      >> The discussion should be captured in the minutes to the
      meeting.

      >> I wasn't able to find them posted yet.

      >>

      >> Jouni, Lionel, what is the status of the minutes for the
      meeting?

      >>

      >> My reading of emails prior to the London meeting is
      different from

      >> yours.  I believe we had come to the conclusion that we
      needed

      >> host and realm (with the definition of realm as outlined
      below).

      >> We were still discussing the need for
      Realm-Routed-Request

      >> reports.

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:

      >>

      >> Steve,

      >>

      >>

      >>

      >> I don't know what happend in London.

      >>

      >> Can you please summarize the technical reasons that led
      to the

      >> London agreement.

      >>

      >> E-mail discussions prior to London have clearly directed
      towards a

      >> report type that requests throttling of realm routed
      request

      >> messages (i.e. not containing a destination host) rather
      than a

      >> report type that requests throttling of messages routed
      towards a

      >> realm (no matter whether they contain a destination host
      or not).

      >>

      >>

      >>

      >>

      >> Ulrich

      >>

      >>

      >>

      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *ext

      >> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM
      *To:*

      >> dime@ietf.org  *Subject:*
      [Dime] Resolution

      >> on action to discuss the need for Realm-Routed-Reports

      >>

      >>

      >>

      >> All,

      >>

      >> Ben and I took the action item to discuss the need for
      the

      >> Realm-Routed-Reports (RRR) report type.

      >>

      >> As you may recall, the consensus coming out of the DIME
      WG meeting

      >> in London was to support two report types:

      >>

      >> - Host -- Impacting requests with a Destination-Host AVP
      matching

      >> the host in the overload report (with the host implicitly


      >> determined from the Origin-Host AVP of the answer message
      carrying

      >> the overload report).

      >>

      >> - Realm -- Impacting 100% of the requests with a
      Destination-Realm

      >> AVP matching the realm in the overload report (with the
      realm

      >> implicitly determine from the Origin-Realm of the answer
      message

      >> carrying the overload report).

      >>

      >> The action Ben and I took was to come back with an
      opinion on

      >> whether RRR reports should also be supported.

      >>

      >> My summary of the discussion is that we recommend to NOT
      include

      >> RRR reports in the current version of the base DOIC
      draft.

      >>

      >> We still have some concerns with the granularity of
      control

      >> enabled by having just the two report types but the
      analysis of

      >> whether RRR reports are still needed can occur
      independent of the

      >> base DOIC draft.  If there is a determination that RRRs
      are needed

      >> in time to include in the base draft then it can be
      considered at

      >> that time.

      >>

      >> Based on this, I propose the following

      >>

      >> - Resolution to issue #23 is to remove RRR reports from
      the

      >> document. - Resolution to issue #55 is to add Realm
      reports

      >> (actually to redefine them per the above definition). -
      Resolution

      >> to issue #57 is that it no longer applies (as it deals
      with RRRs).

      >>

      >> There is also need for text describing the interaction
      between

      >> host and the realm reports.  I don't expect we will have
      consensus

      >> on this wording prior to the -02 draft being submitted.
      To this

      >> end, I'll open a new issue to deal with the need for
      wording on

      >> the interaction.

      >>

      >> Regards,

      >>

      >> Steve

      >>

      >>

      >>

      >>

      >>

      >> _______________________________________________

      >>

      >> 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 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 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

      > 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 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_6B7134B31289DC4FAF731D844122B36E51D0A2PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











When determining if a request s=
hould be throttled, there are three cases:



- Only a Realm report (based on the definition from the meeting) matches th=
e message -- In this case the Realm report MUST be used to determine if the=
 message is throttled.

- Only a Host report matches the message -- In this case the Host report MU=
ST be used to determine if the message is throttled.

- Both a Realm and Host report match the message -- In this case the Host r=
eport MUST be used to determine if the message is throttled and throttling =
based on the Realm report MUST NOT also be applied to the message.



I'm ok at the moment with this wording, but I don't think we've thou=
ght through the implications of prioritizing Host reports over Realm report=
s when both apply.  As such, this is open to change in a future versio=
n of the draft.






[LM] OK<=
/span>




> 






      > About renam=
ing "Realm" as "Realm-Routed-Request", no strong


      issue as 






      > soon as the=
 principle above are kept.



SRD> If we go with your proposal above then there is no name change but =
rather a change in the definition of Realm report.






[LM]=
 don't think that the current definition needs to be changed. However the b=
ehavior of the reacting node should be clarified when both
 Host and Realm report type are applicable to a single message.<=
/span>




If we go with Ulrich's proposal then we should change the name from Realm t=
o RRR (or some other name yet to be suggested).



If we go with three reports then we also need to change the name of the exi=
sting Realm report to RRR and redefine Realm to match the above logic.






[LM]=
 let's play with only two for now.


 


> 






     &=
nbsp;> The need for realm-based type that would apply to any requ=
est


      (even 






      > if a "=
Host" exists for a destination-host in the request) was


      






      > challenged =
and not retained. Ben was supposed to lock you in


      a room 






      > and to conv=
ince you that this last report type was not


      needed.



This is NOT my recollection of the decision and is NOT what is reflected in=
 the minutes.  This is also NOT what you say above.




Here's the relevant portion of the minutes:



Report types - there was consensus that Host and Realm report types needed =
to be retained. Ben suggested that if a node sent a Realm report, it needed=
 to be an absolute authority for the realm. Dave did not agree that agents =
needed to be authoritative and felt
 that clients should be able to make their own decisions on conflicting rea=
lm reports, which Lionel disagreed with. Maria Cruz agreed with both propos=
als because it would be deployment dependent. Steve said that the draft sho=
uld provide guidance that a sender
 of the realm report should be an authority and that realm reports should n=
ot contradict. It should provide guidance on what the client should do if d=
oes receive different realm reports. Ben pointed out that, in the case wher=
e a realm was sending overload reports,
 individual servers could send Reductions of 0% in their reports to provide=
 more information to clients.






ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a pr=
oposal on whether to remove or to incorporate.




ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Route=
d-Request an open issue.




ACTION: Clarify precedence of the host and realm report types and what acti=
ons to take when they are received.







[LM] ok<=
/span>








> 






      > Lionel






      > 






      > Envoy=E9 de=
puis mon Sony Xperia SP d'Orange






      > 






      > Steve Donov=
an 
<srdonovan@usdonovans.com> a =E9crit :






      > 






      > Consensus i=
s obviously a fleeting and temporary thing.






      > 






      > Let us make=
 sure that we are precise in our definitions of


      the






      > report types we =
are discussing.






      > 






      > Host report=
 - Applies when the destination-host AVP is


      present in






      > the request. Rea=
lm-Routed-Request (RRR) - Applies when there


      is no 






      > destination=
-host AVP in the request. Realm - Applies to 100%


      of 






      > requests se=
nt to the realm.






      > 






      > These are t=
he definitions used in our discussions in London


      and in 






      > various pla=
ces in our email discussions.






      > 






      > Can we plea=
se agree to use these definitions going forward so


      we are 






      > all talking=
 about the same thing.






      > 






      > Regards,






      > 






      > Steve






      > 






      > On 3/25/14 =
10:27 AM, 
lionel.morand@orange.com wrote:






      >> 






      >> Hi Mari=
a Cruz, All,






      >> 






      >> 






      >> 






      >> In the =
previous mail, you wrote:






      >> 






      >> 






      >> 






      >> /That i=
s, we have two reports, host and realm. /






      >> 






      >> /Host a=
pplies when Destination_host is present, and then


      it takes 






      >> precede=
nce over Realm. If both are present, only Host is


      applied./






      >> 






      >> /Realm =
applies when only Destination_realm is present./






      >> 






      >> 






      >> 






      >> And I a=
gree with this statement. But I'm not sure that


      this is the 






      >> case di=
scussed by Ulrich.






      >> 






      >> 






      >> 






      >> Whateve=
r the name of the realm report type, is there an


      agreement 






      >> on the =
description given above by Maria Cruz and


      discussed in 






      >> London?=







      >> 






      >> 






      >> 






      >> Regards=
,






      >> 






      >> 






      >> 






      >> Lionel<=
br>





      >> 






      >> 






      >> 






      >> *De :*D=
iME [mailto:dime-bounces@ietf.org<=
/a>] *De la part de*


      Maria 






      >> Cruz Ba=
rtolome *Envoy=E9 :* mardi 25 mars 2014 16:21 *=C0 :*


      Wiehe, 






      >> Ulrich =
(NSN - DE/Munich); ext Steve Donovan;


      dime@ietf.org *Objet







      >> :* Re: =
[Dime] Resolution on action to discuss the need


      for 






      >> Realm-R=
outed-Reports






      >> 






      >> 






      >> 






      >> Dear al=
l,






      >> 






      >> 






      >> 






      >> I suppo=
rt option 1 a well






      >> 






      >> Cheers<=
br>





      >> 






      >> /MCruz<=
br>





      >> 






      >> 






      >> 






      >> *From:*=
DiME [mailto:dime-bounces@ietf.org=
] *On Behalf Of


      *Wiehe, 






      >> Ulrich =
(NSN - DE/Munich) *Sent:* martes, 25 de marzo de


      2014 16:15






      >>  *To:* =
ext Steve Donovan; 
dime@ietf.org *Subject:* Re:


      [Dime] 






      >> Resolut=
ion on action to discuss the need for


      Realm-Routed-Reports<=
br>





      >> 






      >> 






      >> 






      >> Steve,<=
br>





      >> 






      >> Thank y=
ou for this summary.






      >> 






      >> Please =
see inline.






      >> 






      >> 






      >> 






      >> Ulrich<=
br>





      >> 






      >> 






      >> 






      >> *From:*=
ext Steve Donovan


      [mailto:srdonovan@usdonovans.com] *Sent:*







      >> Tuesday=
, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN


      - 






      >> DE/Muni=
ch); dime@ietf.org
<mailto:dime@ietf.org>


      *Subject:* Re: 






      >> [Dime] =
Resolution on action to discuss the need for







      >> Realm-R=
outed-Reports






      >> 






      >> 






      >> 






      >> Ulrich,=







      >> 






      >> I mean =
going backwards from where I thought we were after


      the 






      >> London =
meeting.






      >> 






      >> We are =
clearly out of sync but hopefully we can fix that.






      >> 






      >> Here's =
my understanding of the status of #23 and #55.






      >> 






      >> Prior t=
o London meeting:






      >> 






      >> #23 sta=
tus: - Agreement to change the name of existing


      realm 






      >> reports=
 to realm-routed-reports (RRR).






      >> 






      >> <Ulr=
ich>this includes agreement to keep the (newly


      called) 






      >> realm-r=
outed-reports</Ulrich> - Discussions were


      ongoing as to the 






      >> need fo=
r both realm reports and RRR reports.






      >> 






      >> <Ulr=
ich>I would say “…as to the need for realm


      reports in addition <=
br>





      >> to real=
m-routed-reports” </Ulrich>






      >> 






      >> 






      >> 






      >> #55 sta=
tus: - Agreement on adding Realm reports based on


      the 






      >> definit=
ion that realm reports apply to all traffic sent


      to the 






      >> realm.<=
br>





      >> 






      >> <Ulr=
ich>This is what I’m missing. The issue has


      been very briefly 






      >> discuss=
ed under #34 without conclusion. There was no


      discussion 






      >> under #=
55</Ulrich>






      >> 






      >> 






      >> - Limit=
ed discussion on the interaction between the new


      realm 






      >> reports=
 and the existing host and RRR reports.






      >> 






      >> After L=
ondon meeting:






      >> 






      >> #23 sta=
tus: - Tentative agreement in London meeting to


      remove RRR 






      >> reports=
.






      >> 






      >> <Ulr=
ich>What was the technical


      argument?</Ulrich&=
gt;






      >> 






      >> 






      >> - Ben e=
xpressed the strongest concern with this plan. 


      Steve and 






      >> Ben too=
k action to discuss and come back with a


      recommendation.






      >> 






      >> #55 sta=
tus: - No change






      >> 






      >> Summary=
: - Tentative consensus reached to move forward


      with two 






      >> report =
types - host and realm, with realm having the new


      






      >> definit=
ion. <Ulrich>What was the technical


      argument?</Ulrich&=
gt;






      >> 






      >> 






      >> Current=
 status:






      >> 






      >> #23 sta=
tus: - Change the name to RRR - Whether or not to


      remove






      >> RRR and revi=
sit later or keep RRR and revisit later is an


      open






      >> issue.






      >> 






      >> #55 sta=
tus: - My opinion is that we have at least rough


      consensus 






      >> on the =
need to support realm reports.  Others might have


      a 






      >> differe=
nt opinion.






      >> 






      >> <Ulr=
ich> There was no comment posted to issue #55,


      also no






      >> proposed sol=
ution, so I cannot see where the consensus


      came






      >> from</Ulr=
ich>






      >> 






      >> 






      >> 






      >> Summary=
: - I believe we have three options:






      >> 






      >> 1) Supp=
ort host and RRR reports 2) Support host and Realm


      reports 






      >> -- This=
 was the tentative plan coming out of the London


      meeting






      >> 






      >> < Ul=
rich> There is not even an issue number


      identifying problems =







      >> with RR=
R and proposing to remove RRR</Ulrich>






      >> 






      >> 






      >> 3) Supp=
ort host, RRR and Realm reports






      >> 






      >> <Ulr=
ich> I support option 1</Ulrich>






      >> 






      >> 






      >> Regards=
,






      >> 






      >> Steve





      >> 






      >> On 3/25=
/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)


      wrote:






      >> 






      >> Steve,<=
br>





      >> 






      >> I don&#=
8217;t think we are going backwards (we may be out of


      synch 






      >> though)=







      >> 






      >> 






      >> 






      >> Can you=
 please summarize the status of #23 and #55.






      >> 






      >> 






      >> 






      >> Ulrich<=
br>





      >> 






      >> 






      >> 






      >> 






      >> 






      >> *From:*=
ext Steve Donovan


      [mailto:srdonovan@usdonovans.com] *Sent:*







      >> Monday,=
 March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -


      






      >> DE/Muni=
ch); dime@ietf.org
<mailto:dime@ietf.org>


      *Subject:* Re: 






      >> [Dime] =
Resolution on action to discuss the need for







      >> Realm-R=
outed-Reports






      >> 






      >> 






      >> 






      >> Ok, we =
are going backwards on this one.






      >> 






      >> I did n=
ot include option three because we had moved past


      that 






      >> option =
in our discussions, both on the list (I thought),


      and in






      >> the meeting.=







      >> 






      >> I belie=
ve that we had come to rough consensus on the need


      for a 






      >> realm r=
eport and the only remaining issue was whether we


      also 






      >> include=
d the RRR report type.






      >> 






      >> At this=
 point, the only option is to leave all of the


      issues 






      >> related=
 to the report types open and attempt to resolve


      them in






      >> the -03 draf=
t.






      >> 






      >> Steve





      >> 






      >> On 3/24=
/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)


      wrote:






      >> 






      >> Steve,<=
br>





      >> 






      >> 






      >> 






      >> I do no=
t agree.






      >> 






      >> 






      >> 






      >> We shou=
ld still have the option






      >> 






      >> 3) supp=
ort report type 0 (this is called host report) and


      support 






      >> of repo=
rt type 1 (this has been called relam report but


      people 






      >> argued =
it should better be called realm routed request


      report).






      >> 






      >> 






      >> 






      >> Whether=
 or not we need in addition to type 0 and type 1


      (or as a 






      >> replace=
ment of type 1) a 






      >> realm-n=
o-matter-whether-destination-host-is


      present-or-not report=
 






      >> is an o=
pen issue (see #55).






      >> 






      >> There a=
re a lot of open questions  with regard to #55 and


      I have 






      >> not see=
n a conclusion.






      >> 






      >> Where I=
 have seen a conclusion is issue #34 and that is


      inline






      >> with option =
3).






      >> 






      >> 






      >> 






      >> Unless =
we conclude on #55, or decide to re-open #34,


      option 3) is 






      >> what sh=
ould go in the -02 draft.






      >> 






      >> 






      >> 






      >> 






      >> 






      >> Ulrich<=
br>





      >> 






      >> 






      >> 






      >> *From:*=
DiME [mailto:dime-bounces@ietf.org=
] *On Behalf Of


      *ext






      >> Steve Donova=
n *Sent:* Monday, March 24, 2014 2:57 PM


      *To:*






      >> dime@ietf.org 
<mailto:dime@ietf.org> *Subject:* Re:


      [Dime]






      >> Resolution o=
n action to discuss the need for


      Realm-Routed-Reports<=
br>





      >> 






      >> 






      >> 






      >> Ulrich,=
 All,






      >> 






      >> We have=
 two options for the -02 draft.






     >> 






      >> 1) Supp=
ort Host and Realm as proposed below, removing RRR


      reports.






      >>  2) Sup=
port Host, Realm and RRR reports.






      >> 






      >> The def=
ault plan is to go with option 1 in the -02 draft,


      as that 






      >> was the=
 proposal that came out of the meeting in London. 


      RRR 






      >> reports=
 can be added back in if and when we are convinced


      of the 






      >> need.





      >> 






      >> If ther=
e are strong objections to this then I will update


      the -02 






      >> draft t=
o reflect all three report types.






      >> 






      >> I plan =
to make these updates Wednesday morning, Dallas,


      Texas 






      >> time.





      >> 






      >> Either =
way I do not expect we will have agreed to wording


      on the 






      >> interac=
tion between the report types when a reacting node


      has 






      >> multipl=
e report types, all of which apply to individual


      requests. 






      >> This wi=
ll need to be addressed in the -03 draft.






      >> 






      >> Regards=
,






      >> 






      >> Steve





      >> 






      >> On 3/21=
/14 4:05 PM, Steve Donovan wrote:






      >> 






      >> Ulrich,=







      >> 






      >> The dis=
cussion should be captured in the minutes to the


      meeting.






      >> I wasn't abl=
e to find them posted yet.






      >> 






      >> Jouni, =
Lionel, what is the status of the minutes for the


      meeting?






      >> 






      >> My read=
ing of emails prior to the London meeting is


      different from 






      >> yours.&=
nbsp; I believe we had come to the conclusion that we


      needed






      >> host and rea=
lm (with the definition of realm as outlined


      below).






      >> We were stil=
l discussing the need for


      Realm-Routed-Request<=
br>





      >> reports.






      >> 






      >> Regards=
,






      >> 






      >> Steve





      >> 






      >> On 3/21=
/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)


      wrote:






      >> 






      >> Steve,<=
br>





      >> 






      >> 






      >> 






      >> I don&#=
8217;t know what happend in London.






      >> 






      >> Can you=
 please summarize the technical reasons that led


      to the 






      >> London =
agreement.






      >> 






      >> E-mail =
discussions prior to London have clearly directed


      towards a 






      >> report =
type that requests throttling of realm routed


      request 






      >> message=
s (i.e. not containing a destination host) rather


      than a 






      >> report =
type that requests throttling of messages routed


      towards a 






      >> realm (=
no matter whether they contain a destination host


      or not).






      >> 






      >> 






      >> 






      >> 






      >> Ulrich<=
br>





      >> 






      >> 






      >> 






      >> *From:*=
DiME [mailto:dime-bounces@ietf.org=
] *On Behalf Of


      *ext






      >> Steve Donova=
n *Sent:* Friday, March 21, 2014 3:33 PM


      *To:*






      >> dime@ietf.org 
<mailto:dime@ietf.org> *Subject:*


      [Dime] Resolution






      >> on action to=
 discuss the need for Realm-Routed-Reports






      >> 






      >> 






      >> 






      >> All,






      >> 






      >> Ben and=
 I took the action item to discuss the need for


      the 






      >> Realm-R=
outed-Reports (RRR) report type.






      >> 






      >> As you =
may recall, the consensus coming out of the DIME


      WG meeting 






      >> in Lond=
on was to support two report types:






      >> 






      >> - Host =
-- Impacting requests with a Destination-Host AVP


      matching 






      >> the hos=
t in the overload report (with the host implicitly


      






      >> determi=
ned from the Origin-Host AVP of the answer message


      carrying 






      >> the ove=
rload report).






      >> 






      >> - Realm=
 -- Impacting 100% of the requests with a


      Destination-Realm 






      >> AVP mat=
ching the realm in the overload report (with the


      realm 






      >> implici=
tly determine from the Origin-Realm of the answer


      message 






      >> carryin=
g the overload report).






      >> 






      >> The act=
ion Ben and I took was to come back with an


      opinion on 






      >> whether=
 RRR reports should also be supported.






      >> 






      >> My summ=
ary of the discussion is that we recommend to NOT


      include 






      >> RRR rep=
orts in the current version of the base DOIC


      draft.






      >> 






      >> We stil=
l have some concerns with the granularity of


      control






      >> enabled by h=
aving just the two report types but the


      analysis of






      >> whether RRR =
reports are still needed can occur


      independent of the






      >> base DOIC dr=
aft.  If there is a determination that RRRs


      are needed






      >> in time to i=
nclude in the base draft then it can be


      considered at






      >> that time.





      >> 






      >> Based o=
n this, I propose the following






      >> 






      >> - Resol=
ution to issue #23 is to remove RRR reports from


      the 






      >> documen=
t. - Resolution to issue #55 is to add Realm


      reports 






      >> (actual=
ly to redefine them per the above definition). -


      Resolution 






      >> to issu=
e #57 is that it no longer applies (as it deals


      with RRRs).






      >> 






      >> There i=
s also need for text describing the interaction


      between






      >> host and the=
 realm reports.  I don't expect we will have


      consensus






      >> on this word=
ing prior to the -02 draft being submitted. 


      To this






      >> end, I'll op=
en a new issue to deal with the need for


      wording on






      >> the interact=
ion.






      >> 






      >> Regards=
,






      >> 






      >> Steve





      >> 






      >> 






      >> 






      >> 






      >> 






      >> _______=
________________________________________






      >> 






      >> DiME ma=
iling list






      >> 






      >> DiME@ietf.org 
<mailto: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 s=
ans autorisation. Si vous 






      >> avez re=
cu ce message par erreur, veuillez le signaler a







      >> l'exped=
iteur et le detruire ainsi que les pieces jointes.


      Les 






      >> message=
s electroniques etant susceptibles d'alteration,


      Orange 






      >> decline=
 toute responsabilite si ce message a ete altere,


      deforme






      >> ou falsifie.=
 Merci.






      >> 






      >> This me=
ssage and its attachments may contain confidential


      or 






      >> privile=
ged information that may be protected by law; they


      should 






      >> not be =
distributed, used or copied without authorisation.


      If you 






      >> have re=
ceived 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 fals=
ified. Thank you.






      > 






      ><=
/p>

____________________________________________________=
_____________________________________________________________________






      >






      >






      >






      > 

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 autorisat=
ion. Si vous 






      > avez recu c=
e message par erreur, veuillez le signaler a


      l'expediteur 






      > et le detru=
ire ainsi que les pieces jointes. Les messages







      > electroniqu=
es etant susceptibles d'alteration, Orange decline


      toute 






      > responsabil=
ite si ce message a ete altere, deforme ou


      falsifie. 






      > Merci.






      > 






      > This messag=
e and its attachments may contain confidential or


      






      > privileged =
information that may be protected by law; they


      should not 






      > be distribu=
ted, used or copied without authorisation. If you


      have 






      > received th=
is email in error, please notify the sender and


      delete 






      > this messag=
e and its attachments. As emails may be altered,


      Orange






      > is not liable fo=
r messages that have been modified, changed


      or 






   &nb=
sp;  > falsified. Thank you.








______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E51D0A2PEXCVZYM13corpora_--


From nobody Wed Mar 26 06:33:39 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 84D411A0327 for ; Wed, 26 Mar 2014 06:33:37 -0700 (PDT)
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 t_RMfHRJxW1g for ; Wed, 26 Mar 2014 06:33:28 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id D247D1A00F9 for ; Wed, 26 Mar 2014 06:33:28 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:62537 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSnxL-00054x-HI for dime@ietf.org; Wed, 26 Mar 2014 06:33:26 -0700
Message-ID: <5332D724.7080903@usdonovans.com>
Date: Wed, 26 Mar 2014 08:33:24 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net>   <5BCBA1FC2B7F0B4C9D935572D9000668151D202E@DEMUMBX014.nsn-intra.net>  <5BCBA1FC2B7F0B4C9D935572D9000668151D2462@DEMUMBX014.nsn-intra.net>  <5332C7B4.4060805@usdonovans.com>  <5332CD09.5050706@usdonovans.com> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000703090103020203090605"
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/G49t7hC2lwYKsNPEBJwah33_GzU
Subject: Re: [Dime] issue #56 proposed 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: Wed, 26 Mar 2014 13:33:37 -0000

This is a multi-part message in MIME format.
--------------000703090103020203090605
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

JJ,

I agree, we need wording around extensibility.

My concern, however, was that adding wording around client specific
reports might mean we should also put wording around peer reports that
would be used for agent overload.

Is it ok to defer the extensibility wording to be addressed in -03 and
go with Ulrich's suggestion?  I have a good deal of work to do to get
the -02 draft published prior to next weeks CT4 meeting and this would
let me focus there.

Regards,

Steve

On 3/26/14 8:07 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
> Steve
>
>  
>
> A sentence about extensibility of the OSC is for me necessary, not
> only on  the information it can store but also on the access keys (eg
> per reacting nodes), otherwise the OCS as currently described for
> which it should have a large appliance perimeter has already two
> exceptions, the specific client % reduction percentage  with the loss
> algorithm and your control rate case.
>
>  
>
> Best regards
>
>  
>
> JJacques
>
>  
>
>  
>
> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve Donovan
> *Envoyé :* mercredi 26 mars 2014 13:50
> *À :* dime@ietf.org
> *Objet :* Re: [Dime] issue #56 proposed conclusion
>
>  
>
> JJ,
>
> There is nothing in the draft that prevents extending the amount of
> state saved by a reporting node.
>
> We do probably need to add more on extensibility into the draft and
> one of the suggestions for any extension should be to expand on the
> discussion of how OCS is impacted by the extension.
>
> Regards,
>
> Steve
>
> On 3/26/14 7:37 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>     Hi Steve
>
>      
>
>     When reading your draft  about Rate control, we have
>
>             The server must allocate a portion of the
>
>        target Diameter request rate to each of its reacting nodes.  The
>
>        server may set the same rate for every reacting node, or may set
>
>        different rates for different reacting node.
>
>     I am OK with this statement. For me it implies  the reporting node
>     (server)  to have a n OCS per reacting node if the rates are
>     different .
>
>     So  I am a bit surprised you do not take this example  into
>     account in the draft that should be future proof in its wording
>     even if the OCS is not normative, but has a general meaning
>     applicable to various algorithm and not only to the loss algorithm.
>
>      
>
>     Best regards
>
>      
>
>     JJacques
>
>        
>
>      
>
>     *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de* Steve
>     Donovan
>     *Envoyé :* mercredi 26 mars 2014 13:28
>     *À :* dime@ietf.org 
>     *Objet :* Re: [Dime] issue #56 proposed conclusion
>
>      
>
>     JJ,
>
>     I am not in favor of your suggestion.  I won't restate -- its in
>     my previous email.
>
>     Steve
>
>     On 3/26/14 3:51 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
>
>         Hi Ulrich
>
>          
>
>         1) I understand and agree it is good to have a text in v02 on OCS definition. #35 will deal on the protocol aspects about DOIC information transfer for client mitigation in te loss algorithm context .  But regarding OCS definition I prefer to have the OCS definition currently covering a larger scope that may be reviewed if needed in 03 than to do the reverse. For loss algorithm, in the dedicated part for loss that Ben mentioned, we can later add that the per client OCS case would be used for a specific client mitigation. For  other algorithms (eg rate control) we will see which type of OCS to apply , but it will remain compliant with the general definition. So I remain in favor of my proposal, why not to introduce it?
>
>          
>
>         2) about realm OCS, it is to identify the OCS associated to the generation of a realm OLR, as this OCS will store the 
>
>         Reduction percentage for the realm.
>
>          
>
>         Best regards
>
>          
>
>         JJacques   
>
>          
>
>          
>
>         -----Message d'origine-----
>
>         De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
>
>         Envoyé : mercredi 26 mars 2014 09:26
>
>         À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org 
>
>         Objet : RE: issue #56 proposed conclusion
>
>          
>
>         Hi JJacques,
>
>          
>
>         In order to meet Steve's deadline for the 02-draft I would like to close #56 as proposed by Steve.
>
>         This does not mean that we cannot improve text for 03.
>
>          
>
>         Ad 1) I don't think that the definition of OCS is Loss specific. Whether we need client-specific OCS should be discussed under #35. As we have it now there is one OCS shared for all reacting nodes with which the same algorithm was negotiated.
>
>         This of course limits agents taking the role of a reacting node for two clients C1 and C2 to advertize the same set of algorithm, and reacting nodes to select the algorithm based on the set of advertized algorithm and not based on the client.
>
>          
>
>         Ad 2) The current text assumes that a reporting node is located in just one realm. If that is not the case OCSs need to be maintained per realm. We may want to look at this when working on 03.
>
>          
>
>         Best regards
>
>         Ulrich
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>         Sent: Wednesday, March 26, 2014 8:59 AM
>
>         To: dime@ietf.org 
>
>         Subject: Re: [Dime] issue #56 proposed conclusion
>
>          
>
>         Hi Ulrich
>
>          
>
>         1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.
>
>         For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.
>
>          
>
>         So I propose  to evolve your definition
>
>            
>
>         A reporting node maintains per supported Diameter application, per
>
>             selected Abatement Algorithm and eventually per client if relevant an Overload
>
>             Control State
>
>          
>
>         Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.
>
>          
>
>          
>
>         2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    
>
>          
>
>          
>
>         Best regards 
>
>          
>
>         JJacques 
>
>          
>
>         -----Message d'origine-----
>
>         De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org  Objet : RE: issue #56 proposed conclusion
>
>          
>
>         Hi JJacques
>
>          
>
>         Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.
>
>          
>
>         The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.
>
>         With this (partial) solution of #35 there would not be any impact to my proposal for #56.
>
>          
>
>         Best regards
>
>         Ulrich
>
>          
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
>
>         Sent: Monday, March 24, 2014 7:43 PM
>
>         To: dime@ietf.org 
>
>         Subject: Re: [Dime] issue #56 proposed conclusion
>
>          
>
>         Hi Ulrich and all
>
>          
>
>         Still to complement my remark about question of the mitigation for a given client 
>
>          
>
>         Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)
>
>          
>
>         I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 
>
>          
>
>         So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.
>
>          
>
>         This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.
>
>          
>
>         Best regards 
>
>          
>
>         JJacques   
>
>          
>
>          
>
>         -----Message d'origine-----
>
>         De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org  Objet : Re: [Dime] issue #56 proposed conclusion
>
>          
>
>         Hi Ulrich
>
>          
>
>         In 5.5.1.2 you wrote:
>
>           A reporting node maintains per supported Diameter application and per
>
>             supported (and eventually selected) Abatement Algorithm an Overload
>
>             Control State
>
>          
>
>         but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become
>
>          
>
>              ...per supported Diameter application and for the
>
>             selected Abatement Algorithm.... 
>
>          
>
>          
>
>         I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 
>
>          
>
>         Interest of this text is that it clarifies the node behaviors.
>
>          
>
>         Best regards
>
>          
>
>         JJacques  
>
>          
>
>          
>
>         -----Message d'origine-----
>
>         De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org  Objet : Re: [Dime] issue #56 proposed conclusion
>
>          
>
>         Dear all,
>
>          
>
>         I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".
>
>          
>
>         I'm fine with not abbreviating "Overload Control State".
>
>          
>
>         I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.
>
>          
>
>         Ulrich
>
>          
>
>         -----Original Message-----
>
>         From: Wiehe, Ulrich (NSN - DE/Munich)
>
>         Sent: Thursday, March 20, 2014 2:08 PM
>
>         To: dime@ietf.org 
>
>         Subject: issue #56 proposed conclusion
>
>          
>
>         #56: Bad Description of Overload Control State
>
>          
>
>          
>
>         Dear all,
>
>          
>
>         I have received comments from Steve, MCruz and Jouni.
>
>          
>
>         I believe all comments are covered by the following proposed text:
>
>          
>
>          
>
>          
>
>             5.5.1.  Overload Control State (OCS)
>
>          
>
>             5.5.1.1   Overload Control States for reacting nodes
>
>          
>
>             A reacting node 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 towards
>
>               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 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
>
>             following information:
>
>             - Sequence number (as reveived in OC-OLR)
>
>             - Time of expiry  (deviated from validity duration as received in OC-OLR
>
>               and time of reception)
>
>             - Selected Abatement Algorithm (as received in OC-Supported-Features)
>
>             - Algorithm specific input data (as received within OC-OLR, e.g.
>
>               Reduction Percentage for Loss)
>
>          
>
>            
>
>             5.5.1.2   Overload Control States for reporting nodes
>
>          
>
>             A reporting node maintains per supported Diameter application and per
>
>             supported (and eventually selected) Abatement Algorithm an Overload
>
>             Control State. 
>
>          
>
>             An Overload Control State may be identified by the pair of Application-Id
>
>             and supported Abatement Algorithm.
>
>          
>
>             The Overload Control State for a given pair of Application and Abatement
>
>             Algorithm could include the information:
>
>             - Sequence number
>
>             - Validity Duration and Expiry Time
>
>             - Algorithm specific input data (e.g. Reduction Percentage for Loss)
>
>          
>
>             
>
>             5.5.1.3  Maintaining Overload Control States
>
>          
>
>             Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving
>
>             an answer message of application app-id containing an Orig-Host of host-id and a
>
>             host-type OC-OLR AVP unless such host-type OCS already exists.
>
>          
>
>             Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving
>
>             an answer message of application app-id containing an Orig-Realm of realm-id and a
>
>             realm-type OC-OLR AVP unless such realm type OCS already exists.
>
>          
>
>             Reacting nodes delete an OCS when it expires (i.e. when current time
>
>             minus reception time is greater than validity duration).
>
>          
>
>             Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when
>
>             receiving an answer message of application app-id containing an Orig-Host of
>
>             host-id and a host-type OC-OLR AVP with a sequence number higher than the
>
>             stored sequence number.
>
>          
>
>             Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when
>
>             receiving an answer message of application app-id containing an Orig-Realm of
>
>             realm-id and a realm-type OC-OLR AVP with a sequence number higher than the
>
>             stored sequence number.
>
>          
>
>             Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a
>
>             request of application app-id containing an OC-Supported-Features AVP
>
>             indicating support of the Abatement Algorithm Alg (which the reporting
>
>             node selects) while being overloaded, unless such OCS already exists.
>
>          
>
>             Reporting nodes delete an OCS when it expires.
>
>          
>
>             Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the
>
>             need to modify the requested amount of application app-id traffic reduction.
>
>          
>
>         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
>
>          
>
>         _______________________________________________
>
>         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


--------------000703090103020203090605
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    JJ,

      

      I agree, we need wording around extensibility.

      

      My concern, however, was that adding wording around client
      specific reports might mean we should also put wording around peer
      reports that would be used for agent overload.

      

      Is it ok to defer the extensibility wording to be addressed in -03
      and go with Ulrich's suggestion?  I have a good deal of work to do
      to get the -02 draft published prior to next weeks CT4 meeting and
      this would let me focus there.

      

      Regards,

      

      Steve

      

    
    
On 3/26/14 8:07 AM, TROTTIN,
      JEAN-JACQUES (JEAN-JACQUES) wrote:

    

    

      
      
      
      

        
Steve

        
 

        
A
            sentence about extensibility of the OSC is for me necessary,
            not only on  the information it can store but also on the
            access keys (eg per reacting nodes), otherwise the OCS as
            currently described for which it should have a large
            appliance perimeter has already two exceptions, the specific
            client % reduction percentage  with the loss algorithm and
            your control rate case.
            

        
 

        
Best
            regards

        
 

        
JJacques
            

        
 

        
 

        

          

            
De : DiME [mailto:dime-bounces@ietf.org]
                De la part de Steve Donovan

                Envoyé : mercredi 26 mars 2014 13:50

                À : dime@ietf.org

                Objet : Re: [Dime] issue #56 proposed conclusion

          

        

        
 

        
JJ,

          

          There is nothing in the draft that prevents extending the
          amount of state saved by a reporting node.

          

          We do probably need to add more on extensibility into the
          draft and one of the suggestions for any extension should be
          to expand on the discussion of how OCS is impacted by the
          extension.

          

          Regards,

          

          Steve

        

          
On 3/26/14 7:37 AM, TROTTIN, JEAN-JACQUES
            (JEAN-JACQUES) wrote:

        

        

          
Hi
              Steve

          
 

          
When
              reading your draft  about Rate control, we have

          
        The
              server must allocate a portion of the

          
   target
              Diameter request rate to each of its reacting nodes.  The

          
   server may
              set the same rate for every reacting node, or may set

          
   different
              rates for different reacting node.

          
I
              am OK with this statement. For me it implies  the
              reporting node (server)  to have a n OCS per reacting node
              if the rates are different .

          
So
               I am a bit surprised you do not take this example  into
              account in the draft that should be future proof in its
              wording even if the OCS is not normative, but has a
              general meaning applicable to various algorithm and not
              only to the loss algorithm.

          
 

          
Best
              regards

          
 

          
JJacques
            

          
   

          
 

          

            

              
De : DiME [mailto:dime-bounces@ietf.org]
                  De la part de Steve Donovan

                  Envoyé : mercredi 26 mars 2014 13:28

                  À : dime@ietf.org

                  Objet : Re: [Dime] issue #56 proposed
                  conclusion

            

          

          
 

          
JJ,

            

            I am not in favor of your suggestion.  I won't restate --
            its in my previous email.

            

            Steve

          

            
On 3/26/14 3:51 AM, TROTTIN,
              JEAN-JACQUES (JEAN-JACQUES) wrote:

          

          

            
Hi Ulrich

            
 

            
1) I understand and agree it is good to have a text in v02 on OCS definition. #35 will deal on the protocol aspects about DOIC information transfer for client mitigation in te loss algorithm context .  But regarding OCS definition I prefer to have the OCS definition currently covering a larger scope that may be reviewed if needed in 03 than to do the reverse. For loss algorithm, in the dedicated part for loss that Ben mentioned, we can later add that the per client OCS case would be used for a specific client mitigation. For  other algorithms (eg rate control) we will see which type of OCS to apply , but it will remain compliant with the general definition. So I remain in favor of my proposal, why not to introduce it?

            
 

            
2) about realm OCS, it is to identify the OCS associated to the generation of a realm OLR, as this OCS will store the 

            
Reduction percentage for the realm.

            
 

            
Best regards

            
 

            
JJacques   

            
 

            
 

            
-----Message d'origine-----

            
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 

            
Envoyé : mercredi 26 mars 2014 09:26

            
À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org

            
Objet : RE: issue #56 proposed conclusion

            
 

            
Hi JJacques,

            
 

            
In order to meet Steve's deadline for the 02-draft I would like to close #56 as proposed by Steve.

            
This does not mean that we cannot improve text for 03.

            
 

            
Ad 1) I don't think that the definition of OCS is Loss specific. Whether we need client-specific OCS should be discussed under #35. As we have it now there is one OCS shared for all reacting nodes with which the same algorithm was negotiated.

            
This of course limits agents taking the role of a reacting node for two clients C1 and C2 to advertize the same set of algorithm, and reacting nodes to select the algorithm based on the set of advertized algorithm and not based on the client.

            
 

            
Ad 2) The current text assumes that a reporting node is located in just one realm. If that is not the case OCSs need to be maintained per realm. We may want to look at this when working on 03.

            
 

            
Best regards

            
Ulrich

            
 

            
 

            
-----Original Message-----

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

            
Sent: Wednesday, March 26, 2014 8:59 AM

            
To: dime@ietf.org

            
Subject: Re: [Dime] issue #56 proposed conclusion

            
 

            
Hi Ulrich

            
 

            
1) My point is that the definition of OCS should be sufficiently generic so to apply to various algorithms. The current definition applies to the default algorithm, but will need to be extended to support the overload mitigation for a specific  client.

            
For other algorithms, I mentioned the rate control as we will work on it. And in my previous mail example, with all clients and the server supporting selecting the rate control, I currently do not see how to not introduce OCS per client somewhere (in the server or in a DA) to be able to run the rate control.

            
 

            
So I propose  to evolve your definition

            
   

            
A reporting node maintains per supported Diameter application, per

            
    selected Abatement Algorithm and eventually per client if relevant an Overload

            
    Control State

            
 

            
Such a definition would be more generic and applicable to future algorithms. I think the draft should be future proof.

            
 

            
 

            
2) I am also questioning, if we have not the need to define an OCS per application  per selected algorithm and per realm for a reporting node (eg  in the DA that is generating Realm reports for request without destination hosts; realm OCS is only defined for reacting nodes in your proposal. Here again I would have  the additional question OCS eventually per client    

            
 

            
 

            
Best regards 

            
 

            
JJacques 

            
 

            
-----Message d'origine-----

            
De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 25 mars 2014 09:24 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: issue #56 proposed conclusion

            
 

            
Hi JJacques

            
 

            
Your concern is related to issue #35. For #35 we almost reached the conclusion not to address client specific throttling in the 02-draft.

            
 

            
The latest proposal to solve #35 was to let clients indicate in OC-Supported-Features that they are clients; agents taking the role of reacting nodes on behalf of clients would not indicate  so. Servers must not request client specific throtting from reacting nodes that did not indicate that they are clients.

            
With this (partial) solution of #35 there would not be any impact to my proposal for #56.

            
 

            
Best regards

            
Ulrich

            
 

            
 

            
 

            
-----Original Message-----

            
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES)

            
Sent: Monday, March 24, 2014 7:43 PM

            
To: dime@ietf.org

            
Subject: Re: [Dime] issue #56 proposed conclusion

            
 

            
Hi Ulrich and all

            
 

            
Still to complement my remark about question of the mitigation for a given client 

            
 

            
Your description of state is defined per Application and Abatement, so not including the mitigation case of a state for a client (cf my previous mail)

            
 

            
I al trying to se how it would apply to another abatement algorithm. There is the rate control algorithm that we will study, and here I am questioning if we will not be driven to have a state per client, as the requested rate will be rather specific to a client, some clients may have a small traffic  and others a large traffic, meaning to define a requested rate per client somewhere. 

            
 

            
So I may again repeat myself that the normal state would be per client in general, which does not exclude to group all clients and consider a state common to all clients when relevant.

            
 

            
This may require some more thinking, but I prefer to remind this point, but it also concern other tickets.

            
 

            
Best regards 

            
 

            
JJacques   

            
 

            
 

            
-----Message d'origine-----

            
De : DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Envoyé : lundi 24 mars 2014 19:08 À : dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

            
 

            
Hi Ulrich

            
 

            
In 5.5.1.2 you wrote:

            
  A reporting node maintains per supported Diameter application and per

            
    supported (and eventually selected) Abatement Algorithm an Overload

            
    Control State

            
 

            
but for another ticket, there is the conclusion that reporting node selects one algorithm,  so your wording would become

            
 

            
     ...per supported Diameter application and for the

            
    selected Abatement Algorithm.... 

            
 

            
 

            
I have also the question of the mitigation for a given  client which may drives the reporting node to consider a state for a client 

            
 

            
Interest of this text is that it clarifies the node behaviors.

            
 

            
Best regards

            
 

            
JJacques  

            
 

            
 

            
-----Message d'origine-----

            
De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion

            
 

            
Dear all,

            
 

            
I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System".

            
 

            
I'm fine with not abbreviating "Overload Control State".

            
 

            
I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow.

            
 

            
Ulrich

            
 

            
-----Original Message-----

            
From: Wiehe, Ulrich (NSN - DE/Munich)

            
Sent: Thursday, March 20, 2014 2:08 PM

            
To: dime@ietf.org

            
Subject: issue #56 proposed conclusion

            
 

            
#56: Bad Description of Overload Control State

            
 

            
 

            
Dear all,

            
 

            
I have received comments from Steve, MCruz and Jouni.

            
 

            
I believe all comments are covered by the following proposed text:

            
 

            
 

            
 

            
    5.5.1.  Overload Control State (OCS)

            
 

            
    5.5.1.1   Overload Control States for reacting nodes

            
 

            
    A reacting node 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 towards

            
      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 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

            
    following information:

            
    - Sequence number (as reveived in OC-OLR)

            
    - Time of expiry  (deviated from validity duration as received in OC-OLR

            
      and time of reception)

            
    - Selected Abatement Algorithm (as received in OC-Supported-Features)

            
    - Algorithm specific input data (as received within OC-OLR, e.g.

            
      Reduction Percentage for Loss)

            
 

            
   

            
    5.5.1.2   Overload Control States for reporting nodes

            
 

            
    A reporting node maintains per supported Diameter application and per

            
    supported (and eventually selected) Abatement Algorithm an Overload

            
    Control State. 

            
 

            
    An Overload Control State may be identified by the pair of Application-Id

            
    and supported Abatement Algorithm.

            
 

            
    The Overload Control State for a given pair of Application and Abatement

            
    Algorithm could include the information:

            
    - Sequence number

            
    - Validity Duration and Expiry Time

            
    - Algorithm specific input data (e.g. Reduction Percentage for Loss)

            
 

            
    

            
    5.5.1.3  Maintaining Overload Control States

            
 

            
    Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving

            
    an answer message of application app-id containing an Orig-Host of host-id and a

            
    host-type OC-OLR AVP unless such host-type OCS already exists.

            
 

            
    Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving

            
    an answer message of application app-id containing an Orig-Realm of realm-id and a

            
    realm-type OC-OLR AVP unless such realm type OCS already exists.

            
 

            
    Reacting nodes delete an OCS when it expires (i.e. when current time

            
    minus reception time is greater than validity duration).

            
 

            
    Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when

            
    receiving an answer message of application app-id containing an Orig-Host of

            
    host-id and a host-type OC-OLR AVP with a sequence number higher than the

            
    stored sequence number.

            
 

            
    Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when

            
    receiving an answer message of application app-id containing an Orig-Realm of

            
    realm-id and a realm-type OC-OLR AVP with a sequence number higher than the

            
    stored sequence number.

            
 

            
    Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a

            
    request of application app-id containing an OC-Supported-Features AVP

            
    indicating support of the Abatement Algorithm Alg (which the reporting

            
    node selects) while being overloaded, unless such OCS already exists.

            
 

            
    Reporting nodes delete an OCS when it expires.

            
 

            
    Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the

            
    need to modify the requested amount of application app-id traffic reduction.

            
 

            
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

            
 

            
_______________________________________________

            
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


    

    

  


--------------000703090103020203090605--


From nobody Wed Mar 26 06:50: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 01A801A030D for ; Wed, 26 Mar 2014 06:50:41 -0700 (PDT)
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 J24Ln6PfKcrl for ; Wed, 26 Mar 2014 06:50:30 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id E6B691A027F for ; Wed, 26 Mar 2014 06:50:28 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 9550CC076D; Wed, 26 Mar 2014 14:50:26 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 7340D180053; Wed, 26 Mar 2014 14:50:26 +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; Wed, 26 Mar 2014 14:50:26 +0100
From: 
To: "Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPSO3GKav1Yd2xqUyLNClmxsrsL5rzQiOAgAAe3/A=
Date: Wed, 26 Mar 2014 13:50:25 +0000
Message-ID: <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51E2FDPEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.173915
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/x7yS6I3xviXlHHYD8tfDU0CmfxE
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Wed, 26 Mar 2014 13:50:41 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51E2FDPEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E51E2FDPEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi,


 =
;


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.


To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.<=
/p>

Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 =
;


Regards,


 =
;


Lionel


 =
;


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@h=
uawei.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-       &nb=
sp; 
First a not always needed AVP cannot justify why it =
shall be mandatory.




-       &nb=
sp; 
Secondly, in my view, having a not always needed AVP=
 as mandatory cannot be less error prone. On the contrary,
 it would introduce more error cases. RFC 6733 defines a couple of error co=
des e.g. DIAMETER_MISSING_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and may=
be others to deal with the possible error cases. All the handling with this=
 AVP consumes the resource of both
 reporting nodes and reacting nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mail=
to:srdonovan@usdonovans.com]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,=



 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/o:p>




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 =



From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:<=
/pre>

 =



Hi,


 =



How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 =



If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 =



Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?


 =



- Jouni


 =



 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 =



 


Hello all,


 =



I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 =



I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 =



Best regards


/MCruz


 =



-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13<=
/pre>

To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 =



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 =



I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 =



- Jouni


 =



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 =



Hi Mcruz


 =



The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
o:p>


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 =



Best regards


 =



JJacques


 =



 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 


lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



Hi Maria Cruz,


 =



I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?


 =



So instead of:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



You would prefer:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



And I'm fine with this proposal.


 =



Cheers,


 =



Lionel


 =



-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



#54: OC-Report-Type as mandatory AVP


 =



Now in chapter 4.6:


 =



 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 =



This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 =



--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz


  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new


Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 =



Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>


 =



_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 =



_____________________________________________________________=
________


____________________________________________________


 =



Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 =



This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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


 =



 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 




 






_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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.




 




______________________________________________________________________=
___________________________________________________

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_6B7134B31289DC4FAF731D844122B36E51E2FDPEXCVZYM13corpora_--


From nobody Wed Mar 26 07:30: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 093351A00FB for ; Wed, 26 Mar 2014 07:30:43 -0700 (PDT)
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 xmlVWNyON5S1 for ; Wed, 26 Mar 2014 07:30:34 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id DBC951A00E3 for ; Wed, 26 Mar 2014 07:30:34 -0700 (PDT)
Received: from [137.254.4.56] (port=11779 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSoqW-0001gN-Dh; Wed, 26 Mar 2014 07:30:29 -0700
Message-ID: <5332E495.10204@usdonovans.com>
Date: Wed, 26 Mar 2014 09:30:45 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: lionel.morand@orange.com,  Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" ,  "dime@ietf.org" 
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5331B195.9020402@usdonovans.com> <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com> <5332C4C1.9010801@usdonovans.com> <16679_1395839760_5332D310_16679_7554_1_6B7134B31289DC4FAF731D844122B36E51D0A2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <16679_1395839760_5332D310_16679_7554_1_6B7134B31289DC4FAF731D844122B36E51D0A2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Content-Type: multipart/alternative; boundary="------------020005070308070305050704"
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/c62_Y1k1qh-WIh1wtS1MjVdiMGE
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Wed, 26 Mar 2014 14:30:43 -0000

This is a multi-part message in MIME format.
--------------020005070308070305050704
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit

Lionel,

Please see comments inline.

Regards,

Steve

On 3/26/14 8:15 AM, lionel.morand@orange.com wrote:
>
> When determining if a request should be throttled, there are three cases:
>
> - Only a Realm report (based on the definition from the meeting)
> matches the message -- In this case the Realm report MUST be used to
> determine if the message is throttled.
> - Only a Host report matches the message -- In this case the Host
> report MUST be used to determine if the message is throttled.
> - Both a Realm and Host report match the message -- In this case the
> Host report MUST be used to determine if the message is throttled and
> throttling based on the Realm report MUST NOT also be applied to the
> message.
>
> I'm ok at the moment with this wording, but I don't think we've
> thought through the implications of prioritizing Host reports over
> Realm reports when both apply.  As such, this is open to change in a
> future version of the draft.
>
> */[LM] OK/*
>
>
SRD> Just to be 100% clear on the first bullet above.  This, I believe,
is where we have confusion and disagreement on this topic.

My proposal is that the Realm report effects 100% of messages that
contain a Realm AVP that matches the Realm report.

The other definition is that the report effects only messages that match
the Realm in the report AND do not have a Destination-Host AVP. 

These are very different definitions and is why it is important to
define what is meant by Realm reports.
>
> >
>
>       > About renaming "Realm" as "Realm-Routed-Request", no strong
>
>       issue as
>
>       > soon as the principle above are kept.
>
> SRD> If we go with your proposal above then there is no name change
> but rather a change in the definition of Realm report.
>
> */[LM] don't think that the current definition needs to be changed.
> However the behavior of the reacting node should be clarified when
> both Host and Realm report type are applicable to a single message./*
>
>
SRD> See above.  Plus, the -01 draft contains BOTH definitions, so it
needs to be updated.
>
> If we go with Ulrich's proposal then we should change the name from
> Realm to RRR (or some other name yet to be suggested).
>
> If we go with three reports then we also need to change the name of
> the existing Realm report to RRR and redefine Realm to match the above
> logic.
>
> */[LM] let's play with only two for now./*
>
> */ /*
>
> > 
>
>       > The need for realm-based type that would apply to any request
>
>       (even
>
>       > if a "Host" exists for a destination-host in the request) was
>
>      
>
>       > challenged and not retained. Ben was supposed to lock you in
>
>       a room
>
>       > and to convince you that this last report type was not
>
>       needed.
>
> This is NOT my recollection of the decision and is NOT what is
> reflected in the minutes.  This is also NOT what you say above.
>
> Here's the relevant portion of the minutes:
>
> Report types - there was consensus that Host and Realm report types
> needed to be retained. Ben suggested that if a node sent a Realm
> report, it needed to be an absolute authority for the realm. Dave did
> not agree that agents needed to be authoritative and felt that clients
> should be able to make their own decisions on conflicting realm
> reports, which Lionel disagreed with. Maria Cruz agreed with both
> proposals because it would be deployment dependent. Steve said that
> the draft should provide guidance that a sender of the realm report
> should be an authority and that realm reports should not contradict.
> It should provide guidance on what the client should do if does
> receive different realm reports. Ben pointed out that, in the case
> where a realm was sending overload reports, individual servers could
> send Reductions of 0% in their reports to provide more information to
> clients.
>
>
> ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with
> a proposal on whether to remove or to incorporate.
>
> ACTION: Next version of DOIC will keep Host and Realm and leave
> Realm-Routed-Request an open issue.
>
> ACTION: Clarify precedence of the host and realm report types and what
> actions to take when they are received.
>
> */[LM] ok/*
>
>
>
>
> >
>
>       > Lionel
>
>       >
>
>       > Envoyé depuis mon Sony Xperia SP d'Orange
>
>       >
>
>       > Steve Donovan 
>  a écrit :
>
>       >
>
>       > Consensus is obviously a fleeting and temporary thing.
>
>       >
>
>       > Let us make sure that we are precise in our definitions of
>
>       the
>
>       > report types we are discussing.
>
>       >
>
>       > Host report - Applies when the destination-host AVP is
>
>       present in
>
>       > the request. Realm-Routed-Request (RRR) - Applies when there
>
>       is no
>
>       > destination-host AVP in the request. Realm - Applies to 100%
>
>       of
>
>       > requests sent to the realm.
>
>       >
>
>       > These are the definitions used in our discussions in London
>
>       and in
>
>       > various places in our email discussions.
>
>       >
>
>       > Can we please agree to use these definitions going forward so
>
>       we are
>
>       > all talking about the same thing.
>
>       >
>
>       > Regards,
>
>       >
>
>       > Steve
>
>       >
>
>       > On 3/25/14 10:27 AM, lionel.morand@orange.com
>  wrote:
>
>       >>
>
>       >> Hi Maria Cruz, All,
>
>       >>
>
>       >>
>
>       >>
>
>       >> In the previous mail, you wrote:
>
>       >>
>
>       >>
>
>       >>
>
>       >> /That is, we have two reports, host and realm. /
>
>       >>
>
>       >> /Host applies when Destination_host is present, and then
>
>       it takes
>
>       >> precedence over Realm. If both are present, only Host is
>
>       applied./
>
>       >>
>
>       >> /Realm applies when only Destination_realm is present./
>
>       >>
>
>       >>
>
>       >>
>
>       >> And I agree with this statement. But I'm not sure that
>
>       this is the
>
>       >> case discussed by Ulrich.
>
>       >>
>
>       >>
>
>       >>
>
>       >> Whatever the name of the realm report type, is there an
>
>       agreement
>
>       >> on the description given above by Maria Cruz and
>
>       discussed in
>
>       >> London?
>
>       >>
>
>       >>
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >>
>
>       >>
>
>       >> Lionel
>
>       >>
>
>       >>
>
>       >>
>
>       >> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
>
>       Maria
>
>       >> Cruz Bartolome *Envoyé :* mardi 25 mars 2014 16:21 *À :*
>
>       Wiehe,
>
>       >> Ulrich (NSN - DE/Munich); ext Steve Donovan;
>
>       dime@ietf.org  *Objet
>
>       >> :* Re: [Dime] Resolution on action to discuss the need
>
>       for
>
>       >> Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Dear all,
>
>       >>
>
>       >>
>
>       >>
>
>       >> I support option 1 a well
>
>       >>
>
>       >> Cheers
>
>       >>
>
>       >> /MCruz
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>
>       *Wiehe,
>
>       >> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de
>
>       2014 16:15
>
>       >>  *To:* ext Steve Donovan; dime@ietf.org
>  *Subject:* Re:
>
>       [Dime]
>
>       >> Resolution on action to discuss the need for
>
>       Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >> Thank you for this summary.
>
>       >>
>
>       >> Please see inline.
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*ext Steve Donovan
>
>       [mailto:srdonovan@usdonovans.com] *Sent:*
>
>       >> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN
>
>       -
>
>       >> DE/Munich); dime@ietf.org 
>  
>
>       *Subject:* Re:
>
>       >> [Dime] Resolution on action to discuss the need for
>
>       >> Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich,
>
>       >>
>
>       >> I mean going backwards from where I thought we were after
>
>       the
>
>       >> London meeting.
>
>       >>
>
>       >> We are clearly out of sync but hopefully we can fix that.
>
>       >>
>
>       >> Here's my understanding of the status of #23 and #55.
>
>       >>
>
>       >> Prior to London meeting:
>
>       >>
>
>       >> #23 status: - Agreement to change the name of existing
>
>       realm
>
>       >> reports to realm-routed-reports (RRR).
>
>       >>
>
>       >> this includes agreement to keep the (newly
>
>       called)
>
>       >> realm-routed-reports - Discussions were
>
>       ongoing as to the
>
>       >> need for both realm reports and RRR reports.
>
>       >>
>
>       >> I would say "...as to the need for realm
>
>       reports in addition
>
>       >> to realm-routed-reports" 
>
>       >>
>
>       >>
>
>       >>
>
>       >> #55 status: - Agreement on adding Realm reports based on
>
>       the
>
>       >> definition that realm reports apply to all traffic sent
>
>       to the
>
>       >> realm.
>
>       >>
>
>       >> This is what I'm missing. The issue has
>
>       been very briefly
>
>       >> discussed under #34 without conclusion. There was no
>
>       discussion
>
>       >> under #55
>
>       >>
>
>       >>
>
>       >> - Limited discussion on the interaction between the new
>
>       realm
>
>       >> reports and the existing host and RRR reports.
>
>       >>
>
>       >> After London meeting:
>
>       >>
>
>       >> #23 status: - Tentative agreement in London meeting to
>
>       remove RRR
>
>       >> reports.
>
>       >>
>
>       >> What was the technical
>
>       argument?
>
>       >>
>
>       >>
>
>       >> - Ben expressed the strongest concern with this plan. 
>
>       Steve and
>
>       >> Ben took action to discuss and come back with a
>
>       recommendation.
>
>       >>
>
>       >> #55 status: - No change
>
>       >>
>
>       >> Summary: - Tentative consensus reached to move forward
>
>       with two
>
>       >> report types - host and realm, with realm having the new
>
>      
>
>       >> definition. What was the technical
>
>       argument?
>
>       >>
>
>       >>
>
>       >> Current status:
>
>       >>
>
>       >> #23 status: - Change the name to RRR - Whether or not to
>
>       remove
>
>       >> RRR and revisit later or keep RRR and revisit later is an
>
>       open
>
>       >> issue.
>
>       >>
>
>       >> #55 status: - My opinion is that we have at least rough
>
>       consensus
>
>       >> on the need to support realm reports.  Others might have
>
>       a
>
>       >> different opinion.
>
>       >>
>
>       >>  There was no comment posted to issue #55,
>
>       also no
>
>       >> proposed solution, so I cannot see where the consensus
>
>       came
>
>       >> from
>
>       >>
>
>       >>
>
>       >>
>
>       >> Summary: - I believe we have three options:
>
>       >>
>
>       >> 1) Support host and RRR reports 2) Support host and Realm
>
>       reports
>
>       >> -- This was the tentative plan coming out of the London
>
>       meeting
>
>       >>
>
>       >> < Ulrich> There is not even an issue number
>
>       identifying problems
>
>       >> with RRR and proposing to remove RRR
>
>       >>
>
>       >>
>
>       >> 3) Support host, RRR and Realm reports
>
>       >>
>
>       >>  I support option 1
>
>       >>
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >> I don't think we are going backwards (we may be out of
>
>       synch
>
>       >> though)
>
>       >>
>
>       >>
>
>       >>
>
>       >> Can you please summarize the status of #23 and #55.
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*ext Steve Donovan
>
>       [mailto:srdonovan@usdonovans.com] *Sent:*
>
>       >> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -
>
>      
>
>       >> DE/Munich); dime@ietf.org 
>  
>
>       *Subject:* Re:
>
>       >> [Dime] Resolution on action to discuss the need for
>
>       >> Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ok, we are going backwards on this one.
>
>       >>
>
>       >> I did not include option three because we had moved past
>
>       that
>
>       >> option in our discussions, both on the list (I thought),
>
>       and in
>
>       >> the meeting.
>
>       >>
>
>       >> I believe that we had come to rough consensus on the need
>
>       for a
>
>       >> realm report and the only remaining issue was whether we
>
>       also
>
>       >> included the RRR report type.
>
>       >>
>
>       >> At this point, the only option is to leave all of the
>
>       issues
>
>       >> related to the report types open and attempt to resolve
>
>       them in
>
>       >> the -03 draft.
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >>
>
>       >>
>
>       >> I do not agree.
>
>       >>
>
>       >>
>
>       >>
>
>       >> We should still have the option
>
>       >>
>
>       >> 3) support report type 0 (this is called host report) and
>
>       support
>
>       >> of report type 1 (this has been called relam report but
>
>       people
>
>       >> argued it should better be called realm routed request
>
>       report).
>
>       >>
>
>       >>
>
>       >>
>
>       >> Whether or not we need in addition to type 0 and type 1
>
>       (or as a
>
>       >> replacement of type 1) a
>
>       >> realm-no-matter-whether-destination-host-is
>
>       present-or-not report
>
>       >> is an open issue (see #55).
>
>       >>
>
>       >> There are a lot of open questions  with regard to #55 and
>
>       I have
>
>       >> not seen a conclusion.
>
>       >>
>
>       >> Where I have seen a conclusion is issue #34 and that is
>
>       inline
>
>       >> with option 3).
>
>       >>
>
>       >>
>
>       >>
>
>       >> Unless we conclude on #55, or decide to re-open #34,
>
>       option 3) is
>
>       >> what should go in the -02 draft.
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>
>       *ext
>
>       >> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM
>
>       *To:*
>
>       >> dime@ietf.org  
>  *Subject:* Re:
>
>       [Dime]
>
>       >> Resolution on action to discuss the need for
>
>       Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich, All,
>
>       >>
>
>       >> We have two options for the -02 draft.
>
>      >>
>
>       >> 1) Support Host and Realm as proposed below, removing RRR
>
>       reports.
>
>       >>  2) Support Host, Realm and RRR reports.
>
>       >>
>
>       >> The default plan is to go with option 1 in the -02 draft,
>
>       as that
>
>       >> was the proposal that came out of the meeting in London. 
>
>       RRR
>
>       >> reports can be added back in if and when we are convinced
>
>       of the
>
>       >> need.
>
>       >>
>
>       >> If there are strong objections to this then I will update
>
>       the -02
>
>       >> draft to reflect all three report types.
>
>       >>
>
>       >> I plan to make these updates Wednesday morning, Dallas,
>
>       Texas
>
>       >> time.
>
>       >>
>
>       >> Either way I do not expect we will have agreed to wording
>
>       on the
>
>       >> interaction between the report types when a reacting node
>
>       has
>
>       >> multiple report types, all of which apply to individual
>
>       requests.
>
>       >> This will need to be addressed in the -03 draft.
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/21/14 4:05 PM, Steve Donovan wrote:
>
>       >>
>
>       >> Ulrich,
>
>       >>
>
>       >> The discussion should be captured in the minutes to the
>
>       meeting.
>
>       >> I wasn't able to find them posted yet.
>
>       >>
>
>       >> Jouni, Lionel, what is the status of the minutes for the
>
>       meeting?
>
>       >>
>
>       >> My reading of emails prior to the London meeting is
>
>       different from
>
>       >> yours.  I believe we had come to the conclusion that we
>
>       needed
>
>       >> host and realm (with the definition of realm as outlined
>
>       below).
>
>       >> We were still discussing the need for
>
>       Realm-Routed-Request
>
>       >> reports.
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
>
>       wrote:
>
>       >>
>
>       >> Steve,
>
>       >>
>
>       >>
>
>       >>
>
>       >> I don't know what happend in London.
>
>       >>
>
>       >> Can you please summarize the technical reasons that led
>
>       to the
>
>       >> London agreement.
>
>       >>
>
>       >> E-mail discussions prior to London have clearly directed
>
>       towards a
>
>       >> report type that requests throttling of realm routed
>
>       request
>
>       >> messages (i.e. not containing a destination host) rather
>
>       than a
>
>       >> report type that requests throttling of messages routed
>
>       towards a
>
>       >> realm (no matter whether they contain a destination host
>
>       or not).
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> Ulrich
>
>       >>
>
>       >>
>
>       >>
>
>       >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
>
>       *ext
>
>       >> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM
>
>       *To:*
>
>       >> dime@ietf.org  
>  *Subject:*
>
>       [Dime] Resolution
>
>       >> on action to discuss the need for Realm-Routed-Reports
>
>       >>
>
>       >>
>
>       >>
>
>       >> All,
>
>       >>
>
>       >> Ben and I took the action item to discuss the need for
>
>       the
>
>       >> Realm-Routed-Reports (RRR) report type.
>
>       >>
>
>       >> As you may recall, the consensus coming out of the DIME
>
>       WG meeting
>
>       >> in London was to support two report types:
>
>       >>
>
>       >> - Host -- Impacting requests with a Destination-Host AVP
>
>       matching
>
>       >> the host in the overload report (with the host implicitly
>
>      
>
>       >> determined from the Origin-Host AVP of the answer message
>
>       carrying
>
>       >> the overload report).
>
>       >>
>
>       >> - Realm -- Impacting 100% of the requests with a
>
>       Destination-Realm
>
>       >> AVP matching the realm in the overload report (with the
>
>       realm
>
>       >> implicitly determine from the Origin-Realm of the answer
>
>       message
>
>       >> carrying the overload report).
>
>       >>
>
>       >> The action Ben and I took was to come back with an
>
>       opinion on
>
>       >> whether RRR reports should also be supported.
>
>       >>
>
>       >> My summary of the discussion is that we recommend to NOT
>
>       include
>
>       >> RRR reports in the current version of the base DOIC
>
>       draft.
>
>       >>
>
>       >> We still have some concerns with the granularity of
>
>       control
>
>       >> enabled by having just the two report types but the
>
>       analysis of
>
>       >> whether RRR reports are still needed can occur
>
>       independent of the
>
>       >> base DOIC draft.  If there is a determination that RRRs
>
>       are needed
>
>       >> in time to include in the base draft then it can be
>
>       considered at
>
>       >> that time.
>
>       >>
>
>       >> Based on this, I propose the following
>
>       >>
>
>       >> - Resolution to issue #23 is to remove RRR reports from
>
>       the
>
>       >> document. - Resolution to issue #55 is to add Realm
>
>       reports
>
>       >> (actually to redefine them per the above definition). -
>
>       Resolution
>
>       >> to issue #57 is that it no longer applies (as it deals
>
>       with RRRs).
>
>       >>
>
>       >> There is also need for text describing the interaction
>
>       between
>
>       >> host and the realm reports.  I don't expect we will have
>
>       consensus
>
>       >> on this wording prior to the -02 draft being submitted. 
>
>       To this
>
>       >> end, I'll open a new issue to deal with the need for
>
>       wording on
>
>       >> the interaction.
>
>       >>
>
>       >> Regards,
>
>       >>
>
>       >> Steve
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >>
>
>       >> _______________________________________________
>
>       >>
>
>       >> 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.
>
> _________________________________________________________________________________________________________________________
>
> 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.


--------------020005070308070305050704
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Lionel,

      

      Please see comments inline.

      

      Regards,

      

      Steve

      

    
    
On 3/26/14 8:15 AM,
      lionel.morand@orange.com wrote:

    

    

      
      
      
      

        
When determining if a
            request should be throttled, there are three cases:

            

            - Only a Realm report (based on the definition from the
            meeting) matches the message -- In this case the Realm
            report MUST be used to determine if the message is
            throttled.

            - Only a Host report matches the message -- In this case the
            Host report MUST be used to determine if the message is
            throttled.

            - Both a Realm and Host report match the message -- In this
            case the Host report MUST be used to determine if the
            message is throttled and throttling based on the Realm
            report MUST NOT also be applied to the message.

            

          I'm ok at the moment with this wording, but I don't
          think we've thought through the implications of prioritizing
          Host reports over Realm reports when both apply.  As such,
          this is open to change in a future version of the draft.

          

          

        
[LM]
                OK

        


        

      

    

    SRD> Just to be 100% clear on the first bullet above.  This, I
    believe, is where we have confusion and disagreement on this topic.

    

    My proposal is that the Realm report effects 100% of messages that
    contain a Realm AVP that matches the Realm report.

    

    The other definition is that the report effects only messages that
    match the Realm in the report AND do not have a Destination-Host
    AVP.  

    

    These are very different definitions and is why it is important to
    define what is meant by Realm reports.

    

      

        

          > 

          

          

        
      > About renaming "Realm" as
          "Realm-Routed-Request", no strong

        
      issue as 

          

          

        
      > soon as the principle above are
          kept.

          

          SRD> If we go with your proposal above then there is no
          name change but rather a change in the definition of Realm
          report.

          

          

        
[LM] don't think that the current
                definition needs to be changed. However the behavior of
                the reacting node should be clarified when both Host and
                Realm report type are applicable to a single message.

        


          

      

    

    SRD> See above.  Plus, the -01 draft contains BOTH definitions,
    so it needs to be updated.

    

      

        

            If we go with Ulrich's proposal then we should change the
            name from Realm to RRR (or some other name yet to be
            suggested).

            

            If we go with three reports then we also need to change the
            name of the existing Realm report to RRR and redefine Realm
            to match the above logic.

            

          

        
[LM] let's play with only two for now.

        
 

        
> 

            

            

        
      > The
          need for realm-based type that would apply to any request

        
      (even 

          

          

        
      > if a "Host" exists for a
          destination-host in the request) was

        
      

          

          

        
      > challenged and not retained. Ben
          was supposed to lock you in

        
      a room 

          

          

        
      > and to convince you that this
          last report type was not

        
      needed.

          

          This is NOT my recollection of the decision and is NOT what is
          reflected in the minutes.  This is also NOT what you say
          above.
          

          

          Here's the relevant portion of the minutes:

          

          Report types - there was consensus that Host and Realm report
          types needed to be retained. Ben suggested that if a node sent
          a Realm report, it needed to be an absolute authority for the
          realm. Dave did not agree that agents needed to be
          authoritative and felt that clients should be able to make
          their own decisions on conflicting realm reports, which Lionel
          disagreed with. Maria Cruz agreed with both proposals because
          it would be deployment dependent. Steve said that the draft
          should provide guidance that a sender of the realm report
          should be an authority and that realm reports should not
          contradict. It should provide guidance on what the client
          should do if does receive different realm reports. Ben pointed
          out that, in the case where a realm was sending overload
          reports, individual servers could send Reductions of 0% in
          their reports to provide more information to clients.
          

          

          

          ACTION: Ben and Steve to discuss Realm-Routed-Request and come
          up with a proposal on whether to remove or to incorporate.
          

          

          ACTION: Next version of DOIC will keep Host and Realm and
          leave Realm-Routed-Request an open issue.
          

          

          ACTION: Clarify precedence of the host and realm report types
          and what actions to take when they are received.
          

          

          

        
[LM]
                ok

        


          

          

          > 

          

          

        
      > Lionel

          

          

        
      > 

          

          

        
      > Envoyé depuis mon Sony Xperia SP
          d'Orange

          

          

        
      > 

          

          

        
      > Steve Donovan 
            <srdonovan@usdonovans.com> a écrit :

          

          

        
      > 

          

          

        
      > Consensus is obviously a
          fleeting and temporary thing.

          

          

        
      > 

          

          

        
      > Let us make sure that we are
          precise in our definitions of

        
      the

          

          

        
      > report types we are discussing.

          

          

        
      > 

          

          

        
      > Host report - Applies when the
          destination-host AVP is

        
      present in

          

          

        
      > the request.
          Realm-Routed-Request (RRR) - Applies when there

        
      is no 

          

          

        
      > destination-host AVP in the
          request. Realm - Applies to 100%

        
      of 

          

          

        
      > requests sent to the realm.

          

          

        
      > 

          

          

        
      > These are the definitions used
          in our discussions in London

        
      and in 

          

          

        
      > various places in our email
          discussions.

          

          

        
      > 

          

          

        
      > Can we please agree to use these
          definitions going forward so

        
      we are 

          

          

        
      > all talking about the same
          thing.

          

          

        
      > 

          

          

        
      > Regards,

          

          

        
      > 

          

          

        
      > Steve

          

          

        
      > 

          

          

        
      > On 3/25/14 10:27 AM, 
            lionel.morand@orange.com wrote:

          

          

        
      >> 

          

          

        
      >> Hi Maria Cruz, All,

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> In the previous mail, you
          wrote:

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> /That is, we have two
          reports, host and realm. /

          

          

        
      >> 

          

          

        
      >> /Host applies when
          Destination_host is present, and then

        
      it takes 

          

          

        
      >> precedence over Realm. If
          both are present, only Host is

        
      applied./

          

          

        
      >> 

          

          

        
      >> /Realm applies when only
          Destination_realm is present./

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> And I agree with this
          statement. But I'm not sure that

        
      this is the 

          

          

        
      >> case discussed by Ulrich.

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Whatever the name of the
          realm report type, is there an

        
      agreement 

          

          

        
      >> on the description given
          above by Maria Cruz and

        
      discussed in 

          

          

        
      >> London?

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Regards,

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Lionel

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> *De :*DiME [mailto:dime-bounces@ietf.org]
          *De la part de*

        
      Maria 

          

          

        
      >> Cruz Bartolome *Envoyé :*
          mardi 25 mars 2014 16:21 *À :*

        
      Wiehe, 

          

          

        
      >> Ulrich (NSN - DE/Munich);
          ext Steve Donovan;

        
      dime@ietf.org *Objet
          

          

          

        
      >> :* Re: [Dime] Resolution on
          action to discuss the need

        
      for 

          

          

        
      >> Realm-Routed-Reports

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Dear all,

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> I support option 1 a well

          

          

        
      >> 

          

          

        
      >> Cheers

          

          

        
      >> 

          

          

        
      >> /MCruz

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> *From:*DiME [mailto:dime-bounces@ietf.org]
          *On Behalf Of

        
      *Wiehe, 

          

          

        
      >> Ulrich (NSN - DE/Munich)
          *Sent:* martes, 25 de marzo de

        
      2014 16:15

          

          

        
      >>  *To:* ext Steve Donovan; 
            dime@ietf.org *Subject:* Re:

        
      [Dime] 

          

          

        
      >> Resolution on action to
          discuss the need for

        
      Realm-Routed-Reports

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Steve,

          

          

        
      >> 

          

          

        
      >> Thank you for this summary.

          

          

        
      >> 

          

          

        
      >> Please see inline.

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Ulrich

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> *From:*ext Steve Donovan

        
      [mailto:srdonovan@usdonovans.com]
          *Sent:*
          

          

          

        
      >> Tuesday, March 25, 2014 2:49
          PM *To:* Wiehe, Ulrich (NSN

        
      - 

          

          

        
      >> DE/Munich); dime@ietf.org
          <mailto:dime@ietf.org>

        
      *Subject:* Re: 

          

          

        
      >> [Dime] Resolution on action
          to discuss the need for
          

          

          

        
      >> Realm-Routed-Reports

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Ulrich,

          

          

        
      >> 

          

          

        
      >> I mean going backwards from
          where I thought we were after

        
      the 

          

          

        
      >> London meeting.

          

          

        
      >> 

          

          

        
      >> We are clearly out of sync
          but hopefully we can fix that.

          

          

        
      >> 

          

          

        
      >> Here's my understanding of
          the status of #23 and #55.

          

          

        
      >> 

          

          

        
      >> Prior to London meeting:

          

          

        
      >> 

          

          

        
      >> #23 status: - Agreement to
          change the name of existing

        
      realm 

          

          

        
      >> reports to
          realm-routed-reports (RRR).

          

          

        
      >> 

          

          

        
      >> <Ulrich>this includes
          agreement to keep the (newly

        
      called) 

          

          

        
      >>
          realm-routed-reports</Ulrich> - Discussions were

        
      ongoing as to the 

          

          

        
      >> need for both realm reports
          and RRR reports.

          

          

        
      >> 

          

          

        
      >> <Ulrich>I would say
          “…as to the need for realm

        
      reports in addition 

          

          

        
      >> to realm-routed-reports”
          </Ulrich>

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> #55 status: - Agreement on
          adding Realm reports based on

        
      the 

          

          

        
      >> definition that realm
          reports apply to all traffic sent

        
      to the 

          

          

        
      >> realm.

          

          

        
      >> 

          

          

        
      >> <Ulrich>This is what
          I’m missing. The issue has

        
      been very briefly 

          

          

        
      >> discussed under #34 without
          conclusion. There was no

        
      discussion 

          

          

        
      >> under #55</Ulrich>

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> - Limited discussion on the
          interaction between the new

        
      realm 

          

          

        
      >> reports and the existing
          host and RRR reports.

          

          

        
      >> 

          

          

        
      >> After London meeting:

          

          

        
      >> 

          

          

        
      >> #23 status: - Tentative
          agreement in London meeting to

        
      remove RRR 

          

          

        
      >> reports.

          

          

        
      >> 

          

          

        
      >> <Ulrich>What was the
          technical

        
      argument?</Ulrich>

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> - Ben expressed the
          strongest concern with this plan. 

        
      Steve and 

          

          

        
      >> Ben took action to discuss
          and come back with a

        
      recommendation.

          

          

        
      >> 

          

          

        
      >> #55 status: - No change

          

          

        
      >> 

          

          

        
      >> Summary: - Tentative
          consensus reached to move forward

        
      with two 

          

          

        
      >> report types - host and
          realm, with realm having the new

        
      

          

          

        
      >> definition.
          <Ulrich>What was the technical

        
      argument?</Ulrich>

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Current status:

          

          

        
      >> 

          

          

        
      >> #23 status: - Change the
          name to RRR - Whether or not to

        
      remove

          

          

        
      >> RRR and revisit later or
          keep RRR and revisit later is an

        
      open

          

          

        
      >> issue.

          

          

        
      >> 

          

          

        
      >> #55 status: - My opinion is
          that we have at least rough

        
      consensus 

          

          

        
      >> on the need to support realm
          reports.  Others might have

        
      a 

          

          

        
      >> different opinion.

          

          

        
      >> 

          

          

        
      >> <Ulrich> There was no
          comment posted to issue #55,

        
      also no

          

          

        
      >> proposed solution, so I
          cannot see where the consensus

        
      came

          

          

        
      >> from</Ulrich>

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Summary: - I believe we have
          three options:

          

          

        
      >> 

          

          

        
      >> 1) Support host and RRR
          reports 2) Support host and Realm

        
      reports 

          

          

        
      >> -- This was the tentative
          plan coming out of the London

        
      meeting

          

          

        
      >> 

          

          

        
      >> < Ulrich> There is not
          even an issue number

        
      identifying problems 

          

          

        
      >> with RRR and proposing to
          remove RRR</Ulrich>

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 3) Support host, RRR and
          Realm reports

          

          

        
      >> 

          

          

        
      >> <Ulrich> I support
          option 1</Ulrich>

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Regards,

          

          

        
      >> 

          

          

        
      >> Steve

          

          

        
      >> 

          

          

        
      >> On 3/25/14 6:44 AM, Wiehe,
          Ulrich (NSN - DE/Munich)

        
      wrote:

          

          

        
      >> 

          

          

        
      >> Steve,

          

          

        
      >> 

          

          

        
      >> I don’t think we are going
          backwards (we may be out of

        
      synch 

          

          

        
      >> though)

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Can you please summarize the
          status of #23 and #55.

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Ulrich

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> *From:*ext Steve Donovan

        
      [mailto:srdonovan@usdonovans.com]
          *Sent:*
          

          

          

        
      >> Monday, March 24, 2014 7:38
          PM *To:* Wiehe, Ulrich (NSN -

        
      

          

          

        
      >> DE/Munich); dime@ietf.org
          <mailto:dime@ietf.org>

        
      *Subject:* Re: 

          

          

        
      >> [Dime] Resolution on action
          to discuss the need for
          

          

          

        
      >> Realm-Routed-Reports

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Ok, we are going backwards
          on this one.

          

          

        
      >> 

          

          

        
      >> I did not include option
          three because we had moved past

        
      that 

          

          

        
      >> option in our discussions,
          both on the list (I thought),

        
      and in

          

          

        
      >> the meeting.

          

          

        
      >> 

          

          

        
      >> I believe that we had come
          to rough consensus on the need

        
      for a 

          

          

        
      >> realm report and the only
          remaining issue was whether we

        
      also 

          

          

        
      >> included the RRR report
          type.

          

          

        
      >> 

          

          

        
      >> At this point, the only
          option is to leave all of the

        
      issues 

          

          

        
      >> related to the report types
          open and attempt to resolve

        
      them in

          

          

        
      >> the -03 draft.

          

          

        
      >> 

          

          

        
      >> Steve

          

          

        
      >> 

          

          

        
      >> On 3/24/14 11:13 AM, Wiehe,
          Ulrich (NSN - DE/Munich)

        
      wrote:

          

          

        
      >> 

          

          

        
      >> Steve,

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> I do not agree.

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> We should still have the
          option

          

          

        
      >> 

          

          

        
      >> 3) support report type 0
          (this is called host report) and

        
      support 

          

          

        
      >> of report type 1 (this has
          been called relam report but

        
      people 

          

          

        
      >> argued it should better be
          called realm routed request

        
      report).

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Whether or not we need in
          addition to type 0 and type 1

        
      (or as a 

          

          

        
      >> replacement of type 1) a 

          

          

        
      >>
          realm-no-matter-whether-destination-host-is

        
      present-or-not report 

          

          

        
      >> is an open issue (see #55).

          

          

        
      >> 

          

          

        
      >> There are a lot of open
          questions  with regard to #55 and

        
      I have 

          

          

        
      >> not seen a conclusion.

          

          

        
      >> 

          

          

        
      >> Where I have seen a
          conclusion is issue #34 and that is

        
      inline

          

          

        
      >> with option 3).

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Unless we conclude on #55,
          or decide to re-open #34,

        
      option 3) is 

          

          

        
      >> what should go in the -02
          draft.

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Ulrich

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> *From:*DiME [mailto:dime-bounces@ietf.org]
          *On Behalf Of

        
      *ext

          

          

        
      >> Steve Donovan *Sent:*
          Monday, March 24, 2014 2:57 PM

        
      *To:*

          

          

        
      >> dime@ietf.org 
            <mailto:dime@ietf.org> *Subject:* Re:

        
      [Dime]

          

          

        
      >> Resolution on action to
          discuss the need for

        
      Realm-Routed-Reports

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Ulrich, All,

          

          

        
      >> 

          

          

        
      >> We have two options for the
          -02 draft.

          

          

        
     >> 

          

          

        
      >> 1) Support Host and Realm as
          proposed below, removing RRR

        
      reports.

          

          

        
      >>  2) Support Host, Realm and
          RRR reports.

          

          

        
      >> 

          

          

        
      >> The default plan is to go
          with option 1 in the -02 draft,

        
      as that 

          

          

        
      >> was the proposal that came
          out of the meeting in London. 

        
      RRR 

          

          

        
      >> reports can be added back in
          if and when we are convinced

        
      of the 

          

          

        
      >> need.

          

          

        
      >> 

          

          

        
      >> If there are strong
          objections to this then I will update

        
      the -02 

          

          

        
      >> draft to reflect all three
          report types.

          

          

        
      >> 

          

          

        
      >> I plan to make these updates
          Wednesday morning, Dallas,

        
      Texas 

          

          

        
      >> time.

          

          

        
      >> 

          

          

        
      >> Either way I do not expect
          we will have agreed to wording

        
      on the 

          

          

        
      >> interaction between the
          report types when a reacting node

        
      has 

          

          

        
      >> multiple report types, all
          of which apply to individual

        
      requests. 

          

          

        
      >> This will need to be
          addressed in the -03 draft.

          

          

        
      >> 

          

          

        
      >> Regards,

          

          

        
      >> 

          

          

        
      >> Steve

          

          

        
      >> 

          

          

        
      >> On 3/21/14 4:05 PM, Steve
          Donovan wrote:

          

          

        
      >> 

          

          

        
      >> Ulrich,

          

          

        
      >> 

          

          

        
      >> The discussion should be
          captured in the minutes to the

        
      meeting.

          

          

        
      >> I wasn't able to find them
          posted yet.

          

          

        
      >> 

          

          

        
      >> Jouni, Lionel, what is the
          status of the minutes for the

        
      meeting?

          

          

        
      >> 

          

          

        
      >> My reading of emails prior
          to the London meeting is

        
      different from 

          

          

        
      >> yours.  I believe we had
          come to the conclusion that we

        
      needed

          

          

        
      >> host and realm (with the
          definition of realm as outlined

        
      below).

          

          

        
      >> We were still discussing the
          need for

        
      Realm-Routed-Request

          

          

        
      >> reports.

          

          

        
      >> 

          

          

        
      >> Regards,

          

          

        
      >> 

          

          

        
      >> Steve

          

          

        
      >> 

          

          

        
      >> On 3/21/14 10:09 AM, Wiehe,
          Ulrich (NSN - DE/Munich)

        
      wrote:

          

          

        
      >> 

          

          

        
      >> Steve,

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> I don’t know what happend in
          London.

          

          

        
      >> 

          

          

        
      >> Can you please summarize the
          technical reasons that led

        
      to the 

          

          

        
      >> London agreement.

          

          

        
      >> 

          

          

        
      >> E-mail discussions prior to
          London have clearly directed

        
      towards a 

          

          

        
      >> report type that requests
          throttling of realm routed

        
      request 

          

          

        
      >> messages (i.e. not
          containing a destination host) rather

        
      than a 

          

          

        
      >> report type that requests
          throttling of messages routed

        
      towards a 

          

          

        
      >> realm (no matter whether
          they contain a destination host

        
      or not).

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> Ulrich

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> *From:*DiME [mailto:dime-bounces@ietf.org]
          *On Behalf Of

        
      *ext

          

          

        
      >> Steve Donovan *Sent:*
          Friday, March 21, 2014 3:33 PM

        
      *To:*

          

          

        
      >> dime@ietf.org 
            <mailto:dime@ietf.org> *Subject:*

        
      [Dime] Resolution

          

          

        
      >> on action to discuss the
          need for Realm-Routed-Reports

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> All,

          

          

        
      >> 

          

          

        
      >> Ben and I took the action
          item to discuss the need for

        
      the 

          

          

        
      >> Realm-Routed-Reports (RRR)
          report type.

          

          

        
      >> 

          

          

        
      >> As you may recall, the
          consensus coming out of the DIME

        
      WG meeting 

          

          

        
      >> in London was to support two
          report types:

          

          

        
      >> 

          

          

        
      >> - Host -- Impacting requests
          with a Destination-Host AVP

        
      matching 

          

          

        
      >> the host in the overload
          report (with the host implicitly

        
      

          

          

        
      >> determined from the
          Origin-Host AVP of the answer message

        
      carrying 

          

          

        
      >> the overload report).

          

          

        
      >> 

          

          

        
      >> - Realm -- Impacting 100% of
          the requests with a

        
      Destination-Realm 

          

          

        
      >> AVP matching the realm in
          the overload report (with the

        
      realm 

          

          

        
      >> implicitly determine from
          the Origin-Realm of the answer

        
      message 

          

          

        
      >> carrying the overload
          report).

          

          

        
      >> 

          

          

        
      >> The action Ben and I took
          was to come back with an

        
      opinion on 

          

          

        
      >> whether RRR reports should
          also be supported.

          

          

        
      >> 

          

          

        
      >> My summary of the discussion
          is that we recommend to NOT

        
      include 

          

          

        
      >> RRR reports in the current
          version of the base DOIC

        
      draft.

          

          

        
      >> 

          

          

        
      >> We still have some concerns
          with the granularity of

        
      control

          

          

        
      >> enabled by having just the
          two report types but the

        
      analysis of

          

          

        
      >> whether RRR reports are
          still needed can occur

        
      independent of the

          

          

        
      >> base DOIC draft.  If there
          is a determination that RRRs

        
      are needed

          

          

        
      >> in time to include in the
          base draft then it can be

        
      considered at

          

          

        
      >> that time.

          

          

        
      >> 

          

          

        
      >> Based on this, I propose the
          following

          

          

        
      >> 

          

          

        
      >> - Resolution to issue #23 is
          to remove RRR reports from

        
      the 

          

          

        
      >> document. - Resolution to
          issue #55 is to add Realm

        
      reports 

          

          

        
      >> (actually to redefine them
          per the above definition). -

        
      Resolution 

          

          

        
      >> to issue #57 is that it no
          longer applies (as it deals

        
      with RRRs).

          

          

        
      >> 

          

          

        
      >> There is also need for text
          describing the interaction

        
      between

          

          

        
      >> host and the realm reports. 
          I don't expect we will have

        
      consensus

          

          

        
      >> on this wording prior to the
          -02 draft being submitted. 

        
      To this

          

          

        
      >> end, I'll open a new issue
          to deal with the need for

        
      wording on

          

          

        
      >> the interaction.

          

          

        
      >> 

          

          

        
      >> Regards,

          

          

        
      >> 

          

          

        
      >> Steve

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >> 

          

          

        
      >>
          _______________________________________________

          

          

        
      >> 

          

          

        
      >> DiME mailing list

          

          

        
      >> 

          

          

        
      >> DiME@ietf.org 
            <mailto: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.

          

          

      

      
_________________________________________________________________________________________________________________________

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.


    

    

  


--------------020005070308070305050704--


From nobody Wed Mar 26 08:21: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 405E81A00FB for ; Wed, 26 Mar 2014 08:21:27 -0700 (PDT)
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 EXzd078hppsQ for ; Wed, 26 Mar 2014 08:21:18 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA711A00E3 for ; Wed, 26 Mar 2014 08:21:16 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DEF4422C654; Wed, 26 Mar 2014 16:21:14 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id BC9724C06C; Wed, 26 Mar 2014 16:21:14 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Wed, 26 Mar 2014 16:21:14 +0100
From: 
To: Steve Donovan , Maria Cruz Bartolome , "Wiehe, Ulrich (NSN - DE/Munich)" , "dime@ietf.org" 
Thread-Topic: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
Thread-Index: AQHPSP/5scXj4P/C40GW6f1v1eWv+5rzenBg
Date: Wed, 26 Mar 2014 15:21:13 +0000
Message-ID: <2473_1395847274_5332F06A_2473_1243_1_6B7134B31289DC4FAF731D844122B36E51E620@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <532C4D98.7040303@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151C98A7@DEMUMBX014.nsn-intra.net> <532CA99F.4070409@usdonovans.com> <53303991.6060307@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D1E15@DEMUMBX014.nsn-intra.net> <53307B7C.4000200@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2197@DEMUMBX014.nsn-intra.net> <5331895D.5050500@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2299@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B92097A0844@ESESSMB101.ericsson.se> <6076_1395761224_5331A048_6076_6681_1_6B7134B31289DC4FAF731D844122B36E51AC99@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <5331B195.9020402@usdonovans.com> <1369_1395815681_53327501_1369_7786_1_anlyh92po3ps3dth8oijm8v1.1395815673766@email.android.com> <5332C4C1.9010801@usdonovans.com> <16679_1395839760_5332D310_16679_7554_1_6B7134B31289DC4FAF731D844122B36E51D0A2@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5332E495.10204@usdonovans.com>
In-Reply-To: <5332E495.10204@usdonovans.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E51E620PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/QcbrsRzpUFBmbufzM0AO1R2mhq8
Subject: Re: [Dime] Resolution on action to discuss the need for Realm-Routed-Reports
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: Wed, 26 Mar 2014 15:21:27 -0000

--_000_6B7134B31289DC4FAF731D844122B36E51E620PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I confirm that we agree:
Realm: for all the messages towards a given relam (with or without destinat=
ion)
Host: for all the messages towards a given diestination-host
Realm + Host: only host apply when the given destination host is in the mes=
sage.

Lionel

De : Steve Donovan [mailto:srdonovan@usdonovans.com]
Envoy=E9 : mercredi 26 mars 2014 15:31
=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; Wiehe, Ulrich (NSN - DE/=
Munich); dime@ietf.org
Objet : Re: [Dime] Resolution on action to discuss the need for Realm-Route=
d-Reports

Lionel,

Please see comments inline.

Regards,

Steve
On 3/26/14 8:15 AM, lionel.morand@orange.com wrote:
When determining if a request should be throttled, there are three cases:

- Only a Realm report (based on the definition from the meeting) matches th=
e message -- In this case the Realm report MUST be used to determine if the=
 message is throttled.
- Only a Host report matches the message -- In this case the Host report MU=
ST be used to determine if the message is throttled.
- Both a Realm and Host report match the message -- In this case the Host r=
eport MUST be used to determine if the message is throttled and throttling =
based on the Realm report MUST NOT also be applied to the message.

I'm ok at the moment with this wording, but I don't think we've thought thr=
ough the implications of prioritizing Host reports over Realm reports when =
both apply.  As such, this is open to change in a future version of the dra=
ft.


[LM] OK

SRD> Just to be 100% clear on the first bullet above.  This, I believe, is =
where we have confusion and disagreement on this topic.

My proposal is that the Realm report effects 100% of messages that contain =
a Realm AVP that matches the Realm report.

The other definition is that the report effects only messages that match th=
e Realm in the report AND do not have a Destination-Host AVP.

These are very different definitions and is why it is important to define w=
hat is meant by Realm reports.

>


      > About renaming "Realm" as "Realm-Routed-Request", no strong
      issue as


      > soon as the principle above are kept.

SRD> If we go with your proposal above then there is no name change but rat=
her a change in the definition of Realm report.


[LM] don't think that the current definition needs to be changed. However t=
he behavior of the reacting node should be clarified when both Host and Rea=
lm report type are applicable to a single message.

SRD> See above.  Plus, the -01 draft contains BOTH definitions, so it needs=
 to be updated.

If we go with Ulrich's proposal then we should change the name from Realm t=
o RRR (or some other name yet to be suggested).

If we go with three reports then we also need to change the name of the exi=
sting Realm report to RRR and redefine Realm to match the above logic.


[LM] let's play with only two for now.

>


      > The need for realm-based type that would apply to any request
      (even


      > if a "Host" exists for a destination-host in the request) was



      > challenged and not retained. Ben was supposed to lock you in
      a room


      > and to convince you that this last report type was not
      needed.

This is NOT my recollection of the decision and is NOT what is reflected in=
 the minutes.  This is also NOT what you say above.

Here's the relevant portion of the minutes:

Report types - there was consensus that Host and Realm report types needed =
to be retained. Ben suggested that if a node sent a Realm report, it needed=
 to be an absolute authority for the realm. Dave did not agree that agents =
needed to be authoritative and felt that clients should be able to make the=
ir own decisions on conflicting realm reports, which Lionel disagreed with.=
 Maria Cruz agreed with both proposals because it would be deployment depen=
dent. Steve said that the draft should provide guidance that a sender of th=
e realm report should be an authority and that realm reports should not con=
tradict. It should provide guidance on what the client should do if does re=
ceive different realm reports. Ben pointed out that, in the case where a re=
alm was sending overload reports, individual servers could send Reductions =
of 0% in their reports to provide more information to clients.


ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a pr=
oposal on whether to remove or to incorporate.

ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Route=
d-Request an open issue.

ACTION: Clarify precedence of the host and realm report types and what acti=
ons to take when they are received.


[LM] ok



>


      > Lionel


      >


      > Envoy=E9 depuis mon Sony Xperia SP d'Orange


      >


      > Steve Donovan  a =E9crit :


      >


      > Consensus is obviously a fleeting and temporary thing.


      >


      > Let us make sure that we are precise in our definitions of
      the


      > report types we are discussing.


      >


      > Host report - Applies when the destination-host AVP is
      present in


      > the request. Realm-Routed-Request (RRR) - Applies when there
      is no


      > destination-host AVP in the request. Realm - Applies to 100%
      of


      > requests sent to the realm.


      >


      > These are the definitions used in our discussions in London
      and in


      > various places in our email discussions.


      >


      > Can we please agree to use these definitions going forward so
      we are


      > all talking about the same thing.


      >


      > Regards,


      >


      > Steve


      >


      > On 3/25/14 10:27 AM, lionel.morand@orange.com wrote:


      >>


      >> Hi Maria Cruz, All,


      >>


      >>


      >>


      >> In the previous mail, you wrote:


      >>


      >>


      >>


      >> /That is, we have two reports, host and realm. /


      >>


      >> /Host applies when Destination_host is present, and then
      it takes


      >> precedence over Realm. If both are present, only Host is
      applied./


      >>


      >> /Realm applies when only Destination_realm is present./


      >>


      >>


      >>


      >> And I agree with this statement. But I'm not sure that
      this is the


      >> case discussed by Ulrich.


      >>


      >>


      >>


      >> Whatever the name of the realm report type, is there an
      agreement


      >> on the description given above by Maria Cruz and
      discussed in


      >> London?


      >>


      >>


      >>


      >> Regards,


      >>


      >>


      >>


      >> Lionel


      >>


      >>


      >>


      >> *De :*DiME [mailto:dime-bounces@ietf.org] *De la part de*
      Maria


      >> Cruz Bartolome *Envoy=E9 :* mardi 25 mars 2014 16:21 *=C0 :*
      Wiehe,


      >> Ulrich (NSN - DE/Munich); ext Steve Donovan;
      dime@ietf.org *Objet


      >> :* Re: [Dime] Resolution on action to discuss the need
      for


      >> Realm-Routed-Reports


      >>


      >>


      >>


      >> Dear all,


      >>


      >>


      >>


      >> I support option 1 a well


      >>


      >> Cheers


      >>


      >> /MCruz


      >>


      >>


      >>


      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *Wiehe,


      >> Ulrich (NSN - DE/Munich) *Sent:* martes, 25 de marzo de
      2014 16:15


      >>  *To:* ext Steve Donovan; dime@ietf.org *Sub=
ject:* Re:
      [Dime]


      >> Resolution on action to discuss the need for
      Realm-Routed-Reports


      >>


      >>


      >>


      >> Steve,


      >>


      >> Thank you for this summary.


      >>


      >> Please see inline.


      >>


      >>


      >>


      >> Ulrich


      >>


      >>


      >>


      >> *From:*ext Steve Donovan
      [mailto:srdonovan@usdonovans.com] *Sent:*


      >> Tuesday, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN
      -


      >> DE/Munich); dime@ietf.org 
      *Subject:* Re:


      >> [Dime] Resolution on action to discuss the need for


      >> Realm-Routed-Reports


      >>


      >>


      >>


      >> Ulrich,


      >>


      >> I mean going backwards from where I thought we were after
      the


      >> London meeting.


      >>


      >> We are clearly out of sync but hopefully we can fix that.


      >>


      >> Here's my understanding of the status of #23 and #55.


      >>


      >> Prior to London meeting:


      >>


      >> #23 status: - Agreement to change the name of existing
      realm


      >> reports to realm-routed-reports (RRR).


      >>


      >> this includes agreement to keep the (newly
      called)


      >> realm-routed-reports - Discussions were
      ongoing as to the


      >> need for both realm reports and RRR reports.


      >>


      >> I would say "...as to the need for realm
      reports in addition


      >> to realm-routed-reports" 


      >>


      >>


      >>


      >> #55 status: - Agreement on adding Realm reports based on
      the


      >> definition that realm reports apply to all traffic sent
      to the


      >> realm.


      >>


      >> This is what I'm missing. The issue has
      been very briefly


      >> discussed under #34 without conclusion. There was no
      discussion


      >> under #55


      >>


      >>


      >> - Limited discussion on the interaction between the new
      realm


      >> reports and the existing host and RRR reports.


      >>


      >> After London meeting:


      >>


      >> #23 status: - Tentative agreement in London meeting to
      remove RRR


      >> reports.


      >>


      >> What was the technical
      argument?


      >>


      >>


      >> - Ben expressed the strongest concern with this plan.
      Steve and


      >> Ben took action to discuss and come back with a
      recommendation.


      >>


      >> #55 status: - No change


      >>


      >> Summary: - Tentative consensus reached to move forward
      with two


      >> report types - host and realm, with realm having the new



      >> definition. What was the technical
      argument?


      >>


      >>


      >> Current status:


      >>


      >> #23 status: - Change the name to RRR - Whether or not to
      remove


      >> RRR and revisit later or keep RRR and revisit later is an
      open


      >> issue.


      >>


      >> #55 status: - My opinion is that we have at least rough
      consensus


      >> on the need to support realm reports.  Others might have
      a


      >> different opinion.


      >>


      >>  There was no comment posted to issue #55,
      also no


      >> proposed solution, so I cannot see where the consensus
      came


      >> from


      >>


      >>


      >>


      >> Summary: - I believe we have three options:


      >>


      >> 1) Support host and RRR reports 2) Support host and Realm
      reports


      >> -- This was the tentative plan coming out of the London
      meeting


      >>


      >> < Ulrich> There is not even an issue number
      identifying problems


      >> with RRR and proposing to remove RRR


      >>


      >>


      >> 3) Support host, RRR and Realm reports


      >>


      >>  I support option 1


      >>


      >>


      >> Regards,


      >>


      >> Steve


      >>


      >> On 3/25/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:


      >>


      >> Steve,


      >>


      >> I don't think we are going backwards (we may be out of
      synch


      >> though)


      >>


      >>


      >>


      >> Can you please summarize the status of #23 and #55.


      >>


      >>


      >>


      >> Ulrich


      >>


      >>


      >>


      >>


      >>


      >> *From:*ext Steve Donovan
      [mailto:srdonovan@usdonovans.com] *Sent:*


      >> Monday, March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -



      >> DE/Munich); dime@ietf.org 
      *Subject:* Re:


      >> [Dime] Resolution on action to discuss the need for


      >> Realm-Routed-Reports


      >>


      >>


      >>


      >> Ok, we are going backwards on this one.


      >>


      >> I did not include option three because we had moved past
      that


      >> option in our discussions, both on the list (I thought),
      and in


      >> the meeting.


      >>


      >> I believe that we had come to rough consensus on the need
      for a


      >> realm report and the only remaining issue was whether we
      also


      >> included the RRR report type.


      >>


      >> At this point, the only option is to leave all of the
      issues


      >> related to the report types open and attempt to resolve
      them in


      >> the -03 draft.


      >>


      >> Steve


      >>


      >> On 3/24/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:


      >>


      >> Steve,


      >>


      >>


      >>


      >> I do not agree.


      >>


      >>


      >>


      >> We should still have the option


      >>


      >> 3) support report type 0 (this is called host report) and
      support


      >> of report type 1 (this has been called relam report but
      people


      >> argued it should better be called realm routed request
      report).


      >>


      >>


      >>


      >> Whether or not we need in addition to type 0 and type 1
      (or as a


      >> replacement of type 1) a


      >> realm-no-matter-whether-destination-host-is
      present-or-not report


      >> is an open issue (see #55).


      >>


      >> There are a lot of open questions  with regard to #55 and
      I have


      >> not seen a conclusion.


      >>


      >> Where I have seen a conclusion is issue #34 and that is
      inline


      >> with option 3).


      >>


      >>


      >>


      >> Unless we conclude on #55, or decide to re-open #34,
      option 3) is


      >> what should go in the -02 draft.


      >>


      >>


      >>


      >>


      >>


      >> Ulrich


      >>


      >>


      >>


      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *ext


      >> Steve Donovan *Sent:* Monday, March 24, 2014 2:57 PM
      *To:*


      >> dime@ietf.org  *Subject:* Re:
      [Dime]


      >> Resolution on action to discuss the need for
      Realm-Routed-Reports


      >>


      >>


      >>


      >> Ulrich, All,


      >>


      >> We have two options for the -02 draft.


     >>


      >> 1) Support Host and Realm as proposed below, removing RRR
      reports.


      >>  2) Support Host, Realm and RRR reports.


      >>


      >> The default plan is to go with option 1 in the -02 draft,
      as that


      >> was the proposal that came out of the meeting in London.
      RRR


      >> reports can be added back in if and when we are convinced
      of the


      >> need.


      >>


      >> If there are strong objections to this then I will update
      the -02


      >> draft to reflect all three report types.


      >>


      >> I plan to make these updates Wednesday morning, Dallas,
      Texas


      >> time.


      >>


      >> Either way I do not expect we will have agreed to wording
      on the


      >> interaction between the report types when a reacting node
      has


      >> multiple report types, all of which apply to individual
      requests.


      >> This will need to be addressed in the -03 draft.


      >>


      >> Regards,


      >>


      >> Steve


      >>


      >> On 3/21/14 4:05 PM, Steve Donovan wrote:


      >>


      >> Ulrich,


      >>


      >> The discussion should be captured in the minutes to the
      meeting.


      >> I wasn't able to find them posted yet.


      >>


      >> Jouni, Lionel, what is the status of the minutes for the
      meeting?


      >>


      >> My reading of emails prior to the London meeting is
      different from


      >> yours.  I believe we had come to the conclusion that we
      needed


      >> host and realm (with the definition of realm as outlined
      below).


      >> We were still discussing the need for
      Realm-Routed-Request


      >> reports.


      >>


      >> Regards,


      >>


      >> Steve


      >>


      >> On 3/21/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)
      wrote:


      >>


      >> Steve,


      >>


      >>


      >>


      >> I don't know what happend in London.


      >>


      >> Can you please summarize the technical reasons that led
      to the


      >> London agreement.


      >>


      >> E-mail discussions prior to London have clearly directed
      towards a


      >> report type that requests throttling of realm routed
      request


      >> messages (i.e. not containing a destination host) rather
      than a


      >> report type that requests throttling of messages routed
      towards a


      >> realm (no matter whether they contain a destination host
      or not).


      >>


      >>


      >>


      >>


      >> Ulrich


      >>


      >>


      >>


      >> *From:*DiME [mailto:dime-bounces@ietf.org] *On Behalf Of
      *ext


      >> Steve Donovan *Sent:* Friday, March 21, 2014 3:33 PM
      *To:*


      >> dime@ietf.org  *Subject:*
      [Dime] Resolution


      >> on action to discuss the need for Realm-Routed-Reports


      >>


      >>


      >>


      >> All,


      >>


      >> Ben and I took the action item to discuss the need for
      the


      >> Realm-Routed-Reports (RRR) report type.


      >>


      >> As you may recall, the consensus coming out of the DIME
      WG meeting


      >> in London was to support two report types:


      >>


      >> - Host -- Impacting requests with a Destination-Host AVP
      matching


      >> the host in the overload report (with the host implicitly



      >> determined from the Origin-Host AVP of the answer message
      carrying


      >> the overload report).


      >>


      >> - Realm -- Impacting 100% of the requests with a
      Destination-Realm


      >> AVP matching the realm in the overload report (with the
      realm


      >> implicitly determine from the Origin-Realm of the answer
      message


      >> carrying the overload report).


      >>


      >> The action Ben and I took was to come back with an
      opinion on


      >> whether RRR reports should also be supported.


      >>


      >> My summary of the discussion is that we recommend to NOT
      include


      >> RRR reports in the current version of the base DOIC
      draft.


      >>


      >> We still have some concerns with the granularity of
      control


      >> enabled by having just the two report types but the
      analysis of


      >> whether RRR reports are still needed can occur
      independent of the


      >> base DOIC draft.  If there is a determination that RRRs
      are needed


      >> in time to include in the base draft then it can be
      considered at


      >> that time.


      >>


      >> Based on this, I propose the following


      >>


      >> - Resolution to issue #23 is to remove RRR reports from
      the


      >> document. - Resolution to issue #55 is to add Realm
      reports


      >> (actually to redefine them per the above definition). -
      Resolution


      >> to issue #57 is that it no longer applies (as it deals
      with RRRs).


      >>


      >> There is also need for text describing the interaction
      between


      >> host and the realm reports.  I don't expect we will have
      consensus


      >> on this wording prior to the -02 draft being submitted.
      To this


      >> end, I'll open a new issue to deal with the need for
      wording on


      >> the interaction.


      >>


      >> Regards,


      >>


      >> Steve


      >>


      >>


      >>


      >>


      >>


      >> _______________________________________________


      >>


      >> 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 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 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


      > 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 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.


___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E51E620PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











I confirm =
that we agree:


Realm: for=
 all the messages towards a given relam (with or without destination)<=
/o:p>


Host: for =
all the messages towards a given diestination-host


Realm +=
; Host: only host apply when the given destination host is in the message.<=
o:p>


 =
;


Lionel


 =
;






De :=
 Steve Donovan [mailto:srdonovan@usdonovans.co=
m]


Envoy=E9 : mercredi 26 mars 2014 15:31

=C0 : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; Wiehe, Ulric=
h (NSN - DE/Munich); dime@ietf.org

Objet : Re: [Dime] Resolution on action to discuss the need for=
 Realm-Routed-Reports






 


Lionel,



Please see comments inline.



Regards,



Steve




On 3/26/14 8:15 AM, 
lionel.morand@orange.com wrote:






When determining if a request s=
hould be throttled, there are three cases:



- Only a Realm report (based on the definition from the meeting) matches th=
e message -- In this case the Realm report MUST be used to determine if the=
 message is throttled.

- Only a Host report matches the message -- In this case the Host report MU=
ST be used to determine if the message is throttled.

- Both a Realm and Host report match the message -- In this case the Host r=
eport MUST be used to determine if the message is throttled and throttling =
based on the Realm report MUST NOT also be applied to the message.



I'm ok at the moment with this wording, but I don't think we've thou=
ght through the implications of prioritizing Host reports over Realm report=
s when both apply.  As such, this is open to change in a future versio=
n of the draft.








[LM] OK<=
/b>


 




SRD> Just to be 100% clear on the first bullet ab=
ove.  This, I believe, is where we have confusion and disagreement on =
this topic.



My proposal is that the Realm report effects 100% of messages that contain =
a Realm AVP that matches the Realm report.



The other definition is that the report effects only messages that match th=
e Realm in the report AND do not have a Destination-Host AVP. 




These are very different definitions and is why it is important to define w=
hat is meant by Realm reports.






> 








      > About renam=
ing "Realm" as "Realm-Routed-Request", no strong


      issue as 








      > soon as the=
 principle above are kept.



SRD> If we go with your proposal above then there is no name change but =
rather a change in the definition of Realm report.








[LM]=
 don't think that the current definition needs to be changed. However the b=
ehavior of the reacting node should be clarified when both
 Host and Realm report type are applicable to a single message.<=
/b>


 


SRD> See above.  Plus, the -01 draft contain=
s BOTH definitions, so it needs to be updated.






If we go with Ulrich's proposal=
 then we should change the name from Realm to RRR (or some other name yet t=
o be suggested).



If we go with three reports then we also need to change the name of the exi=
sting Realm report to RRR and redefine Realm to match the above logic.








[LM]=
 let's play with only two for now.


&nbs=
p;


> 








     &=
nbsp;> The need for realm-based type that would apply to any requ=
est


      (even 








      > if a "=
Host" exists for a destination-host in the request) was


      








      > challenged =
and not retained. Ben was supposed to lock you in


      a room 








      > and to conv=
ince you that this last report type was not


      needed.



This is NOT my recollection of the decision and is NOT what is reflected in=
 the minutes.  This is also NOT what you say above.




Here's the relevant portion of the minutes:



Report types - there was consensus that Host and Realm report types needed =
to be retained. Ben suggested that if a node sent a Realm report, it needed=
 to be an absolute authority for the realm. Dave did not agree that agents =
needed to be authoritative and felt
 that clients should be able to make their own decisions on conflicting rea=
lm reports, which Lionel disagreed with. Maria Cruz agreed with both propos=
als because it would be deployment dependent. Steve said that the draft sho=
uld provide guidance that a sender
 of the realm report should be an authority and that realm reports should n=
ot contradict. It should provide guidance on what the client should do if d=
oes receive different realm reports. Ben pointed out that, in the case wher=
e a realm was sending overload reports,
 individual servers could send Reductions of 0% in their reports to provide=
 more information to clients.






ACTION: Ben and Steve to discuss Realm-Routed-Request and come up with a pr=
oposal on whether to remove or to incorporate.




ACTION: Next version of DOIC will keep Host and Realm and leave Realm-Route=
d-Request an open issue.




ACTION: Clarify precedence of the host and realm report types and what acti=
ons to take when they are received.









[LM] ok<=
/b>








> 








      > Lionel








      > 








      > Envoy=E9 de=
puis mon Sony Xperia SP d'Orange








      > 








      > Steve Donov=
an 
<srdonovan@usdonovans.com> a =E9crit :








      > 








      > Consensus i=
s obviously a fleeting and temporary thing.








      > 








      > Let us make=
 sure that we are precise in our definitions of


      the








      > report types we =
are discussing.








      > 








      > Host report=
 - Applies when the destination-host AVP is


      present in








      > the request. Rea=
lm-Routed-Request (RRR) - Applies when there


      is no 








      > destination=
-host AVP in the request. Realm - Applies to 100%


      of 








      > requests se=
nt to the realm.








      > 








      > These are t=
he definitions used in our discussions in London


      and in 








      > various pla=
ces in our email discussions.








      > 








      > Can we plea=
se agree to use these definitions going forward so


      we are 








      > all talking=
 about the same thing.








      > 








      > Regards,








      > 








      > Steve








      > 








      > On 3/25/14 =
10:27 AM, 
lionel.morand@orange.com wrote:








      >> 








      >> Hi Mari=
a Cruz, All,








      >> 








      >> 








      >> 








      >> In the =
previous mail, you wrote:








      >> 








      >> 








      >> 








      >> /That i=
s, we have two reports, host and realm. /








      >> 








      >> /Host a=
pplies when Destination_host is present, and then


      it takes 








      >> precede=
nce over Realm. If both are present, only Host is


      applied./








      >> 








      >> /Realm =
applies when only Destination_realm is present./








      >> 








      >> 








      >> 








      >> And I a=
gree with this statement. But I'm not sure that


      this is the 








      >> case di=
scussed by Ulrich.








      >> 








      >> 








      >> 








      >> Whateve=
r the name of the realm report type, is there an


      agreement 








      >> on the =
description given above by Maria Cruz and


      discussed in 








      >> London?=









      >> 








      >> 








      >> 








      >> Regards=
,








      >> 








      >> 








      >> 








      >> Lionel<=
br>







      >> 








      >> 








      >> 








      >> *De :*D=
iME [mailto:dime-bounces@ietf.org<=
/a>] *De la part de*


      Maria 








      >> Cruz Ba=
rtolome *Envoy=E9 :* mardi 25 mars 2014 16:21 *=C0 :*


      Wiehe, 








      >> Ulrich =
(NSN - DE/Munich); ext Steve Donovan;


      dime@ietf.org *Objet









      >> :* Re: =
[Dime] Resolution on action to discuss the need


      for 








      >> Realm-R=
outed-Reports








      >> 








      >> 








      >> 








      >> Dear al=
l,








      >> 








      >> 








      >> 








      >> I suppo=
rt option 1 a well








      >> 








      >> Cheers<=
br>







      >> 








      >> /MCruz<=
br>







      >> 








      >> 








      >> 








      >> *From:*=
DiME [mailto:dime-bounces@ietf.org=
] *On Behalf Of


      *Wiehe, 








      >> Ulrich =
(NSN - DE/Munich) *Sent:* martes, 25 de marzo de


      2014 16:15








      >>  *To:* =
ext Steve Donovan; 
dime@ietf.org *Subject:* Re:


      [Dime] 








      >> Resolut=
ion on action to discuss the need for


      Realm-Routed-Reports<=
br>







      >> 








      >> 








      >> 








      >> Steve,<=
br>







      >> 








      >> Thank y=
ou for this summary.








      >> 








      >> Please =
see inline.








      >> 








      >> 








      >> 








      >> Ulrich<=
br>







      >> 








      >> 








      >> 








      >> *From:*=
ext Steve Donovan


      [mailto:srdonovan@usdonovans.com] *Sent:*









      >> Tuesday=
, March 25, 2014 2:49 PM *To:* Wiehe, Ulrich (NSN


      - 








      >> DE/Muni=
ch); dime@ietf.org
<mailto:dime@ietf.org>


      *Subject:* Re: 








      >> [Dime] =
Resolution on action to discuss the need for









      >> Realm-R=
outed-Reports








      >> 








      >> 








      >> 








      >> Ulrich,=









      >> 








      >> I mean =
going backwards from where I thought we were after


      the 








      >> London =
meeting.








      >> 








      >> We are =
clearly out of sync but hopefully we can fix that.








      >> 








      >> Here's =
my understanding of the status of #23 and #55.








      >> 








      >> Prior t=
o London meeting:








      >> 








      >> #23 sta=
tus: - Agreement to change the name of existing


      realm 








      >> reports=
 to realm-routed-reports (RRR).








      >> 








      >> <Ulr=
ich>this includes agreement to keep the (newly


      called) 








      >> realm-r=
outed-reports</Ulrich> - Discussions were


      ongoing as to the 








      >> need fo=
r both realm reports and RRR reports.








      >> 








      >> <Ulr=
ich>I would say “…as to the need for realm


      reports in addition <=
br>







      >> to real=
m-routed-reports” </Ulrich>








      >> 








      >> 








      >> 








      >> #55 sta=
tus: - Agreement on adding Realm reports based on


      the 








      >> definit=
ion that realm reports apply to all traffic sent


      to the 








      >> realm.<=
br>







      >> 








      >> <Ulr=
ich>This is what I’m missing. The issue has


      been very briefly 








      >> discuss=
ed under #34 without conclusion. There was no


      discussion 








      >> under #=
55</Ulrich>








      >> 








      >> 








      >> - Limit=
ed discussion on the interaction between the new


      realm 








      >> reports=
 and the existing host and RRR reports.








      >> 








      >> After L=
ondon meeting:








      >> 








      >> #23 sta=
tus: - Tentative agreement in London meeting to


      remove RRR 








      >> reports=
.








      >> 








      >> <Ulr=
ich>What was the technical


      argument?</Ulrich&=
gt;








      >> 








      >> 








      >> - Ben e=
xpressed the strongest concern with this plan. 


      Steve and 








      >> Ben too=
k action to discuss and come back with a


      recommendation.








      >> 








      >> #55 sta=
tus: - No change








      >> 








      >> Summary=
: - Tentative consensus reached to move forward


      with two 








      >> report =
types - host and realm, with realm having the new


      








      >> definit=
ion. <Ulrich>What was the technical


      argument?</Ulrich&=
gt;








      >> 








      >> 








      >> Current=
 status:








      >> 








      >> #23 sta=
tus: - Change the name to RRR - Whether or not to


      remove








      >> RRR and revi=
sit later or keep RRR and revisit later is an


      open








      >> issue.








      >> 








      >> #55 sta=
tus: - My opinion is that we have at least rough


      consensus 








      >> on the =
need to support realm reports.  Others might have


      a 








      >> differe=
nt opinion.








      >> 








      >> <Ulr=
ich> There was no comment posted to issue #55,


      also no








      >> proposed sol=
ution, so I cannot see where the consensus


      came








      >> from</Ulr=
ich>








      >> 








      >> 








      >> 








      >> Summary=
: - I believe we have three options:








      >> 








      >> 1) Supp=
ort host and RRR reports 2) Support host and Realm


      reports 








      >> -- This=
 was the tentative plan coming out of the London


      meeting








      >> 








      >> < Ul=
rich> There is not even an issue number


      identifying problems =









      >> with RR=
R and proposing to remove RRR</Ulrich>








      >> 








      >> 








      >> 3) Supp=
ort host, RRR and Realm reports








      >> 








      >> <Ulr=
ich> I support option 1</Ulrich>








      >> 








      >> 








      >> Regards=
,








      >> 








      >> Steve







      >> 








      >> On 3/25=
/14 6:44 AM, Wiehe, Ulrich (NSN - DE/Munich)


      wrote:








      >> 








      >> Steve,<=
br>







      >> 








      >> I don&#=
8217;t think we are going backwards (we may be out of


      synch 








      >> though)=









      >> 








      >> 








      >> 








      >> Can you=
 please summarize the status of #23 and #55.








      >> 








      >> 








      >> 








      >> Ulrich<=
br>







      >> 








      >> 








      >> 








      >> 








      >> 








      >> *From:*=
ext Steve Donovan


      [mailto:srdonovan@usdonovans.com] *Sent:*









      >> Monday,=
 March 24, 2014 7:38 PM *To:* Wiehe, Ulrich (NSN -


      








      >> DE/Muni=
ch); dime@ietf.org
<mailto:dime@ietf.org>


      *Subject:* Re: 








      >> [Dime] =
Resolution on action to discuss the need for









      >> Realm-R=
outed-Reports








      >> 








      >> 








      >> 








      >> Ok, we =
are going backwards on this one.








      >> 








      >> I did n=
ot include option three because we had moved past


      that 








      >> option =
in our discussions, both on the list (I thought),


      and in








      >> the meeting.=









      >> 








      >> I belie=
ve that we had come to rough consensus on the need


      for a 








      >> realm r=
eport and the only remaining issue was whether we


      also 








      >> include=
d the RRR report type.








      >> 








      >> At this=
 point, the only option is to leave all of the


      issues 








      >> related=
 to the report types open and attempt to resolve


      them in








      >> the -03 draf=
t.








      >> 








      >> Steve







      >> 








      >> On 3/24=
/14 11:13 AM, Wiehe, Ulrich (NSN - DE/Munich)


      wrote:








      >> 








      >> Steve,<=
br>







      >> 








      >> 








      >> 








      >> I do no=
t agree.








      >> 








      >> 








      >> 








      >> We shou=
ld still have the option








      >> 








      >> 3) supp=
ort report type 0 (this is called host report) and


      support 








      >> of repo=
rt type 1 (this has been called relam report but


      people 








      >> argued =
it should better be called realm routed request


      report).








      >> 








      >> 








      >> 








      >> Whether=
 or not we need in addition to type 0 and type 1


      (or as a 








      >> replace=
ment of type 1) a 








      >> realm-n=
o-matter-whether-destination-host-is


      present-or-not report=
 








      >> is an o=
pen issue (see #55).








      >> 








      >> There a=
re a lot of open questions  with regard to #55 and


      I have 








      >> not see=
n a conclusion.








      >> 








      >> Where I=
 have seen a conclusion is issue #34 and that is


      inline








      >> with option =
3).








      >> 








      >> 








      >> 








      >> Unless =
we conclude on #55, or decide to re-open #34,


      option 3) is 








      >> what sh=
ould go in the -02 draft.








      >> 








      >> 








      >> 








      >> 








      >> 








      >> Ulrich<=
br>







      >> 








      >> 








      >> 








      >> *From:*=
DiME [mailto:dime-bounces@ietf.org=
] *On Behalf Of


      *ext








      >> Steve Donova=
n *Sent:* Monday, March 24, 2014 2:57 PM


      *To:*








      >> dime@ietf.org 
<mailto:dime@ietf.org> *Subject:* Re:


      [Dime]








      >> Resolution o=
n action to discuss the need for


      Realm-Routed-Reports<=
br>







      >> 








      >> 








      >> 








      >> Ulrich,=
 All,








      >> 








      >> We have=
 two options for the -02 draft.








     >> 








      >> 1) Supp=
ort Host and Realm as proposed below, removing RRR


      reports.








      >>  2) Sup=
port Host, Realm and RRR reports.








      >> 








      >> The def=
ault plan is to go with option 1 in the -02 draft,


      as that 








      >> was the=
 proposal that came out of the meeting in London. 


      RRR 








      >> reports=
 can be added back in if and when we are convinced


      of the 








      >> need.







      >> 








      >> If ther=
e are strong objections to this then I will update


      the -02 








      >> draft t=
o reflect all three report types.








      >> 








      >> I plan =
to make these updates Wednesday morning, Dallas,


      Texas 








      >> time.







      >> 








      >> Either =
way I do not expect we will have agreed to wording


      on the 








      >> interac=
tion between the report types when a reacting node


      has 








      >> multipl=
e report types, all of which apply to individual


      requests. 








      >> This wi=
ll need to be addressed in the -03 draft.








      >> 








      >> Regards=
,








      >> 








      >> Steve







      >> 








      >> On 3/21=
/14 4:05 PM, Steve Donovan wrote:








      >> 








      >> Ulrich,=









      >> 








      >> The dis=
cussion should be captured in the minutes to the


      meeting.








      >> I wasn't abl=
e to find them posted yet.








      >> 








      >> Jouni, =
Lionel, what is the status of the minutes for the


      meeting?








      >> 








      >> My read=
ing of emails prior to the London meeting is


      different from 








      >> yours.&=
nbsp; I believe we had come to the conclusion that we


      needed








      >> host and rea=
lm (with the definition of realm as outlined


      below).








      >> We were stil=
l discussing the need for


      Realm-Routed-Request<=
br>







      >> reports.








      >> 








      >> Regards=
,








      >> 








      >> Steve







      >> 








      >> On 3/21=
/14 10:09 AM, Wiehe, Ulrich (NSN - DE/Munich)


      wrote:








      >> 








      >> Steve,<=
br>







      >> 








      >> 








      >> 








      >> I don&#=
8217;t know what happend in London.








      >> 








      >> Can you=
 please summarize the technical reasons that led


      to the 








      >> London =
agreement.








      >> 








      >> E-mail =
discussions prior to London have clearly directed


      towards a 








      >> report =
type that requests throttling of realm routed


      request 








      >> message=
s (i.e. not containing a destination host) rather


      than a 








      >> report =
type that requests throttling of messages routed


      towards a 








      >> realm (=
no matter whether they contain a destination host


      or not).








      >> 








      >> 








      >> 








      >> 








      >> Ulrich<=
br>







      >> 








      >> 








      >> 








      >> *From:*=
DiME [mailto:dime-bounces@ietf.org=
] *On Behalf Of


      *ext








      >> Steve Donova=
n *Sent:* Friday, March 21, 2014 3:33 PM


      *To:*








      >> dime@ietf.org 
<mailto:dime@ietf.org> *Subject:*


      [Dime] Resolution








      >> on action to=
 discuss the need for Realm-Routed-Reports








      >> 








      >> 








      >> 








      >> All,








      >> 








      >> Ben and=
 I took the action item to discuss the need for


      the 








      >> Realm-R=
outed-Reports (RRR) report type.








      >> 








      >> As you =
may recall, the consensus coming out of the DIME


      WG meeting 








      >> in Lond=
on was to support two report types:








      >> 








      >> - Host =
-- Impacting requests with a Destination-Host AVP


      matching 








      >> the hos=
t in the overload report (with the host implicitly


      








      >> determi=
ned from the Origin-Host AVP of the answer message


      carrying 








      >> the ove=
rload report).








      >> 








      >> - Realm=
 -- Impacting 100% of the requests with a


      Destination-Realm 








      >> AVP mat=
ching the realm in the overload report (with the


      realm 








      >> implici=
tly determine from the Origin-Realm of the answer


      message 








      >> carryin=
g the overload report).








      >> 








      >> The act=
ion Ben and I took was to come back with an


      opinion on 








      >> whether=
 RRR reports should also be supported.








      >> 








      >> My summ=
ary of the discussion is that we recommend to NOT


      include 








      >> RRR rep=
orts in the current version of the base DOIC


      draft.








      >> 








      >> We stil=
l have some concerns with the granularity of


      control








      >> enabled by h=
aving just the two report types but the


      analysis of








      >> whether RRR =
reports are still needed can occur


      independent of the








      >> base DOIC dr=
aft.  If there is a determination that RRRs


      are needed








      >> in time to i=
nclude in the base draft then it can be


      considered at








      >> that time.







      >> 








      >> Based o=
n this, I propose the following








      >> 








      >> - Resol=
ution to issue #23 is to remove RRR reports from


      the 








      >> documen=
t. - Resolution to issue #55 is to add Realm


      reports 








      >> (actual=
ly to redefine them per the above definition). -


      Resolution 








      >> to issu=
e #57 is that it no longer applies (as it deals


      with RRRs).








      >> 








      >> There i=
s also need for text describing the interaction


      between








      >> host and the=
 realm reports.  I don't expect we will have


      consensus








      >> on this word=
ing prior to the -02 draft being submitted. 


      To this








      >> end, I'll op=
en a new issue to deal with the need for


      wording on








      >> the interact=
ion.








      >> 








      >> Regards=
,








      >> 








      >> Steve







      >> 








      >> 








      >> 








      >> 








      >> 








      >> _______=
________________________________________








      >> 








      >> DiME ma=
iling list








      >> 








      >> DiME@ietf.org 
<mailto: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 s=
ans autorisation. Si vous 








      >> avez re=
cu ce message par erreur, veuillez le signaler a









      >> l'exped=
iteur et le detruire ainsi que les pieces jointes.


      Les 








      >> message=
s electroniques etant susceptibles d'alteration,


      Orange 








      >> decline=
 toute responsabilite si ce message a ete altere,


      deforme








      >> ou falsifie.=
 Merci.








      >> 








      >> This me=
ssage and its attachments may contain confidential


      or 








      >> privile=
ged information that may be protected by law; they


      should 








      >> not be =
distributed, used or copied without authorisation.


      If you 








      >> have re=
ceived 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 fals=
ified. Thank you.








      > 








      ><=
/p>

____________________________________________________=
_____________________________________________________________________








      >








      >








      >








      > 

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 autorisat=
ion. Si vous 








      > avez recu c=
e message par erreur, veuillez le signaler a


      l'expediteur 








      > et le detru=
ire ainsi que les pieces jointes. Les messages









      > electroniqu=
es etant susceptibles d'alteration, Orange decline


      toute 








      > responsabil=
ite si ce message a ete altere, deforme ou


      falsifie. 








      > Merci.








      > 








      > This messag=
e and its attachments may contain confidential or


      








      > privileged =
information that may be protected by law; they


      should not 








      > be distribu=
ted, used or copied without authorisation. If you


      have 








      > received th=
is email in error, please notify the sender and


      delete 








      > this messag=
e and its attachments. As emails may be altered,


      Orange








      > is not liable fo=
r messages that have been modified, changed


      or 








   &nb=
sp;  > falsified. Thank you.








______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 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_6B7134B31289DC4FAF731D844122B36E51E620PEXCVZYM13corpora_--


From nobody Wed Mar 26 08:47:09 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 6D4881A018F for ; Wed, 26 Mar 2014 08:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 sBM2yGrKaSJl for ; Wed, 26 Mar 2014 08:47:06 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8B11A0306 for ; Wed, 26 Mar 2014 08:47:06 -0700 (PDT)
Received: from [137.254.4.56] (port=42493 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSq2X-0000ix-2U; Wed, 26 Mar 2014 08:46:58 -0700
Message-ID: <5332F680.9030102@usdonovans.com>
Date: Wed, 26 Mar 2014 10:47:12 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> <072.6892b07263eb158352dabe97ef8b9ed4@trac.tools.ietf.org>
In-Reply-To: <072.6892b07263eb158352dabe97ef8b9ed4@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------090700000903060907000906"
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/jwrLFSvmfsAVG6L61c09pj7mpnE
Subject: Re: [Dime] [dime] #44 (draft-docdt-dime-ovli): Incorrect sequence number behavior
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: Wed, 26 Mar 2014 15:47:07 -0000

This is a multi-part message in MIME format.
--------------090700000903060907000906
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

All,

When looking to make the change documented below, I realized that this
wording had already been changed as a result of a previous agreed to
change.  I haven't searched down which one, but the new wording in the
current -02 snapshot is as following.  I believe that this is consistent
with the proposed wording below and, as such, have not further updated
the paragraph.

If the value of the OC-Sequence-Number AVP contained in the received
   OC-OLR AVP is equal to or less than the value stored in an existing
   overload condition state, the received OC-OLR AVP SHOULD be silently
   discarded.  If the value of the OC-Sequence-Number AVP contained in
   the received OC-OLR AVP is greater than the value stored in an
   existing overload condition state or there is no previously recorded
   sequence number, the reacting node MUST update the overload condition
   state associated with the realm or the specific node is the realm.

Regards,

Steve
On 3/24/14 3:17 PM, dime issue tracker wrote:
> #44: Incorrect sequence number behavior
>
> Changes (by srdonovan@usdonovans.com):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>
> Comment:
>
>  Change the last sentence of section 4.3, paragraph 3 to “The reacting node
>  SHOULD discard an OC-OLR AVP with a sequence number that is less than or
>  equal to the previously received sequence number.â€
>


--------------090700000903060907000906
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    All,

      

      When looking to make the change documented below, I realized that
      this wording had already been changed as a result of a previous
      agreed to change.  I haven't searched down which one, but the new
      wording in the current -02 snapshot is as following.  I believe
      that this is consistent with the proposed wording below and, as
      such, have not further updated the paragraph.

      

      If the value of the OC-Sequence-Number AVP contained in the
      received

         OC-OLR AVP is equal to or less than the value stored in an
      existing

         overload condition state, the received OC-OLR AVP SHOULD be
      silently

         discarded.  If the value of the OC-Sequence-Number AVP
      contained in

         the received OC-OLR AVP is greater than the value stored in an

         existing overload condition state or there is no previously
      recorded

         sequence number, the reacting node MUST update the overload
      condition

         state associated with the realm or the specific node is the
      realm.

      

      Regards,

      

      Steve

    
    
On 3/24/14 3:17 PM, dime issue tracker
      wrote:

    

    

      
#44: Incorrect sequence number behavior

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Change the last sentence of section 4.3, paragraph 3 to “The reacting node
 SHOULD discard an OC-OLR AVP with a sequence number that is less than or
 equal to the previously received sequence number.â€



    

    

  


--------------090700000903060907000906--


From nobody Wed Mar 26 08:55: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 1D5E51A018F for ; Wed, 26 Mar 2014 08:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 ocg49t46lcnn for ; Wed, 26 Mar 2014 08:54:55 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5F81B1A0186 for ; Wed, 26 Mar 2014 08:54:55 -0700 (PDT)
Received: from localhost ([127.0.0.1]:49301 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WSqAC-0002lQ-F9; Wed, 26 Mar 2014 16:54:48 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Wed, 26 Mar 2014 15:54:48 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/46#comment:1
Message-ID: <072.213a8b3a12a7aa6ee65579ab928747c2@trac.tools.ietf.org>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>
X-Trac-Ticket-ID: 46
In-Reply-To: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/4J8wwDzdWtK2V0I-unhCschYPc0
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Bad normative advice on not letting overload reports expire
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: Wed, 26 Mar 2014 15:54:57 -0000

#46: Bad normative advice on not letting overload reports expire


Comment (by srdonovan@usdonovans.com):

 Section 4.5., paragraph 3 -

 Current -02 wording:

 As a general guidance for implementations it is RECOMMENDED never to
    let any overload report to timeout.  Following to this rule, an
    overload endpoint should explicitly signal the end of overload
    condition and not rely on the expiration of the validity time of the
    overload report in the reacting node.  This is achieved by sending an
    updated overload report (meaning it must contain a new sequence
    number) with the OC-Validity-Duration AVP value set to zero ("0").

 Change to:

 When a reporting node has recovered from overload, it SHOULD invalidate
 any existing overload reports in a timely matter. This can be achieved by
 sending an updated overload report (meaning the OLR contains a new
 sequence number) with the OC-Validity-Duration AVP value set to zero
 ("0"). If the overload report is about to expire naturally, the reporting
 node MAY choose to simply let it do so.

  A reacting node MUST invalidate and remove an overload report that
   expires without an explicit overload report containing an OC-Validity-
 Duration
   value set to zero ("0").

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  new
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Wed Mar 26 08:55:07 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 D049A1A0332 for ; Wed, 26 Mar 2014 08:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 L-QQfAMd2try for ; Wed, 26 Mar 2014 08:55:03 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEA21A02D8 for ; Wed, 26 Mar 2014 08:55:03 -0700 (PDT)
Received: from localhost ([127.0.0.1]:49311 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WSqAM-0005fl-Nh; Wed, 26 Mar 2014 16:54:58 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Wed, 26 Mar 2014 15:54:58 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/46#comment:2
Message-ID: <072.7d443a4edac60a57875c19e18faeb61e@trac.tools.ietf.org>
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>
X-Trac-Ticket-ID: 46
In-Reply-To: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/2GpwDqfaCyCjdFyKrwjpLI-Iz4M
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Bad normative advice on not letting overload reports expire
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: Wed, 26 Mar 2014 15:55:05 -0000

#46: Bad normative advice on not letting overload reports expire

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Wed Mar 26 08:59:04 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 C8A7C1A019A for ; Wed, 26 Mar 2014 08:59:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 Jn4GD-Sk5dYB for ; Wed, 26 Mar 2014 08:59:03 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 287731A0119 for ; Wed, 26 Mar 2014 08:59:03 -0700 (PDT)
Received: from [137.254.4.56] (port=57448 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSqEC-0008Pr-TI; Wed, 26 Mar 2014 08:58:57 -0700
Message-ID: <5332F955.7050303@usdonovans.com>
Date: Wed, 26 Mar 2014 10:59:17 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> <072.7d443a4edac60a57875c19e18faeb61e@trac.tools.ietf.org>
In-Reply-To: <072.7d443a4edac60a57875c19e18faeb61e@trac.tools.ietf.org>
Content-Type: multipart/alternative; boundary="------------030400070901030903060406"
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/S-kUrVurxDc6cFWRYCGOwEmaWqM
Subject: Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Bad normative advice on not letting overload reports expire
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: Wed, 26 Mar 2014 15:59:04 -0000

This is a multi-part message in MIME format.
--------------030400070901030903060406
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Ben,

I took the liberty to close this issue for you based on your suggested
wording.  If you disagree please re-open.

Regards,

Steve

On 3/26/14 10:54 AM, dime issue tracker wrote:
> #46: Bad normative advice on not letting overload reports expire
>
> Changes (by srdonovan@usdonovans.com):
>
>  * status:  new => closed
>  * resolution:   => fixed
>
>


--------------030400070901030903060406
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Ben,

      

      I took the liberty to close this issue for you based on your
      suggested wording.  If you disagree please re-open.

      

      Regards,

      

      Steve

      

    
    
On 3/26/14 10:54 AM, dime issue tracker
      wrote:

    

    

      
#46: Bad normative advice on not letting overload reports expire

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed




    

    

  


--------------030400070901030903060406--


From nobody Wed Mar 26 09:09:52 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 BAE6A1A017D for ; Wed, 26 Mar 2014 09:09:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 1j-Z0-pJequk for ; Wed, 26 Mar 2014 09:09:35 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id A78E21A0364 for ; Wed, 26 Mar 2014 09:09:34 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2QG9UrA082122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Mar 2014 11:09:31 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <5332F955.7050303@usdonovans.com>
Date: Wed, 26 Mar 2014 11:09:31 -0500
X-Mao-Original-Outgoing-Id: 417542971.558609-a3a6e0154d45b204501b32dde7dc40c4
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.8b248d3cb5db23879c2730b80d4657d7@trac.tools.ietf.org> <072.7d443a4edac60a57875c19e18faeb61e@trac.tools.ietf.org> <5332F955.7050303@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/t0Jk-mQ15E-M35Qz_Z8Wgqd2_J8
Cc: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #46 (draft-docdt-dime-ovli): Bad normative advice on not letting overload reports expire
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: Wed, 26 Mar 2014 16:09:39 -0000

I'm getting errors looking at the ticket. Hopefully that's temporary. =
But I do not object in principle.

On Mar 26, 2014, at 10:59 AM, Steve Donovan  =
wrote:

> Ben,
>=20
> I took the liberty to close this issue for you based on your suggested =
wording.  If you disagree please re-open.
>=20
> Regards,
>=20
> Steve
>=20
> On 3/26/14 10:54 AM, dime issue tracker wrote:
>> #46: Bad normative advice on not letting overload reports expire
>>=20
>> Changes (by=20
>> srdonovan@usdonovans.com
>> ):
>>=20
>>  * status:  new =3D> closed
>>  * resolution:   =3D> fixed
>>=20
>>=20
>>=20
>=20


From nobody Wed Mar 26 10:17:24 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 773C51A01AF for ; Wed, 26 Mar 2014 10:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.561
X-Spam-Level: **
X-Spam-Status: No, score=2.561 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, 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 kEbGE7bEaw0K for ; Wed, 26 Mar 2014 10:17:20 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 159DE1A0182 for ; Wed, 26 Mar 2014 10:17:20 -0700 (PDT)
Received: from [137.254.4.56] (port=40630 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WSrRv-0004Wn-Mp for dime@ietf.org; Wed, 26 Mar 2014 10:17:17 -0700
Message-ID: <53330BAC.8010301@usdonovans.com>
Date: Wed, 26 Mar 2014 12:17:32 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070602050807070806040601"
X-OutGoing-Spam-Status: No, score=-1.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/BZLx1Gp3YFWxvZW7VwjlDiU11Qk
Subject: [Dime] New snapshot of -02 draft
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: Wed, 26 Mar 2014 17:17:21 -0000

This is a multi-part message in MIME format.
--------------070602050807070806040601
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

I have put a new snapshot of the -02 draft on the github server.

https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-02.txt

This shapshot adds updates for issues 36, 44, 46, 54 and 56.  This
brings the total number of issues resolved with updates to the -02 draft
to 17 plus three that were considered duplicates and two that were
closed with no change.

We still have a chance to get the following issues resolved:

#31 - Ulrich proposed wording that I will include in the next snapshot
unless someone objects soon.

#40 - This is suggested wording for a couple of definitions.  I'll take
the liberty to add these definitions and if I get them wrong we can
address it in -03

#43 - Ben suggested wording that I will include in the next snapshot
unless someone objects soon.

#48 - This deals with the m-bit.  I think we have consensus that there
needs to be wording saying that the m-bit should not be set but we don't
have detailed wording suggested.  If someone can come up with that
wording, I'm more than happy to include it in the next snapshot.

#49 - This deals with capability exchange.  We might already have all of
the wording changes resulting from other issues.  For instance, one of
the resolutions was that the scope of a capability announcement is a
single transaction.  I will look to see if I think this is already
resolved and come back with a recommendation.  I encourage others to do
so as well.

The following issues are tied into the ongoing discussion on Realm and RRR:

23, 55, 57 and 58.  I'll make changes if we come to consensus. 

This leaves the following for after -02 is published.

#25 - End point definition
#26, 27, 60, 61 - Agent behavior definition  (depends on #26)
#61 - Clean up of overview

Regards,

Steve

--------------070602050807070806040601
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      I have put a new snapshot of the -02 draft on the github server.

    

        https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-02.txt

      

      This shapshot adds updates for issues 36, 44, 46, 54 and 56.  This
      brings the total number of issues resolved with updates to the -02
      draft to 17 plus three that were considered duplicates and two
      that were closed with no change.

      

      We still have a chance to get the following issues resolved:

      

      #31 - Ulrich proposed wording that I will include in the next
      snapshot unless someone objects soon.

      

      #40 - This is suggested wording for a couple of definitions.  I'll
      take the liberty to add these definitions and if I get them wrong
      we can address it in -03

      

      #43 - Ben suggested wording that I will include in the next
      snapshot unless someone objects soon.

      

      #48 - This deals with the m-bit.  I think we have consensus that
      there needs to be wording saying that the m-bit should not be set
      but we don't have detailed wording suggested.  If someone can come
      up with that wording, I'm more than happy to include it in the
      next snapshot.

      

      #49 - This deals with capability exchange.  We might already have
      all of the wording changes resulting from other issues.  For
      instance, one of the resolutions was that the scope of a
      capability announcement is a single transaction.  I will look to
      see if I think this is already resolved and come back with a
      recommendation.  I encourage others to do so as well.

      

      The following issues are tied into the ongoing discussion on Realm
      and RRR:

      

      23, 55, 57 and 58.  I'll make changes if we come to consensus.  

      

      This leaves the following for after -02 is published.

      

      #25 - End point definition

      #26, 27, 60, 61 - Agent behavior definition  (depends on #26)

      #61 - Clean up of overview

      

      Regards,

      

      Steve

    
  


--------------070602050807070806040601--


From nobody Wed Mar 26 10:38:39 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 A821F1A01D1 for ; Wed, 26 Mar 2014 10:38:37 -0700 (PDT)
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 qS6EuF3QZvma for ; Wed, 26 Mar 2014 10:38:34 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 51A3C1A01BB for ; Wed, 26 Mar 2014 10:38:34 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2CAC022C212; Wed, 26 Mar 2014 18:38:32 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 11E124C077; Wed, 26 Mar 2014 18:38:32 +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; Wed, 26 Mar 2014 18:38:31 +0100
From: 
To: Jouni Korhonen , "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
Thread-Topic: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
Thread-Index: AQHPRS04KOSqmQRXnkGiudwjLzokJ5rrz/GAgACDK4CAADMOgIADlj+AgAFK/ICAAEuugIAB9caA
Date: Wed, 26 Mar 2014 17:38:30 +0000
Message-ID: <5026_1395855512_53331098_5026_6736_1_6B7134B31289DC4FAF731D844122B36E51EAB1@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>   <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com> <53302397.7020006@usdonovans.com>  <98C36821-0110-4A8C-9CFB-FDC2C1D88768@gmail.com>
In-Reply-To: <98C36821-0110-4A8C-9CFB-FDC2C1D88768@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
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.26.121816
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/AT7XM_NMLqnYF9soHeU6rCTMuQ8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
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: Wed, 26 Mar 2014 17:38:37 -0000

In another word, I don't see something specific to say in this draft.
The M-bit setting is something that any diameter application should take ca=
re when extending an existing application or creating a new one. It is not =
tied to the overload control mechanism itself.

Regards,

Lionel

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Jouni Korhonen
Envoy=E9=A0: mardi 25 mars 2014 13:38
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics


Hi,

On Mar 25, 2014, at 10:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:

> Hi
>=20=20
> Effectively we should be cautious with M bit for AVPS inside a grouped AV=
P such as OC-OLR AVP, and as Ben proposed, I am also rather in favour of no=
t using the Mbit inside a DOC group AVP, including application specific AVP=
s.
>=20=20
> In the thread discussion it  was mentioned the use of OC-feature and  als=
o relay node that is application  independent.
>=20=20
> Hereafter my  case:
>=20=20
> After our IETF draft having become a RFC, IETF standardizes an extension,=
  which adds a new flag in OC-feature AVP. This extension is not specific t=
o a Diameter application
> -          A  relay oonly supporting our IETF draft, will observe that OC=
-feature value does not fit to what it knows. I expect here that relay will=
 do nothing about DOC as the meaning of the OC-OLR may be different of what=
 it knows. OK? I als othink it applies to a proxy DA

I would expect the behaviour be like this.. otherwise there will be issues.

> -          If the relay supports the extension, it will recognize  the OC=
-feature value and will behave according this value. So OK. Should we have =
some text in the IETF draft?

By default relays should not even look into DOIC stuff.. since relays are o=
nly supposed to route requests. But we cannot prohibit some relay implement=
ations doing "enhanced" processing on requests. For that part I think there=
 is no need to say anything.

>=20=20
> Now, this is a Diameter  application (eg a 3GPP one) that will define an =
extension for its own use . Is this application is allowed to use bits of O=
C-Features AVP to indicate this application specific feature (or even algor=
ithm). How to avoid the application to use the same bits as future IETF ext=
ensions? Will we be driven to use=20

If you define a new application, you are still supposed to register your fe=
ature bits. Otherwise, there will be a mess. I see no reason why someone wo=
uld like to go this road other than for the pleasure of having incompatibil=
ity issues to fight with..

> another OC-Application-Specific-Feature AVP, or have bits  in OC-Feature =
reserved for application specific extensions., or other?  A constraint is t=
hat  a relay (application unaware) should nevertheless  detect there is app=
lication specific extensions (without knowing their meaning) so to not do D=
OC actions.=20=20

The process of registering a new feature flag is made so easy with IANA tha=
t there should not be a reason not to do so. Feature flags are not applicat=
ion specific per se, or that is how its use was designed to begin with. The=
y could be but then relays definitely should not look into those..


>=20=20
> I understand this is not directly linked to our immediate scope, but we m=
ay try  to be future proof allowing application specific extensions and Rel=
ay node supporting the generic DOC.

If you want to be on the safe ground, you do these things with proxies.

>=20=20
> Do you agree on this potential issue? If yes may be to analyse what to ad=
d in the IETF draft to be future proof.

I agree there will be issues if someone deliberately starts doing weird stu=
ff with relays and also fooling around with feature flags.. We are already =
on the edge with feature flags in general, since they allow adding new func=
tionality to applications without doing how Diameter was designed to do tha=
t - getting a new application-id.

- Jouni


>=20=20
> Best regards
>=20=20
> JJacques=20=20
>=20=20=20
>=20=20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
> Envoy=E9 : lundi 24 mars 2014 13:23
> =C0 : dime@ietf.org
> Objet : Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics
>=20=20
> Do we have proposed wording to be included in the -02 version of the draf=
t on this issue?
>=20
> Steve
>=20
> On 3/22/14 12:36 AM, Ben Campbell wrote:
>=20=20
> On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  wrot=
e:
>=20=20
>=20=20
> Ben,
>=20=20
> On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:
>=20=20
>=20=20
> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  wro=
te:
>=20=20
>=20=20
> Consider the case of a Diameter _relay_ that supports DOIC. It is not awa=
re of any application-specific rules about m-bits. It receives an OC-Suppor=
ted-Features or an OC-OLR that has a mandatory AVP that it doesn't recogniz=
e. Logically, it should probably ignore the entire OC-Supported-Features or=
 OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject =
the message. Rather it's likely to try to apply the OC-Supported-Features o=
r OC-OLR incorrectly.
>=20=20
> RFC6733 also says that relays perform not do any application level
> processing. If a relay supports DOIC and does something goofy that
> is left for implementation, we should no care nor try to fix the
> situation. The implementation is already bending the rules in that
> case.
>=20=20
> Hi Jouni,
>=20=20
> I'm not talking about the case of the relay doing something goofy. Rather=
, I mean when a relay tries to perform basic DOIC processing of an OLR as d=
escribed in the base DOIC spec, but ignores some extension AVP that changes=
 the meaning of the OLR. It's not bending the rules so much as failing to r=
ecognize someone else changing the rules.
>=20=20
> Ah, I see your point. But if one adds AVPs to the default algorithm
> that change he behaviour and does not a) declare it as a new algorithm
> or b) add a new supported feature flag, then that is a proprietary
> (broken) implementation. We cannot really protect against those..
>=20=20
> I think that's reasonable. My original point was that extensions should n=
ot try to use the m-bit for that purpose. If they have something that is no=
t backwards compatible, it needs to be negotiated in the feature vector.
>=20=20
>=20=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20=20
>=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 Wed Mar 26 11:35: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 8CF2C1A0388 for ; Wed, 26 Mar 2014 11:35:07 -0700 (PDT)
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 E-MvOB_uXUw9 for ; Wed, 26 Mar 2014 11:35:04 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 792721A036F for ; Wed, 26 Mar 2014 11:35:01 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2QIYvhH013161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Mar 2014 13:34:59 -0500 (CDT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2QIYtKH010259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Mar 2014 19:34:55 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 19:34:55 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: Jouni Korhonen 
Thread-Topic: [Dime] OC-Supported features and application specific flags 
Thread-Index: AQHPSSIUS7l3Hdh/PEWe0bq9qK7pLg==
Date: Wed, 26 Mar 2014 18:34:54 +0000
Message-ID: 
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>   <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com> <53302397.7020006@usdonovans.com>  <98C36821-0110-4A8C-9CFB-FDC2C1D88768@gmail.com>
In-Reply-To: <98C36821-0110-4A8C-9CFB-FDC2C1D88768@gmail.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.40]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/jNAPrWvNU9rMLhWMyNd7UKWhR9M
Cc: "dime@ietf.org" 
Subject: [Dime]  OC-Supported features and application specific flags
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: Wed, 26 Mar 2014 18:35:07 -0000

Hi Jouni

Thanks for your detailed answers about my questioning regarding the OC-feat=
ures AVP  (I propose  to do another thread as not related to #48)=20

About relays, I have not asked for relay to support DOIC, but Ben several t=
imes mentioned the relays that may act as a DOIC node . So I try to see con=
sequences of this assuimption. From you answer, I think it should be clarif=
ied.

Then there are my questions about an application introducing new features, =
your answer is that new flags in the OC-features AVP must be declared to IA=
NA. OK for this; I would think it should be written in the draft?=20
Have we other possibilities: I think that in the OC-features AVP a part of =
the bit mask could be "common" meaning anew flag added in this part is decl=
ared to IANA. Another part is fully specific to an application, which is co=
mpatible with the fact that an OC-feature AVP (and its content) when sent  =
is always associated to a specific application. Other possibilities?

I currently have no religion on the way to do, only to have a way on how an=
 application can add new feature bits without creating issues, and this way=
 described in the draft.=20

In 3GPP, there is the Supported-Features AVP of which the whole bit mask co=
ntent  is fully specific to a Diameter application and this OK. This AVP ma=
y be understood by a Proxy DA application aware.

Best regards

JJacques=20


 =20

-----Message d'origine-----
De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Envoy=E9=A0: mardi 25 mars 2014 13:38
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics


Hi,

On Mar 25, 2014, at 10:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:

> Hi
> =20
> Effectively we should be cautious with M bit for AVPS inside a grouped AV=
P such as OC-OLR AVP, and as Ben proposed, I am also rather in favour of no=
t using the Mbit inside a DOC group AVP, including application specific AVP=
s.
> =20
> In the thread discussion it  was mentioned the use of OC-feature and  als=
o relay node that is application  independent.
> =20
> Hereafter my  case:
> =20
> After our IETF draft having become a RFC, IETF standardizes an extension,=
  which adds a new flag in OC-feature AVP. This extension is not specific t=
o a Diameter application
> -          A  relay oonly supporting our IETF draft, will observe that OC=
-feature value does not fit to what it knows. I expect here that relay will=
 do nothing about DOC as the meaning of the OC-OLR may be different of what=
 it knows. OK? I als othink it applies to a proxy DA

I would expect the behaviour be like this.. otherwise there will be issues.

> -          If the relay supports the extension, it will recognize  the OC=
-feature value and will behave according this value. So OK. Should we have =
some text in the IETF draft?

By default relays should not even look into DOIC stuff.. since relays are o=
nly supposed to route requests. But we cannot prohibit some relay implement=
ations doing "enhanced" processing on requests. For that part I think there=
 is no need to say anything.

> =20
> Now, this is a Diameter  application (eg a 3GPP one) that will define=20
> an extension for its own use . Is this application is allowed to use=20
> bits of OC-Features AVP to indicate this application specific feature=20
> (or even algorithm). How to avoid the application to use the same bits=20
> as future IETF extensions? Will we be driven to use

If you define a new application, you are still supposed to register your fe=
ature bits. Otherwise, there will be a mess. I see no reason why someone wo=
uld like to go this road other than for the pleasure of having incompatibil=
ity issues to fight with..

> another OC-Application-Specific-Feature AVP, or have bits  in OC-Feature =
reserved for application specific extensions., or other?  A constraint is t=
hat  a relay (application unaware) should nevertheless  detect there is app=
lication specific extensions (without knowing their meaning) so to not do D=
OC actions. =20

The process of registering a new feature flag is made so easy with IANA tha=
t there should not be a reason not to do so. Feature flags are not applicat=
ion specific per se, or that is how its use was designed to begin with. The=
y could be but then relays definitely should not look into those..


> =20
> I understand this is not directly linked to our immediate scope, but we m=
ay try  to be future proof allowing application specific extensions and Rel=
ay node supporting the generic DOC.

If you want to be on the safe ground, you do these things with proxies.

> =20
> Do you agree on this potential issue? If yes may be to analyse what to ad=
d in the IETF draft to be future proof.

I agree there will be issues if someone deliberately starts doing weird stu=
ff with relays and also fooling around with feature flags.. We are already =
on the edge with feature flags in general, since they allow adding new func=
tionality to applications without doing how Diameter was designed to do tha=
t - getting a new application-id.

- Jouni


> =20
> Best regards
> =20
> JJacques
>  =20
> =20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
> Envoy=E9 : lundi 24 mars 2014 13:23 =C0 : dime@ietf.org Objet : Re: [Dime=
]=20
> [dime] #48: Setting M-Bit gives wrong semantics
> =20
> Do we have proposed wording to be included in the -02 version of the draf=
t on this issue?
>=20
> Steve
>=20
> On 3/22/14 12:36 AM, Ben Campbell wrote:
> =20
> On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  wrot=
e:
> =20
> =20
> Ben,
> =20
> On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:
> =20
> =20
> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  wro=
te:
> =20
> =20
> Consider the case of a Diameter _relay_ that supports DOIC. It is not awa=
re of any application-specific rules about m-bits. It receives an OC-Suppor=
ted-Features or an OC-OLR that has a mandatory AVP that it doesn't recogniz=
e. Logically, it should probably ignore the entire OC-Supported-Features or=
 OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject =
the message. Rather it's likely to try to apply the OC-Supported-Features o=
r OC-OLR incorrectly.
> =20
> RFC6733 also says that relays perform not do any application level=20
> processing. If a relay supports DOIC and does something goofy that is=20
> left for implementation, we should no care nor try to fix the=20
> situation. The implementation is already bending the rules in that=20
> case.
> =20
> Hi Jouni,
> =20
> I'm not talking about the case of the relay doing something goofy. Rather=
, I mean when a relay tries to perform basic DOIC processing of an OLR as d=
escribed in the base DOIC spec, but ignores some extension AVP that changes=
 the meaning of the OLR. It's not bending the rules so much as failing to r=
ecognize someone else changing the rules.
> =20
> Ah, I see your point. But if one adds AVPs to the default algorithm=20
> that change he behaviour and does not a) declare it as a new algorithm=20
> or b) add a new supported feature flag, then that is a proprietary
> (broken) implementation. We cannot really protect against those..
> =20
> I think that's reasonable. My original point was that extensions should n=
ot try to use the m-bit for that purpose. If they have something that is no=
t backwards compatible, it needs to be negotiated in the feature vector.
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
> =20
> =20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


From nobody Wed Mar 26 12:10:03 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 352A41A03BB for ; Wed, 26 Mar 2014 12:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Level: 
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] 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 gVbJ-LfcNESg for ; Wed, 26 Mar 2014 12:09:56 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id DDD8F1A0354 for ; Wed, 26 Mar 2014 12:09:55 -0700 (PDT)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 835D122C452; Wed, 26 Mar 2014 20:09:53 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6664D35C099; Wed, 26 Mar 2014 20:09:53 +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; Wed, 26 Mar 2014 20:09:52 +0100
From: 
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" , Jouni Korhonen 
Thread-Topic: [Dime]  OC-Supported features and application specific flags
Thread-Index: AQHPSSIUS7l3Hdh/PEWe0bq9qK7pLprzszZA
Date: Wed, 26 Mar 2014 19:09:51 +0000
Message-ID: <25922_1395860993_53332601_25922_7432_1_6B7134B31289DC4FAF731D844122B36E51ED3E@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.cca16f1268987a869c0055728f3d7793@trac.tools.ietf.org> <752FBBF3-DF13-4BCC-A613-E61D00038E2E@nostrum.com> <6A4050BC-908A-439C-BF41-2992CF0F58B6@gmail.com>   <512F9D8C-BE9B-4365-8D89-402AC0A81D99@nostrum.com> <53302397.7020006@usdonovans.com>  <98C36821-0110-4A8C-9CFB-FDC2C1D88768@gmail.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.4]
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.26.121816
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/WNSVgGCSGPyIYuy-njeJbigpAtY
Cc: "dime@ietf.org" 
Subject: Re: [Dime] OC-Supported features and application specific flags
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: Wed, 26 Mar 2014 19:09:59 -0000

Hi JJ,

Relay is just a relay and application-agnostic. Overload control is designe=
d to be used only on top of applications, not at the base level.
Everything done below the application level is then implementation specific.

As soon as there is a registry in IANA in which you can safely declare any =
new mechanism, the OC-Feature-Vector AVP is the mechanism to know what to d=
o with the received OLR (when speaking about the generic solution). The Sup=
ported-Features AVP defined in 3GPP is another way. And to be able to under=
stand these AVP, you will have to be at the application level in any case.

Regards,

Lionel=20
=20
-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de TROTTIN, JEAN-JACQ=
UES (JEAN-JACQUES)
Envoy=E9=A0: mercredi 26 mars 2014 19:35
=C0=A0: Jouni Korhonen
Cc=A0: dime@ietf.org
Objet=A0: [Dime] OC-Supported features and application specific flags

Hi Jouni

Thanks for your detailed answers about my questioning regarding the OC-feat=
ures AVP  (I propose  to do another thread as not related to #48)=20

About relays, I have not asked for relay to support DOIC, but Ben several t=
imes mentioned the relays that may act as a DOIC node . So I try to see con=
sequences of this assuimption. From you answer, I think it should be clarif=
ied.

Then there are my questions about an application introducing new features, =
your answer is that new flags in the OC-features AVP must be declared to IA=
NA. OK for this; I would think it should be written in the draft?=20
Have we other possibilities: I think that in the OC-features AVP a part of =
the bit mask could be "common" meaning anew flag added in this part is decl=
ared to IANA. Another part is fully specific to an application, which is co=
mpatible with the fact that an OC-feature AVP (and its content) when sent  =
is always associated to a specific application. Other possibilities?

I currently have no religion on the way to do, only to have a way on how an=
 application can add new feature bits without creating issues, and this way=
 described in the draft.=20

In 3GPP, there is the Supported-Features AVP of which the whole bit mask co=
ntent  is fully specific to a Diameter application and this OK. This AVP ma=
y be understood by a Proxy DA application aware.

Best regards

JJacques=20


=20=20

-----Message d'origine-----
De=A0: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20
Envoy=E9=A0: mardi 25 mars 2014 13:38
=C0=A0: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Cc=A0: dime@ietf.org
Objet=A0: Re: [Dime] [dime] #48: Setting M-Bit gives wrong semantics


Hi,

On Mar 25, 2014, at 10:07 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:

> Hi
>=20=20
> Effectively we should be cautious with M bit for AVPS inside a grouped AV=
P such as OC-OLR AVP, and as Ben proposed, I am also rather in favour of no=
t using the Mbit inside a DOC group AVP, including application specific AVP=
s.
>=20=20
> In the thread discussion it  was mentioned the use of OC-feature and  als=
o relay node that is application  independent.
>=20=20
> Hereafter my  case:
>=20=20
> After our IETF draft having become a RFC, IETF standardizes an extension,=
  which adds a new flag in OC-feature AVP. This extension is not specific t=
o a Diameter application
> -          A  relay oonly supporting our IETF draft, will observe that OC=
-feature value does not fit to what it knows. I expect here that relay will=
 do nothing about DOC as the meaning of the OC-OLR may be different of what=
 it knows. OK? I als othink it applies to a proxy DA

I would expect the behaviour be like this.. otherwise there will be issues.

> -          If the relay supports the extension, it will recognize  the OC=
-feature value and will behave according this value. So OK. Should we have =
some text in the IETF draft?

By default relays should not even look into DOIC stuff.. since relays are o=
nly supposed to route requests. But we cannot prohibit some relay implement=
ations doing "enhanced" processing on requests. For that part I think there=
 is no need to say anything.

>=20=20
> Now, this is a Diameter  application (eg a 3GPP one) that will define=20
> an extension for its own use . Is this application is allowed to use=20
> bits of OC-Features AVP to indicate this application specific feature=20
> (or even algorithm). How to avoid the application to use the same bits=20
> as future IETF extensions? Will we be driven to use

If you define a new application, you are still supposed to register your fe=
ature bits. Otherwise, there will be a mess. I see no reason why someone wo=
uld like to go this road other than for the pleasure of having incompatibil=
ity issues to fight with..

> another OC-Application-Specific-Feature AVP, or have bits  in OC-Feature =
reserved for application specific extensions., or other?  A constraint is t=
hat  a relay (application unaware) should nevertheless  detect there is app=
lication specific extensions (without knowing their meaning) so to not do D=
OC actions.=20=20

The process of registering a new feature flag is made so easy with IANA tha=
t there should not be a reason not to do so. Feature flags are not applicat=
ion specific per se, or that is how its use was designed to begin with. The=
y could be but then relays definitely should not look into those..


>=20=20
> I understand this is not directly linked to our immediate scope, but we m=
ay try  to be future proof allowing application specific extensions and Rel=
ay node supporting the generic DOC.

If you want to be on the safe ground, you do these things with proxies.

>=20=20
> Do you agree on this potential issue? If yes may be to analyse what to ad=
d in the IETF draft to be future proof.

I agree there will be issues if someone deliberately starts doing weird stu=
ff with relays and also fooling around with feature flags.. We are already =
on the edge with feature flags in general, since they allow adding new func=
tionality to applications without doing how Diameter was designed to do tha=
t - getting a new application-id.

- Jouni


>=20=20
> Best regards
>=20=20
> JJacques
>=20=20=20
>=20=20
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan=20
> Envoy=E9 : lundi 24 mars 2014 13:23 =C0 : dime@ietf.org Objet : Re: [Dime=
]=20
> [dime] #48: Setting M-Bit gives wrong semantics
>=20=20
> Do we have proposed wording to be included in the -02 version of the draf=
t on this issue?
>=20
> Steve
>=20
> On 3/22/14 12:36 AM, Ben Campbell wrote:
>=20=20
> On Mar 21, 2014, at 9:33 PM, Jouni Korhonen  wrot=
e:
>=20=20
>=20=20
> Ben,
>=20=20
> On Mar 22, 2014, at 2:44 AM, Ben Campbell  wrote:
>=20=20
>=20=20
> On Mar 21, 2014, at 12:43 PM, Jouni Korhonen  wro=
te:
>=20=20
>=20=20
> Consider the case of a Diameter _relay_ that supports DOIC. It is not awa=
re of any application-specific rules about m-bits. It receives an OC-Suppor=
ted-Features or an OC-OLR that has a mandatory AVP that it doesn't recogniz=
e. Logically, it should probably ignore the entire OC-Supported-Features or=
 OC-OLR grouped-AVP. But it won't. Being a relay, it's not going to reject =
the message. Rather it's likely to try to apply the OC-Supported-Features o=
r OC-OLR incorrectly.
>=20=20
> RFC6733 also says that relays perform not do any application level=20
> processing. If a relay supports DOIC and does something goofy that is=20
> left for implementation, we should no care nor try to fix the=20
> situation. The implementation is already bending the rules in that=20
> case.
>=20=20
> Hi Jouni,
>=20=20
> I'm not talking about the case of the relay doing something goofy. Rather=
, I mean when a relay tries to perform basic DOIC processing of an OLR as d=
escribed in the base DOIC spec, but ignores some extension AVP that changes=
 the meaning of the OLR. It's not bending the rules so much as failing to r=
ecognize someone else changing the rules.
>=20=20
> Ah, I see your point. But if one adds AVPs to the default algorithm=20
> that change he behaviour and does not a) declare it as a new algorithm=20
> or b) add a new supported feature flag, then that is a proprietary
> (broken) implementation. We cannot really protect against those..
>=20=20
> I think that's reasonable. My original point was that extensions should n=
ot try to use the m-bit for that purpose. If they have something that is no=
t backwards compatible, it needs to be negotiated in the feature vector.
>=20=20
>=20=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>=20=20
>=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 Wed Mar 26 23:38:46 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 B9F371A0208 for ; Wed, 26 Mar 2014 23:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xrkJqEfuieGE for ; Wed, 26 Mar 2014 23:38:34 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C45971A046A for ; Wed, 26 Mar 2014 23:38:32 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEZ40871; Thu, 27 Mar 2014 06:38:28 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 06:37:17 +0000
Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 06:37:43 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Thu, 27 Mar 2014 14:37:35 +0800
From: "Shishufeng (Susan)" 
To: "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeA=
Date: Thu, 27 Mar 2014 06:37:34 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3ED23SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5EstqYreQgwfCowV1KV8N1z-rNk
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 06:38:45 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3ED23SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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_26C84DFD55BC3040A45BF70926E55F2587C3ED23SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Lionel,=



 =
;


If you car=
es, please clarify how this decision was made based on the newly ongoing te=
chnical discussion. I really don’t understand a useless AVP
 in most cases has to be mandatory.


 =
;


May I ask =
why not define every optional AVP as mandatory if the only point you made d=
ecision was that it will not block anything?


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi,


 =
;


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.


To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.<=
/p>

Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 =
;


Regards,


 =
;


Lionel


 =
;


 =
;






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-     &=
nbsp;   
Fi=
rst a not always needed AVP cannot justify why it shall be mandatory.




-     &=
nbsp;   
Se=
condly, in my view, having a not always needed AVP as mandatory cannot be l=
ess error prone. On the contrary, it would introduce more
 error cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSIN=
G_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with t=
he possible error cases. All the handling with this AVP consumes the resour=
ce of both reporting nodes and reacting
 nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.<=
o:p>


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



As chair and temporary doc shepherd,=



 <=
/span>


Please stop this thread for now.


 <=
/span>


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 <=
/span>


Lionel =



 <=
/span>


 <=
/span>


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 <=
/span>






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. =



 


Best Regards,

Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] <=
/span>


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan<=
/pre>

Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 


If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?=



 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.<=
/o:p>


 


I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen=



Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 


I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
span lang=3D"FR">


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de =



lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 

[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,

 


I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?

 


So instead of:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


You would prefer:<=
/pre>

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue =



tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP=



 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 


This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 


--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz

  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new

Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>

 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_____________________________________________________________=
________


____________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


 




 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 =





 =







_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


________________________________________________________________=
_________________________________________________________


 


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.

 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;<=
o:p>


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.




 =



____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3ED23SZXEMA512MBXchi_--


From nobody Thu Mar 27 02:31:34 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 3DB371A04AB for ; Thu, 27 Mar 2014 02:31:32 -0700 (PDT)
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 hk8oXYP2VU1i for ; Thu, 27 Mar 2014 02:31:21 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id C24271A04AE for ; Thu, 27 Mar 2014 02:31:19 -0700 (PDT)
Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 210993B428B; Thu, 27 Mar 2014 10:31:17 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id E5FE11580AE; Thu, 27 Mar 2014 10:31:16 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 27 Mar 2014 10:31:16 +0100
From: 
To: "Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQNKav1Yd2xqUyLNClmxsrsL5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeD//Jsx8A==
Date: Thu, 27 Mar 2014 09:31:15 +0000
Message-ID: <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E520AC9PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.233016
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/5483spk6_wr-ggJxKUUjrUK0Gg8
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 09:31:32 -0000

--_000_6B7134B31289DC4FAF731D844122B36E520AC9PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E520AC9PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Susan,


 <=
/p>

In this sp=
ecific case, the info carried by the AVP is not optional. You need this inf=
o in the algorithm as it will modify the behavior of the reacting
 node.


The curren=
t solution is to define a default value when not received.


 =
;


I believe =
that at the protocol level, having this AVP in every request is cleaner tha=
n relying on default value when not present. The initial goal
 for such default value was to limit the number of AVPs transmitted over th=
e interfaces. And I think that it is not so relevant according to the outpu=
t of the other discussions and such optimization is not deemed required any=
more.



 =
;


Moreover, =
the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used
 in some networks, Realm is perfectly valid as default value if the system =
is designed for that. I think that AT&T and Verizon have clearly expres=
sed their requirements for that.


 =
;


This reaso=
ning leads to change the existing for Grouped AVP from:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


To:


 =
;


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =
;


I would li=
ke to clarify that this discussion is totally independent of the M-bit sett=
ing of the AVP.


 =
;


And about =
why not put the other AVPs as required in the Grouped AVP, it is because it=
 is abvious that the other ones are linked to the reduction
 algo defined in this document. For other algos, you could find other AVPs =
(relying on the extensibility of this Grouped AVP) instead.


 =
;


Let me kno=
w if the clarification is useful.


 =
;


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@h=
uawei.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,=



 


If you car=
es, please clarify how this decision was made based on the newly ongoing te=
chnical discussion. I really don’t understand a useless AVP
 in most cases has to be mandatory.


 


May I ask =
why not define every optional AVP as mandatory if the only point you made d=
ecision was that it will not block anything?


 


Best Regar=
ds,


Susan


 






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi,=



 


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.


To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.<=
/p>

Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 


Regards,


 


Lionel


 


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-       &nb=
sp; 
First a not always needed AVP cannot justify why it =
shall be mandatory.




-       &nb=
sp; 
Secondly, in my view, having a not always needed AVP=
 as mandatory cannot be less error prone. On the contrary,
 it would introduce more error cases. RFC 6733 defines a couple of error co=
des e.g. DIAMETER_MISSING_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and may=
be others to deal with the possible error cases. All the handling with this=
 AVP consumes the resource of both
 reporting nodes and reacting nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,=



 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/o:p>




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 =



From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:<=
/pre>

 =



Hi,


 =



How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 =



If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 =



Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?


 =



- Jouni


 =



 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 =



 


Hello all,


 =



I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 =



I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 =



Best regards


/MCruz


 =



-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13<=
/pre>

To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 =



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 =



I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 =



- Jouni


 =



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 =



Hi Mcruz


 =



The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
o:p>


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 =



Best regards


 =



JJacques


 =



 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 


lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



Hi Maria Cruz,


 =



I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?


 =



So instead of:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



You would prefer:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



And I'm fine with this proposal.


 =



Cheers,


 =



Lionel


 =



-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



#54: OC-Report-Type as mandatory AVP


 =



Now in chapter 4.6:


 =



 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 =



This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 =



--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz


  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new


Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 =



Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>


 =



_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 =



_____________________________________________________________=
________


____________________________________________________


 =



Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 =



This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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


 =



 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 




 






_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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.




 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 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_6B7134B31289DC4FAF731D844122B36E520AC9PEXCVZYM13corpora_--


From nobody Thu Mar 27 03:32: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 300F41A0601 for ; Thu, 27 Mar 2014 03:32:44 -0700 (PDT)
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 Rj_oJ85sApEY for ; Thu, 27 Mar 2014 03:32:31 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 865E61A05E5 for ; Thu, 27 Mar 2014 03:32:30 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 56A153B4214; Thu, 27 Mar 2014 11:32:28 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E51BF4C06C; Thu, 27 Mar 2014 11:32:27 +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; Thu, 27 Mar 2014 11:32:27 +0100
From: 
To: "Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQNKav1Yd2xqUyLNClmxsrsL5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeD//Jsx8ADZeeeA///qNtA=
Date: Thu, 27 Mar 2014 10:32:27 +0000
Message-ID: <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E520C95PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.27.24215
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/RIDu0k3Xltt63pScXnF7g3qG41w
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 10:32:44 -0000

--_000_6B7134B31289DC4FAF731D844122B36E520C95PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Susan,

Please see below.

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,


-          I'm not talking the specific optional AVPs defined in this draft=
, but others e.g. defined in 3GPP specifications. We have a lot optional AV=
Ps with default values.
[LM] in 3GPP there are introduced in existing applications and usually in c=
ommands. There is no other options to include them are purely optional.


-           my understanding, some cases an AVP is needed, some cases it is=
 not needed, that's the key point to justify its optionality.
[LM] I agree that we don't have the same understanding here.


-          Apart from the benefit of less AVPs and less error cases with th=
is AVP as optional, another key point is that the server(host) will never c=
are about the AVP at all. It will never need to remember to put such an AVP=
 into the message. Only agent needs to add such an AVP in case putting into=
 realm report, this would make things much simpler from my point of view.
[LM] that is wrong to say "never". A server can have realm-based informatio=
n that can be provided to reacting nodes. It is only depending of the serve=
r implementation and environment. For instance, if a realm is entirely dedi=
cated to a type of server, a farm based implementation would provide such f=
unctionality, as discussed.

Further, the discussion on Realm is still ongoing and whether it can work w=
ell is still under investigation.
[LM] I think that the ongoing discussion is too tight to specific use cases=
, important ones for 3GPP I admit. However the whole goal of this work is t=
o have something that it will work in any case. If there are some requireme=
nts for realm-based info, I don't see a specific reason to restrict the use=
 of report type. And don't forget that new report types can be created in t=
he future. So it is not restricted to Host vs realm.

The benefit to have it as optional is clear, and this would not bring any h=
arm. I hope this can be reconsidered.
[LM] let see if there are other voice that could not accept the proposed ap=
proach.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, March 27, 2014 5:31 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E520C95PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi Susan,


 <=
/p>

Please see below.


 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@h=
uawei.com]


Envoy=E9 : jeudi 27 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 =
;



-I’m not talking the specific optional AVPs def=
ined in this draft, but others e.g. defined in 3GPP specifications.
 We have a lot optional AVPs with default values. 


[LM]=
 in 3GPP there are introduced in existing applications and usually in comma=
nds. There is no other options to include them are purely
 optional.


 =
;



- my understanding, some cases an AVP is needed,=
 some cases it is not needed, that’s the key point to justify its
 optionality.


[LM]=
 I agree that we don't have the same understanding here.


 =
;



-Apart from the benefit of less AVPs and less error c=
ases with this AVP as optional, another key point is that
 the server(host) will never care about the AVP at all. It will never need =
to remember to put such an AVP into the message. Only agent needs to add su=
ch an AVP in case putting into realm report, this would make things much si=
mpler from my point of view.



[LM]=
 that is wrong to say "never". A server can have realm-based info=
rmation that can be provided to reacting nodes. It is only depending
 of the server implementation and environment. For instance, if a realm is =
entirely dedicated to a type of server, a farm based implementation would p=
rovide such functionality, as discussed.
=



 =
;


Further, t=
he discussion on Realm is still ongoing and whether it can work well is sti=
ll under investigation.


[LM]=
 I think that the ongoing discussion is too tight to specific use cases, im=
portant ones for 3GPP I admit. However the whole goal of this
 work is to have something that it will work in any case. If there are some=
 requirements for realm-based info, I don't see a specific reason to restri=
ct the use of report type. And don't forget that new report types can be cr=
eated in the future. So it is not
 restricted to Host vs realm.


 =
;


The benefi=
t to have it as optional is clear, and this would not bring any harm. I hop=
e this can be reconsidered.


[LM]=
 let see if there are other voice that could not accept the proposed approa=
ch.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Thursday, March 27, 2014 5:31 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 <=
/p>

In this sp=
ecific case, the info carried by the AVP is not optional. You need this inf=
o in the algorithm as it will modify the behavior of the reacting
 node.


The curren=
t solution is to define a default value when not received.


 =
;


I believe =
that at the protocol level, having this AVP in every request is cleaner tha=
n relying on default value when not present. The initial goal
 for such default value was to limit the number of AVPs transmitted over th=
e interfaces. And I think that it is not so relevant according to the outpu=
t of the other discussions and such optimization is not deemed required any=
more.



 =
;


Moreover, =
the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used
 in some networks, Realm is perfectly valid as default value if the system =
is designed for that. I think that AT&T and Verizon have clearly expres=
sed their requirements for that.


 =
;


This reaso=
ning leads to change the existing for Grouped AVP from:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


To:


 =
;


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =
;


I would li=
ke to clarify that this discussion is totally independent of the M-bit sett=
ing of the AVP.


 =
;


And about =
why not put the other AVPs as required in the Grouped AVP, it is because it=
 is abvious that the other ones are linked to the reduction
 algo defined in this document. For other algos, you could find other AVPs =
(relying on the extensibility of this Grouped AVP) instead.


 =
;


Let me kno=
w if the clarification is useful.


 =
;


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,=



 


If you car=
es, please clarify how this decision was made based on the newly ongoing te=
chnical discussion. I really don’t understand a useless AVP
 in most cases has to be mandatory.


 


May I ask =
why not define every optional AVP as mandatory if the only point you made d=
ecision was that it will not block anything?


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi,=



 


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.


To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.<=
/p>

Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 


Regards,


 


Lionel


 


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-       &nb=
sp; 
First a not always needed AVP cannot justify why it =
shall be mandatory.




-       &nb=
sp; 
Secondly, in my view, having a not always needed AVP=
 as mandatory cannot be less error prone. On the contrary,
 it would introduce more error cases. RFC 6733 defines a couple of error co=
des e.g. DIAMETER_MISSING_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and may=
be others to deal with the possible error cases. All the handling with this=
 AVP consumes the resource of both
 reporting nodes and reacting nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,=



 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/o:p>




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 =



From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:<=
/pre>

 =



Hi,


 =



How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 =



If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 =



Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?


 =



- Jouni


 =



 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 =



 


Hello all,


 =



I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 =



I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 =



Best regards


/MCruz


 =



-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13<=
/pre>

To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 =



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 =



I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 =



- Jouni


 =



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 =



Hi Mcruz


 =



The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
o:p>


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 =



Best regards


 =



JJacques


 =



 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 


lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



Hi Maria Cruz,


 =



I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?


 =



So instead of:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



You would prefer:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



And I'm fine with this proposal.


 =



Cheers,


 =



Lionel


 =



-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



#54: OC-Report-Type as mandatory AVP


 =



Now in chapter 4.6:


 =



 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 =



This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 =



--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz


  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new


Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 =



Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>


 =



_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 =



_____________________________________________________________=
________


____________________________________________________


 =



Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 =



This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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


 =



 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 




 






_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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.




 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 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_6B7134B31289DC4FAF731D844122B36E520C95PEXCVZYM13corpora_--


From nobody Thu Mar 27 04:01: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 2118F1A0647 for ; Thu, 27 Mar 2014 04:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 El1l7vQza-eC for ; Thu, 27 Mar 2014 04:00:31 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0781A064B for ; Thu, 27 Mar 2014 04:00:19 -0700 (PDT)
Received: from 172.18.7.232 (EHLO lhrrgout.huawei.com) ([172.18.7.232]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAN19137; Thu, 27 Mar 2014 05:50:21 -0500 (CDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEZ61572; Thu, 27 Mar 2014 10:04:08 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 10:03:25 +0000
Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 10:04:00 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Thu, 27 Mar 2014 18:03:52 +0800
From: "Shishufeng (Susan)" 
To: "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeCAAuiLgP//eGTw
Date: Thu, 27 Mar 2014 10:03:51 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3EEEFSZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JPrJ2jXnBmXtXPSP4xr7MN7DNl4
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 11:00:50 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3EEEFSZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Lionel,


-          I'm not talking the specific optional AVPs defined in this draft=
, but others e.g. defined in 3GPP specifications. We have a lot optional AV=
Ps with default values.


-           my understanding, some cases an AVP is needed, some cases it is=
 not needed, that's the key point to justify its optionality.


-          Apart from the benefit of less AVPs and less error cases with th=
is AVP as optional, another key point is that the server(host) will never c=
are about the AVP at all. It will never need to remember to put such an AVP=
 into the message. Only agent needs to add such an AVP in case putting into=
 realm report, this would make things much simpler from my point of view.

Further, the discussion on Realm is still ongoing and whether it can work w=
ell is still under investigation.

The benefit to have it as optional is clear, and this would not bring any h=
arm. I hope this can be reconsidered.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, March 27, 2014 5:31 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore=
.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_26C84DFD55BC3040A45BF70926E55F2587C3EEEFSZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Lion=
el,


 =
;



-I&=
#8217;m not talking the specific optional AVPs defined in this draft, but o=
thers e.g. defined in 3GPP specifications. We have a lot optional
 AVPs with default values. 


 =
;



-&n=
bsp;my understanding, some cases an AVP is needed, some cases it is not nee=
ded, that’s the key point to justify its optionality.


 =
;



-Ap=
art from the benefit of less AVPs and less error cases with this AVP as opt=
ional, another key point is that the server(host) will never
 care about the AVP at all. It will never need to remember to put such an A=
VP into the message. Only agent needs to add such an AVP in case putting in=
to realm report, this would make things much simpler from my point of view.



 =
;


Further, t=
he discussion on Realm is still ongoing and whether it can work well is sti=
ll under investigation.


 =
;


The benefi=
t to have it as optional is clear, and this would not bring any harm. I hop=
e this can be reconsidered.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Thursday, March 27, 2014 5:31 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


In this sp=
ecific case, the info carried by the AVP is not optional. You need this inf=
o in the algorithm as it will modify the behavior of the reacting
 node.


The curren=
t solution is to define a default value when not received.


 =
;


I believe =
that at the protocol level, having this AVP in every request is cleaner tha=
n relying on default value when not present. The initial goal
 for such default value was to limit the number of AVPs transmitted over th=
e interfaces. And I think that it is not so relevant according to the outpu=
t of the other discussions and such optimization is not deemed required any=
more.



 =
;


Moreover, =
the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used
 in some networks, Realm is perfectly valid as default value if the system =
is designed for that. I think that AT&T and Verizon have clearly expres=
sed their requirements for that.


 =
;


This reaso=
ning leads to change the existing for Grouped AVP from:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]

         * [ AVP ]


To:


 =
;


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]

         * [ AVP ]


 =
;


I would li=
ke to clarify that this discussion is totally independent of the M-bit sett=
ing of the AVP.


 =
;


And about =
why not put the other AVPs as required in the Grouped AVP, it is because it=
 is abvious that the other ones are linked to the reduction
 algo defined in this document. For other algos, you could find other AVPs =
(relying on the extensibility of this Grouped AVP) instead.


 =
;


Let me kno=
w if the clarification is useful.


 =
;


 =
;


Regards,


 =
;


Lionel


 =
;






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,=



 


If you car=
es, please clarify how this decision was made based on the newly ongoing te=
chnical discussion. I really don’t understand a useless AVP
 in most cases has to be mandatory.


 


May I ask =
why not define every optional AVP as mandatory if the only point you made d=
ecision was that it will not block anything?<=
/o:p>


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi,=



 


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.=



To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.


Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 


Regards,


 


Lionel


 


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-     &=
nbsp;   
Fi=
rst a not always needed AVP cannot justify why it shall be mandatory.




-     &=
nbsp;   
Se=
condly, in my view, having a not always needed AVP as mandatory cannot be l=
ess error prone. On the contrary, it would introduce more
 error cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSIN=
G_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with t=
he possible error cases. All the handling with this AVP consumes the resour=
ce of both reporting nodes and reacting
 nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.<=
o:p>


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



As chair and temporary doc shepherd,=



 <=
/span>


Please stop this thread for now.


 <=
/span>


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 <=
/span>


Lionel =



 <=
/span>


 <=
/span>


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 <=
/span>






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. =



 


Best Regards,

Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] <=
/span>


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan<=
/pre>

Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 


If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?=



 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.<=
/o:p>


 


I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen=



Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 


I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
span lang=3D"FR">


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de =



lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 

[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,

 


I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?

 


So instead of:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


You would prefer:<=
/pre>

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue =



tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP=



 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 


This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 


--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz

  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new

Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>

 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_____________________________________________________________=
________


____________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


 




 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 =





 =







_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


________________________________________________________________=
_________________________________________________________


 


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.

 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;<=
o:p>


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.




 =



____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3EEEFSZXEMA512MBXchi_--


From nobody Thu Mar 27 04:39:04 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 E1BF11A0644 for ; Thu, 27 Mar 2014 04:38:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qjOxrxmkOg15 for ; Thu, 27 Mar 2014 04:38:13 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 044B21A0652 for ; Thu, 27 Mar 2014 04:38:12 -0700 (PDT)
Received: from 172.18.9.243 (EHLO lhreml204-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CAN25240; Thu, 27 Mar 2014 06:38:11 -0500 (CDT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 11:37:36 +0000
Received: from SZXEMA403-HUB.china.huawei.com (10.82.72.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 27 Mar 2014 11:38:02 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.239]) by SZXEMA403-HUB.china.huawei.com ([10.82.72.35]) with mapi id 14.03.0158.001; Thu, 27 Mar 2014 19:37:52 +0800
From: "Shishufeng (Susan)" 
To: "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQN3mMmL1YBMEOBG3qYkPuXm5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeCAAuiLgP//eGTwABMWw4D//2p4EA==
Date: Thu, 27 Mar 2014 11:37:51 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C3EF92@SZXEMA512-MBX.china.huawei.com>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com> <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C3EF92SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/55MY6uIgxAUeAhSG_FOVWtkA1G4
X-Mailman-Approved-At: Thu, 27 Mar 2014 04:39:00 -0700
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 11:38:26 -0000

--_000_26C84DFD55BC3040A45BF70926E55F2587C3EF92SZXEMA512MBXchi_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hello Lionel,

Please see below.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lionel.morand@orange.com]
Sent: Thursday, March 27, 2014 6:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Please see below.

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,


-          I'm not talking the specific optional AVPs defined in this draft=
, but others e.g. defined in 3GPP specifications. We have a lot optional AV=
Ps with default values.
[LM] in 3GPP there are introduced in existing applications and usually in c=
ommands. There is no other options to include them are purely optional.
Susan: Not exactly, we have lots of optional AVPs from the first release.


-           my understanding, some cases an AVP is needed, some cases it is=
 not needed, that's the key point to justify its optionality.
[LM] I agree that we don't have the same understanding here.


-          Apart from the benefit of less AVPs and less error cases with th=
is AVP as optional, another key point is that the server(host) will never c=
are about the AVP at all. It will never need to remember to put such an AVP=
 into the message. Only agent needs to add such an AVP in case putting into=
 realm report, this would make things much simpler from my point of view.
[LM] that is wrong to say "never". A server can have realm-based informatio=
n that can be provided to reacting nodes. It is only depending of the serve=
r implementation and environment. For instance, if a realm is entirely dedi=
cated to a type of server, a farm based implementation would provide such f=
unctionality, as discussed.
Susan: In this case the server behaves more like an agent, not a pure serve=
r, i.e. the server provides agent functionality. In IETF, server and agent =
has clear difference.

Further, the discussion on Realm is still ongoing and whether it can work w=
ell is still under investigation.
[LM] I think that the ongoing discussion is too tight to specific use cases=
, important ones for 3GPP I admit. However the whole goal of this work is t=
o have something that it will work in any case. If there are some requireme=
nts for realm-based info, I don't see a specific reason to restrict the use=
 of report type. And don't forget that new report types can be created in t=
he future. So it is not restricted to Host vs realm.
Susan: May I ask what's wrong with this not always needed AVP as optional?

The benefit to have it as optional is clear, and this would not bring any h=
arm. I hope this can be reconsidered.
[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 5:31 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore=
.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_26C84DFD55BC3040A45BF70926E55F2587C3EF92SZXEMA512MBXchi_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hello Lion=
el,


 =
;


Please see=
 below.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=
 lionel.morand@orang=
e.com [mailto:lionel.morand@orange.com]


Sent: Thursday, March 27, 2014 6:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Claise

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


Please see be=
low.


 


Lionel


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 =
;



-I&=
#8217;m not talking the specific optional AVPs defined in this draft, but o=
thers e.g. defined in 3GPP specifications. We have a lot optional
 AVPs with default values. 


[LM]=
 in 3GPP there are introduced in existing applications and usually in comma=
nds. There is no other options to include them are purely
 optional.


Susan: Not=
 exactly, we have lots of optional AVPs from the first release.<=
/span>


 =
;



-&n=
bsp;my understanding, some cases an AVP is needed, some cases it is not nee=
ded, that’s the key point to justify its optionality.


[LM]=
 I agree that we don't have the same understanding here.


 =
;



-Ap=
art from the benefit of less AVPs and less error cases with this AVP as opt=
ional, another key point is that the server(host) will never
 care about the AVP at all. It will never need to remember to put such an A=
VP into the message. Only agent needs to add such an AVP in case putting in=
to realm report, this would make things much simpler from my point of view.



[LM]=
 that is wrong to say "never". A server can have realm-based info=
rmation that can be provided to reacting nodes. It is only depending
 of the server implementation and environment. For instance, if a realm is =
entirely dedicated to a type of server, a farm based implementation would p=
rovide such functionality, as discussed.



Susan: In =
this case the server behaves more like an agent, not a pure server, i.e. th=
e server provides agent functionality. In IETF, server and
 agent has clear difference.


 =
;


Further, t=
he discussion on Realm is still ongoing and whether it can work well is sti=
ll under investigation.


[LM]=
 I think that the ongoing discussion is too tight to specific use cases, im=
portant ones for 3GPP I admit. However the whole goal of this
 work is to have something that it will work in any case. If there are some=
 requirements for realm-based info, I don't see a specific reason to restri=
ct the use of report type. And don't forget that new report types can be cr=
eated in the future. So it is not
 restricted to Host vs realm.


Susan: May=
 I ask what’s wrong with this not always needed AVP as optional?



 =
;


The benefi=
t to have it as optional is clear, and this would not bring any harm. I hop=
e this can be reconsidered.


[LM]=
 let see if there are other voice that could not accept the proposed approa=
ch.


Susan: Ok,=
 but to be fair, maybe we can also ask who could not accept this AVP as opt=
ional. As I know, Steve could live with it as optional.



 =
;


Best Regar=
ds,


Susan=



 =
;






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 5:31 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


In this sp=
ecific case, the info carried by the AVP is not optional. You need this inf=
o in the algorithm as it will modify the behavior of the reacting
 node.


The curren=
t solution is to define a default value when not received.


 =
;


I believe =
that at the protocol level, having this AVP in every request is cleaner tha=
n relying on default value when not present. The initial goal
 for such default value was to limit the number of AVPs transmitted over th=
e interfaces. And I think that it is not so relevant according to the outpu=
t of the other discussions and such optimization is not deemed required any=
more.



 =
;


Moreover, =
the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used
 in some networks, Realm is perfectly valid as default value if the system =
is designed for that. I think that AT&T and Verizon have clearly expres=
sed their requirements for that.


 =
;


This reaso=
ning leads to change the existing for Grouped AVP from:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]

         * [ AVP ]


To:


 =
;


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]

         * [ AVP ]


 =
;


I would li=
ke to clarify that this discussion is totally independent of the M-bit sett=
ing of the AVP.


 =
;


And about =
why not put the other AVPs as required in the Grouped AVP, it is because it=
 is abvious that the other ones are linked to the reduction
 algo defined in this document. For other algos, you could find other AVPs =
(relying on the extensibility of this Grouped AVP) instead.


 =
;


Let me kno=
w if the clarification is useful.


 =
;


 =
;


Regards,


 =
;


Lionel


 =
;






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,=



 


If you car=
es, please clarify how this decision was made based on the newly ongoing te=
chnical discussion. I really don’t understand a useless AVP
 in most cases has to be mandatory.


 


May I ask =
why not define every optional AVP as mandatory if the only point you made d=
ecision was that it will not block anything?<=
/o:p>


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi,=



 


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.=



To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.


Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 


Regards,


 


Lionel


 


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-     &=
nbsp;   
Fi=
rst a not always needed AVP cannot justify why it shall be mandatory.




-     &=
nbsp;   
Se=
condly, in my view, having a not always needed AVP as mandatory cannot be l=
ess error prone. On the contrary, it would introduce more
 error cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSIN=
G_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with t=
he possible error cases. All the handling with this AVP consumes the resour=
ce of both reporting nodes and reacting
 nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.<=
o:p>


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



As chair and temporary doc shepherd,=



 <=
/span>


Please stop this thread for now.


 <=
/span>


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 <=
/span>


Lionel =



 <=
/span>


 <=
/span>


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 <=
/span>






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. =



 


Best Regards,

Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] <=
/span>


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan<=
/pre>

Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


Hi,


 


How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 


If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 


Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?=



 


- Jouni


 


 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 


 


Hello all,


 


I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.<=
/o:p>


 


I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 


Best regards


/MCruz


 


-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13


To: Jouni Korhonen=



Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 


On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 


 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 


I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 


- Jouni


 


On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 


Hi Mcruz


 


The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
span lang=3D"FR">


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 


Best regards


 


JJacques


 


 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de =



lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 

[dime] #54: OC-Report-Type as mandatory AVP


 


Hi Maria Cruz,

 


I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?

 


So instead of:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


You would prefer:<=
/pre>

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number >

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 


And I'm fine with this proposal.


 


Cheers,


 


Lionel


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue =



tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP


 


#54: OC-Report-Type as mandatory AVP=



 


Now in chapter 4.6:


 


 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 


This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 


--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz

  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new

Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 


Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>

 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_____________________________________________________________=
________


____________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 


 




 


_______________________________________________


DiME mailing list<=
/pre>

DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 =





 =







_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions 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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.=



As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.=



Thank you.


________________________________________________________________=
_________________________________________________________


 


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.

 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;<=
o:p>


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.




 =



____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_26C84DFD55BC3040A45BF70926E55F2587C3EF92SZXEMA512MBXchi_--


From nobody Thu Mar 27 05:15: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 D45691A067E for ; Thu, 27 Mar 2014 05:15:17 -0700 (PDT)
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 wa6QcP2SPQ5s for ; Thu, 27 Mar 2014 05:15:01 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id BE0161A0668 for ; Thu, 27 Mar 2014 05:15:00 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 0EF2D1B8202; Thu, 27 Mar 2014 13:14:58 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id A690E180056; Thu, 27 Mar 2014 13:14:57 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0174.001; Thu, 27 Mar 2014 13:14:57 +0100
From: 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Shishufeng (Susan)" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQNKav1Yd2xqUyLNClmxsrsL5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeD//Jsx8ADZeeeA///qNtD//8/ygP//jV9g//8STjA=
Date: Thu, 27 Mar 2014 12:14:56 +0000
Message-ID: <26274_1395922498_53341641_26274_13645_1_6B7134B31289DC4FAF731D844122B36E521058@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com> <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EF92@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D8B92@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D8B92@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.197.38.4]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E521058PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.3.25.173915
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Oi7PpnE-3y3qtg-DJ3E9kDlIcYM
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 12:15:18 -0000

--_000_6B7134B31289DC4FAF731D844122B36E521058PEXCVZYM13corpora_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

More than OK with your last statement.

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoy=E9 : jeudi 27 mars 2014 12:53
=C0 : ext Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni K=
orhonen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

I can accept both (though I have a slight preference in favour of Susan).
Actually I think this is a so minor minor minor issue that it  could serve =
as a very good opportunity for people to show their willingness to give in,=
 in order to make progress.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Shishufeng (Susa=
n)
Sent: Thursday, March 27, 2014 12:38 PM
To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Please see below.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 6:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Please see below.

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,


-          I'm not talking the specific optional AVPs defined in this draft=
, but others e.g. defined in 3GPP specifications. We have a lot optional AV=
Ps with default values.
[LM] in 3GPP there are introduced in existing applications and usually in c=
ommands. There is no other options to include them are purely optional.
Susan: Not exactly, we have lots of optional AVPs from the first release.


-           my understanding, some cases an AVP is needed, some cases it is=
 not needed, that's the key point to justify its optionality.
[LM] I agree that we don't have the same understanding here.


-          Apart from the benefit of less AVPs and less error cases with th=
is AVP as optional, another key point is that the server(host) will never c=
are about the AVP at all. It will never need to remember to put such an AVP=
 into the message. Only agent needs to add such an AVP in case putting into=
 realm report, this would make things much simpler from my point of view.
[LM] that is wrong to say "never". A server can have realm-based informatio=
n that can be provided to reacting nodes. It is only depending of the serve=
r implementation and environment. For instance, if a realm is entirely dedi=
cated to a type of server, a farm based implementation would provide such f=
unctionality, as discussed.
Susan: In this case the server behaves more like an agent, not a pure serve=
r, i.e. the server provides agent functionality. In IETF, server and agent =
has clear difference.

Further, the discussion on Realm is still ongoing and whether it can work w=
ell is still under investigation.
[LM] I think that the ongoing discussion is too tight to specific use cases=
, important ones for 3GPP I admit. However the whole goal of this work is t=
o have something that it will work in any case. If there are some requireme=
nts for realm-based info, I don't see a specific reason to restrict the use=
 of report type. And don't forget that new report types can be created in t=
he future. So it is not restricted to Host vs realm.
Susan: May I ask what's wrong with this not always needed AVP as optional?

The benefit to have it as optional is clear, and this would not bring any h=
arm. I hope this can be reconsidered.
[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 5:31 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________

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_6B7134B31289DC4FAF731D844122B36E521058PEXCVZYM13corpora_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











More than =
OK with your last statement.


 =
;






De :=
 Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulric=
h.wiehe@nsn.com]


Envoy=E9 : jeudi 27 mars 2014 12:53

=C0 : ext Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Dono=
van; Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


[LM]=
 let see if there are other voice that could not accept the proposed approa=
ch.


Susan: Ok,=
 but to be fair, maybe we can also ask who could not accept this AVP as opt=
ional. As I know, Steve could live with it as optional.



 =
;


I can acce=
pt both (though I have a slight preference in favour of Susan).<=
/span>


Actually I=
 think this is a so minor minor minor issue that it  could serve as a =
very good opportunity for people to show their willingness to give
 in, in order to make progress.


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Shishufeng (Susan)

Sent: Thursday, March 27, 2014 12:38 PM

To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hello Lion=
el,


 =
;


Please see=
 below.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 6:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 <=
/p>

Please see below.


 <=
/p>

Lionel<=
/p>

 <=
/p>





De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : jeudi 27 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 =
;



-I’m not talking the specific optional AVPs def=
ined in this draft, but others e.g. defined in 3GPP specifications.
 We have a lot optional AVPs with default values. 


[LM]=
 in 3GPP there are introduced in existing applications and usually in comma=
nds. There is no other options to include them are purely
 optional.


Susan: Not=
 exactly, we have lots of optional AVPs from the first release.<=
/span>


 =
;



- my understanding, some cases an AVP is needed,=
 some cases it is not needed, that’s the key point to justify its
 optionality.


[LM]=
 I agree that we don't have the same understanding here.


 =
;



-Apart from the benefit of less AVPs and less error c=
ases with this AVP as optional, another key point is that
 the server(host) will never care about the AVP at all. It will never need =
to remember to put such an AVP into the message. Only agent needs to add su=
ch an AVP in case putting into realm report, this would make things much si=
mpler from my point of view.



[LM]=
 that is wrong to say "never". A server can have realm-based info=
rmation that can be provided to reacting nodes. It is only depending
 of the server implementation and environment. For instance, if a realm is =
entirely dedicated to a type of server, a farm based implementation would p=
rovide such functionality, as discussed.



Susan: In =
this case the server behaves more like an agent, not a pure server, i.e. th=
e server provides agent functionality. In IETF, server and
 agent has clear difference.


 =
;


Further, t=
he discussion on Realm is still ongoing and whether it can work well is sti=
ll under investigation.


[LM]=
 I think that the ongoing discussion is too tight to specific use cases, im=
portant ones for 3GPP I admit. However the whole goal of this
 work is to have something that it will work in any case. If there are some=
 requirements for realm-based info, I don't see a specific reason to restri=
ct the use of report type. And don't forget that new report types can be cr=
eated in the future. So it is not
 restricted to Host vs realm.


Susan: May=
 I ask what’s wrong with this not always needed AVP as optional?



 =
;


The benefi=
t to have it as optional is clear, and this would not bring any harm. I hop=
e this can be reconsidered.


[LM]=
 let see if there are other voice that could not accept the proposed approa=
ch.


Susan: Ok,=
 but to be fair, maybe we can also ask who could not accept this AVP as opt=
ional. As I know, Steve could live with it as optional.



 =
;


Best Regar=
ds,


Susan=



 =
;






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 5:31 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 <=
/p>

In this sp=
ecific case, the info carried by the AVP is not optional. You need this inf=
o in the algorithm as it will modify the behavior of the reacting
 node.


The curren=
t solution is to define a default value when not received.


 =
;


I believe =
that at the protocol level, having this AVP in every request is cleaner tha=
n relying on default value when not present. The initial goal
 for such default value was to limit the number of AVPs transmitted over th=
e interfaces. And I think that it is not so relevant according to the outpu=
t of the other discussions and such optimization is not deemed required any=
more.



 =
;


Moreover, =
the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used
 in some networks, Realm is perfectly valid as default value if the system =
is designed for that. I think that AT&T and Verizon have clearly expres=
sed their requirements for that.


 =
;


This reaso=
ning leads to change the existing for Grouped AVP from:

 


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


To:


 =
;


OC-OLR ::=3D < AVP Header: TBD2 >


           =
< OC-Sequence-Number ><=
/pre>

           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]

           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =
;


I would li=
ke to clarify that this discussion is totally independent of the M-bit sett=
ing of the AVP.


 =
;


And about =
why not put the other AVPs as required in the Grouped AVP, it is because it=
 is abvious that the other ones are linked to the reduction
 algo defined in this document. For other algos, you could find other AVPs =
(relying on the extensibility of this Grouped AVP) instead.


 =
;


Let me kno=
w if the clarification is useful.


 =
;


 =
;


Regards,


 =
;


Lionel


 =
;






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,=



 


If you car=
es, please clarify how this decision was made based on the newly ongoing te=
chnical discussion. I really don’t understand a useless AVP
 in most cases has to be mandatory.


 


May I ask =
why not define every optional AVP as mandatory if the only point you made d=
ecision was that it will not block anything?


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi,=



 


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.


To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.<=
/p>

Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 


Regards,


 


Lionel


 


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-       &nb=
sp; 
First a not always needed AVP cannot justify why it =
shall be mandatory.




-       &nb=
sp; 
Secondly, in my view, having a not always needed AVP=
 as mandatory cannot be less error prone. On the contrary,
 it would introduce more error cases. RFC 6733 defines a couple of error co=
des e.g. DIAMETER_MISSING_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and may=
be others to deal with the possible error cases. All the handling with this=
 AVP consumes the resource of both
 reporting nodes and reacting nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De :=
 Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,=



 


Please stop this thread for now.


 


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.<=
/p>

 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,


 


I assume we had a lot of discussion on this and reached conse=
nsus to keep it as it is in the draft. 


 


Best Regards,


Susan


 


 


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 


 


Lets have it explicit then. Use '<' and '>' to make the=
 position fixed.


 


- Jouni


 


On Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


 




I'm ok with either direction but generally lean toward being =
explicit.


 


Do we have other opinions?  


 


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:<=
/o:p>




Hello,


I think the agreement tendency is the contrary: OC-Report-Typ=
e is not required, while default value is Host. i.e. it will remain as it i=
s now in the draft.


This may be of some advantage for some applications that may =
only use Host, as long as they may never generate Realm reports.


If there is consensus on this, I will go with this.


Best regards


/MCruz


 =



From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



All,


 


Do we have consensus that the OC-Report-Type AVP is required?=



 


If so then one change would be as indicated in the syntax def=
inition proposed by Lionel.  We would also remove wording on the defau=
lt value.


 


Jouni,


 


How do we indicate a fixed position for an AVP?  =



 


I presonally don't see this as critical but we can add this r=
equirement if there is consensus.


 


Regards,


 


Steve


 


On 2/28/14 10:27 AM, Jouni Korhonen wrote:<=
/pre>

 =



Hi,


 =



How having the AVP could be less error prone if it has a defa=
ult 


value and the receiver knows exactly how to proceed when the =
AVP is 


not present?


 =



If a node does not include it when it should, the implementat=
ion is 


broken. Wouldn't a broken node be able to put wrong report ty=
pe into 


the AVP even if the AVP is mandatory?


 =



Anyway, if it is my statement keeping issue #54 still open, c=
onsider 


it resolved from my side. I am OK making the OC-Report-Type A=
VP as 


required/mandatory AVP. Should we also consider it having a f=
ixed 


position just after the OC-Sequence-Number AVP as well since =
it is 


going to in every OC-OLR?


 =



- Jouni


 =



 


 


On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsso=
n.com> wrote:


 =



 


Hello all,


 =



I understand JJ point of view, but I still tend to prefer to =
make it mandatory, since I think this is less error-prone, since the only n=
ode that knows the requested Report-Type is the reporting, if for any reaso=
n a reporting is omitting it (since it is optional), it will be always inte=
rpreted as HOST, but this type may be wrong.


 =



I think DEFAULT values should never be error-prone, but used =
in "general cases", as a simplification, like e.g. a default for =
the Validity-Duration. Default Validity-Duration will never be an "err=
or", it could be not the best value (compared with another value perfe=
ctly tuned to reporting node overload situation) but never the use of a Def=
ault value should lead to an erroneous behavior.


 =



Best regards


/MCruz


 =



-----Original Message-----


From: DiME [mailto:d=
ime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13<=
/pre>

To: Jouni Korhonen


Cc: dime@ietf.org=



Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory A=
VP


 =



I actually prefer making it mandatory. The cost of adding it =
is trivial--even more so for a reporting node that only supports the defaul=
t. The value of having it is less opportunity for interop errors.


 =



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 =



 


Agree that it is a small optimization, which I put there beca=
use at 


the beginning there seemed to be a lot of worry on every extr=
a AVP 


;-)


 =



I prefer having the AVP optional but with a default value jus=
t like 


it is now. We have the same for the reduction percentage and =
the 


validity time as well.


 =



- Jouni


 =



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JE=
AN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wrote:


 =



Hi Mcruz


 =



The current description indicates that when not present the O=
LR is of type Host, which was fine for me and keeps my preference. <=
o:p>


We may have  deployments where Realm OLR is not used, or=
 where statistically the HOST type is the most frequent, so to have the gro=
uped OLR-AVP containing a minimum of AVPs minimizes parsing. I agree it is =
a small optimization.


 =



Best regards


 =



JJacques


 =



 


 


 


-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de 


lionel.morand@ora=
nge.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


dime@ietf.org; maria.cruz.bartolome@ericsson=
.com Objet : Re: [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



Hi Maria Cruz,


 =



I'm assuming that you mean "required" instead of &q=
uot;mandatory", right?


 =



So instead of:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
[ OC-Report-Type ]


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



You would prefer:


 =



OC-OLR ::=3D < AVP Header: TBD2 >

           =
< OC-Sequence-Number >


           =
{ OC-Report-Type }


           =
[ OC-Reduction-Percentage ]


           =
[ OC-Validity-Duration ]


         * [ AVP ]


 =



And I'm fine with this proposal.


 =



Cheers,


 =



Lionel


 =



-----Message d'origine-----


De : DiME [mailto:di=
me-bounces@ietf.org] De la part de dime issue 


tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


maria.cr=
uz.bartolome@ericsson.com Cc : dime@ie=
tf.org Objet : [Dime] 


[dime] #54: OC-Report-Type as mandatory AVP=



 =



#54: OC-Report-Type as mandatory AVP


 =



Now in chapter 4.6:


 =



 The default value of the OC-Report-Type AVP is 0 (i.e. =
the host  


report).


 =



This AVP is always required, right? Then, I think it is more =
precise that  we define this AVP as mandatory.


 =



--


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


Reporter:  maria.cruz.bartolome@ericsson.com  |   &nbs=
p;  Owner:  MCruz


  Type:  defect      =
             &n=
bsp;         |  Bartolom=
=E9


Priority:  major      &nbs=
p;            &=
nbsp;          |  &n=
bsp;  Status:  new


Component:  draft-docdt-dime-ovli    =
;          |  Milestone:<=
/span>


Severity:  Active WG Document    &nb=
sp;            |&nbs=
p;   Version:  1.0


          &=
nbsp;           &nbs=
p;             =
        |   Keywords:


-----------------------------------------------+---------=
------------


-----------------------------------------------+---


-----------------------------------------------+---


 =



Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/54><=
/span>


dime <http://to=
ols.ietf.org/wg/dime/>


 =



_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime


 =



_____________________________________________________________=
________


____________________________________________________


 =



Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=
 exploites ou copies sans autorisation. Si vous avez recu ce message par er=
reur, veuillez le signaler a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration, Ora=
nge decline toute responsabilite si ce message a ete altere, deforme ou fal=
sifie. Merci.


 =



This message and its attachments may contain confidential or =
privileged information that may be protected by law; they should not be dis=
tributed, used or copied without authorisation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat 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


 =



 




 


_______________________________________________


DiME mailing list


DiME@ietf.org


https:=
//www.ietf.org/mailman/listinfo/dime




 


 


 




 




 






_____________________________________________________________=
____________________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informa=
tions confidentielles ou privilegiees et ne doivent donc<=
/pre>

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. L=
es messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete alter=
e, 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 author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


Thank you.


_=
___________________________________________________________________________=
_____________________________________________


&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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.




 


______________________________________________________________________=
___________________________________________________


 


Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


 


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
o:p>


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 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_6B7134B31289DC4FAF731D844122B36E521058PEXCVZYM13corpora_--


From nobody Thu Mar 27 06:43: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 2B0D81A0666 for ; Thu, 27 Mar 2014 04:54:07 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 a9EU-6EzxQRF for ; Thu, 27 Mar 2014 04:53:54 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8F01A031A for ; Thu, 27 Mar 2014 04:53:53 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2RBqvFi008141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Mar 2014 11:52:57 GMT
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 s2RBqvQR001896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Mar 2014 12:52:57 +0100
Received: from DEMUHTC012.nsn-intra.net (10.159.42.43) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 27 Mar 2014 12:52:56 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.65]) by DEMUHTC012.nsn-intra.net ([10.159.42.43]) with mapi id 14.03.0123.003; Thu, 27 Mar 2014 12:52:56 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" 
To: "ext Shishufeng (Susan)" , "lionel.morand@orange.com" , Steve Donovan , Jouni Korhonen 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPRcQNKav1Yd2xqUyLNClmxsrsL5rvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeD//Jsx8ADZeeeA///qNtD//8/ygP//jV9g
Date: Thu, 27 Mar 2014 11:52:56 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D8B92@DEMUMBX014.nsn-intra.net>
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com> <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EF92@SZXEMA512-MBX.china.huawei.com>
In-Reply-To: <26C84DFD55BC3040A45BF70926E55F2587C3EF92@SZXEMA512-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D8B92DEMUMBX014nsnin_"
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: 167965
X-purgate-ID: 151667::1395921177-0000128C-A0D84565/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/pKms8MbOIi5lrWNJuEzWY7rLaXg
X-Mailman-Approved-At: Thu, 27 Mar 2014 06:43:22 -0700
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 11:54:07 -0000

--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D8B92DEMUMBX014nsnin_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

I can accept both (though I have a slight preference in favour of Susan).
Actually I think this is a so minor minor minor issue that it  could serve =
as a very good opportunity for people to show their willingness to give in,=
 in order to make progress.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Shishufeng (Susa=
n)
Sent: Thursday, March 27, 2014 12:38 PM
To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Please see below.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 6:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Please see below.

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,


-          I'm not talking the specific optional AVPs defined in this draft=
, but others e.g. defined in 3GPP specifications. We have a lot optional AV=
Ps with default values.
[LM] in 3GPP there are introduced in existing applications and usually in c=
ommands. There is no other options to include them are purely optional.
Susan: Not exactly, we have lots of optional AVPs from the first release.


-           my understanding, some cases an AVP is needed, some cases it is=
 not needed, that's the key point to justify its optionality.
[LM] I agree that we don't have the same understanding here.


-          Apart from the benefit of less AVPs and less error cases with th=
is AVP as optional, another key point is that the server(host) will never c=
are about the AVP at all. It will never need to remember to put such an AVP=
 into the message. Only agent needs to add such an AVP in case putting into=
 realm report, this would make things much simpler from my point of view.
[LM] that is wrong to say "never". A server can have realm-based informatio=
n that can be provided to reacting nodes. It is only depending of the serve=
r implementation and environment. For instance, if a realm is entirely dedi=
cated to a type of server, a farm based implementation would provide such f=
unctionality, as discussed.
Susan: In this case the server behaves more like an agent, not a pure serve=
r, i.e. the server provides agent functionality. In IETF, server and agent =
has clear difference.

Further, the discussion on Realm is still ongoing and whether it can work w=
ell is still under investigation.
[LM] I think that the ongoing discussion is too tight to specific use cases=
, important ones for 3GPP I admit. However the whole goal of this work is t=
o have something that it will work in any case. If there are some requireme=
nts for realm-based info, I don't see a specific reason to restrict the use=
 of report type. And don't forget that new report types can be created in t=
he future. So it is not restricted to Host vs realm.
Susan: May I ask what's wrong with this not always needed AVP as optional?

The benefit to have it as optional is clear, and this would not bring any h=
arm. I hope this can be reconsidered.
[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 5:31 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore=
.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_5BCBA1FC2B7F0B4C9D935572D9000668151D8B92DEMUMBX014nsnin_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











[LM]=
 let see if there are other voice that could not accept the proposed approa=
ch.


Susan: Ok,=
 but to be fair, maybe we can also ask who could not accept this AVP as opt=
ional. As I know, Steve could live with it as optional.



 =
;


I can acce=
pt both (though I have a slight preference in favour of Susan).<=
/span>


Actually I=
 think this is a so minor minor minor issue that it  could serve as a =
very good opportunity for people to show their willingness to give
 in, in order to make progress.


 =
;


Ulrich


 =
;






From:=
 DiME [mailto:dime-b=
ounces@ietf.org]
On Behalf Of ext Shishufeng (Susan)

Sent: Thursday, March 27, 2014 12:38 PM

To: lionel.morand@orange.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hello Lion=
el,


 =
;


Please see=
 below.


 =
;


Best Regar=
ds,


Susan=



 =
;






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 6:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


Please see be=
low.


 


Lionel


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lion=
el,


 =
;



-I&=
#8217;m not talking the specific optional AVPs defined in this draft, but o=
thers e.g. defined in 3GPP specifications. We have a lot optional
 AVPs with default values. 


[LM]=
 in 3GPP there are introduced in existing applications and usually in comma=
nds. There is no other options to include them are purely
 optional.


Susan: Not=
 exactly, we have lots of optional AVPs from the first release.<=
/span>


 =
;



-&n=
bsp;my understanding, some cases an AVP is needed, some cases it is not nee=
ded, that’s the key point to justify its optionality.


[LM]=
 I agree that we don't have the same understanding here.


 =
;



-Ap=
art from the benefit of less AVPs and less error cases with this AVP as opt=
ional, another key point is that the server(host) will never
 care about the AVP at all. It will never need to remember to put such an A=
VP into the message. Only agent needs to add such an AVP in case putting in=
to realm report, this would make things much simpler from my point of view.



[LM]=
 that is wrong to say "never". A server can have realm-based info=
rmation that can be provided to reacting nodes. It is only depending
 of the server implementation and environment. For instance, if a realm is =
entirely dedicated to a type of server, a farm based implementation would p=
rovide such functionality, as discussed.



Susan: In =
this case the server behaves more like an agent, not a pure server, i.e. th=
e server provides agent functionality. In IETF, server and
 agent has clear difference.


 =
;


Further, t=
he discussion on Realm is still ongoing and whether it can work well is sti=
ll under investigation.


[LM]=
 I think that the ongoing discussion is too tight to specific use cases, im=
portant ones for 3GPP I admit. However the whole goal of this
 work is to have something that it will work in any case. If there are some=
 requirements for realm-based info, I don't see a specific reason to restri=
ct the use of report type. And don't forget that new report types can be cr=
eated in the future. So it is not
 restricted to Host vs realm.


Susan: May=
 I ask what’s wrong with this not always needed AVP as optional?



 =
;


The benefi=
t to have it as optional is clear, and this would not bring any harm. I hop=
e this can be reconsidered.


[LM]=
 let see if there are other voice that could not accept the proposed approa=
ch.


Susan: Ok,=
 but to be fair, maybe we can also ask who could not accept this AVP as opt=
ional. As I know, Steve could live with it as optional.



 =
;


Best Regar=
ds,


Susan=



 =
;






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 5:31 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


In this sp=
ecific case, the info carried by the AVP is not optional. You need this inf=
o in the algorithm as it will modify the behavior of the reacting
 node.


The curren=
t solution is to define a default value when not received.


 =
;


I believe =
that at the protocol level, having this AVP in every request is cleaner tha=
n relying on default value when not present. The initial goal
 for such default value was to limit the number of AVPs transmitted over th=
e interfaces. And I think that it is not so relevant according to the outpu=
t of the other discussions and such optimization is not deemed required any=
more.



 =
;


Moreover, =
the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used
 in some networks, Realm is perfectly valid as default value if the system =
is designed for that. I think that AT&T and Verizon have clearly expres=
sed their requirements for that.


 =
;


This reaso=
ning leads to change the existing for Grouped AVP from:

 


OC-OLR ::=3D < AVP Header: TBD2 >


       &=
nbsp;   < OC-Sequence-Number ><=
o:p>


       &=
nbsp;   [ OC-Report-T=
ype ]

       &=
nbsp;   [ OC-Reduction-Percentage ]


       &=
nbsp;   [ OC-Validity-Duration ]=



       &=
nbsp; * [ AVP ]


To:


 =
;


OC-OLR ::=3D < AVP Header: TBD2 >


       &=
nbsp;   < OC-Sequence-Number ><=
o:p>


       &=
nbsp;   { OC-Report-T=
ype }

       &=
nbsp;   [ OC-Reduction-Percentage ]


       &=
nbsp;   [ OC-Validity-Duration ]=



       &=
nbsp; * [ AVP ]


 =
;


I would li=
ke to clarify that this discussion is totally independent of the M-bit sett=
ing of the AVP.


 =
;


And about =
why not put the other AVPs as required in the Grouped AVP, it is because it=
 is abvious that the other ones are linked to the reduction
 algo defined in this document. For other algos, you could find other AVPs =
(relying on the extensibility of this Grouped AVP) instead.


 =
;


Let me kno=
w if the clarification is useful.


 =
;


 =
;


Regards,


 =
;


Lionel


 =
;






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,=



 


If you car=
es, please clarify how this decision was made based on the newly ongoing te=
chnical discussion. I really don’t understand a useless AVP
 in most cases has to be mandatory.


 


May I ask =
why not define every optional AVP as mandatory if the only point you made d=
ecision was that it will not block anything?<=
/o:p>


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi,=



 


Because it=
 was not possible to make everyone happy, I made a decision. I think that t=
his decision is valid and will not block anything.=



To be fair=
, I think that the majority could accept both while few have a strong prefe=
rence for optional or mandatory.  And I picked one.


Can we ple=
ase discuss about something else or is it the most critical point to solve?=
 I think that everyone is waiting for a version 02 before
 the end of this week.


 


Regards,


 


Lionel


 


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Stev=
e,


 


Ok, let=
217;s come back with technical discussion then.


 



-     &=
nbsp;   
Fi=
rst a not always needed AVP cannot justify why it shall be mandatory.




-     &=
nbsp;   
Se=
condly, in my view, having a not always needed AVP as mandatory cannot be l=
ess error prone. On the contrary, it would introduce more
 error cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSIN=
G_AVP 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with t=
he possible error cases. All the handling with this AVP consumes the resour=
ce of both reporting nodes and reacting
 nodes. I don't see any benefit to have it.


=
 


Best Regar=
ds,


Susan


 


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng =
(Susan) wrote:






Hello Lion=
el,


 


Thanks for=
 your reply.


 


It is clea=
r that majority companies involved in the discussion prefer to not have thi=
s AVP as mandatory. And Steve is ok with it as it is, and
 thus everyone is ok with it as optional. I’m wondering why you choos=
e another way forward, and don’t take opinion from majority companies=
 into account, which is strange for me.



 


We talked =
much about it, and in some major cases, this AVP is useless. If needed, any=
way an optional AVP has to be present, I don’t see any problem
 with it. We did a lot like this in 3GPP spec. I don’t understand how=
 in this case it shall be mandatory if you also agree that it is not needed=
 in some cases.


 


Best Regar=
ds,


Susan


 


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hi Susan,<=
/span>


 


I do care =
about comments from other but we need to move on.<=
o:p>


 


My decisio=
n is based on the following: from a technical point of view, there is no is=
sue if we define this AVP as required. From a protocol aspect,
 it is cleaner as a report ALWAYS applies to a given type. Default value wa=
s considered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has trigg=
ered this issue) and myself.


 


Now, about=
 the process, a 100% is not required to move forward. As it is not possible=
 to get consensus on this issue, I use my prerogative to pick
 one solution, the one that seems to be the best solution at this stage, to=
 be able to close the discussion at this stage and produce the draft that w=
e need.


 


After, it =
is always possible to challenge again the content of the draft if there is =
still concern.


 


Benoit, th=
e Area Director, is copied. It is not a putsch. Just administrative way agr=
eed within IETF to be able to move forward a WG draft, which
 is the ultimate goal of everyone I think.


 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lion=
el,


 


Further cl=
arification:


 


I don̵=
7;t agree with this, not ok to everyone as you said.


 


Best Regar=
ds,


Susan


 






From:=
 Shishufeng (Susan) =
[mailto:susan.shishufeng@hua=
wei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



Hello Lion=
el,


 


I don̵=
7;t understand it.


 


Please cla=
rify if you care about other people’s comments.


 


Best Regar=
ds,


Susan


 






From:=

lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



As chair and temporary doc shepherd,=



 <=
/span>


Please stop this thread for now.


 <=
/span>


As mandatory/required is ok for everyone (e=
ven if useless in certain case), let use it for now.


 <=
/span>


Lionel =



 <=
/span>


 <=
/span>


"Shishufeng (Susan)" <susan.shishufeng@huawei.com>=
 a =E9crit :


 <=
/span>






Hello Stev=
e,


 


Thanks for=
 clarifying the IETF procedure. I’m not familiar with it, while I kno=
w the draft is mainly for 3GPP use, that’s why we 3GPP delegates
 are deeply involved in this specific discussion. If most of 3GPP people th=
ink it is not so needed I couldn’t understand why it shall be mandato=
ry.


 


From techn=
ical point of view, in the case realm based report type is not needed, noth=
ing wrong without this AVP, and even better and cleaner.


 


And you ev=
er said you have preference but ok with either way forward, i.e., make it m=
andatory or optional. Then let’s move on with the draft as
 it is on this point, if you agree. 


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng=
 (Susan) wrote:






Hi Steve,<=
/span>


 


As I know,=
 majority companies expressed preference to keep the AVP as optional and ke=
ep the texts as they are. You have preference to have it explicitly
 but ok with either way. That’s how I assumed we reached consensus.


 


Best Regar=
ds,


Susan


 






From:=
 Steve Donovan [mailto:srdonovan@usdonovans.com=
]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 =



=
Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng=
 (Susan) wrote:






Hello Jouni,<=
/o:p>


 <=
/span>


I assume we had a lot of discussion on this=
 and reached consensus to keep it as it is in the draft. 


 <=
/span>


Best Regards,=



Susan


 <=
/span>


 <=
/span>


-----Original Message-----


From: Jouni Korhonen [mailto:jouni.nospam@gmail.com] 


Sent: Saturday, March 22, 2014 10:38 AM


To: Steve Donovan<=
o:p>


Cc: dime@i=
etf.org


Subject: Re: [Dime] [dime] #54: OC-Report-T=
ype as mandatory AVP


 <=
/span>


 <=
/span>


Lets have it explicit then. Use '<' and =
'>' to make the position fixed.


 <=
/span>


- Jouni=



 <=
/span>


On Mar 19, 2014, at 1:29 AM, Steve Donovan =
<srdonovan@usdonovans.com>=
; wrote:


 <=
/span>




I'm ok with either direction but generally =
lean toward being explicit.

 <=
/span>


Do we have other opinions?  


 <=
/span>


Steve


On 3/18/14 12:16 PM, Maria Cruz Bartolome w=
rote:




Hello,<=
/span>


I think the agreement tendency is the contr=
ary: OC-Report-Type is not required, while default value is Host. i.e. it w=
ill remain as it is now in the draft.


This may be of some advantage for some appl=
ications that may only use Host, as long as they may never generate Realm r=
eports.


If there is consensus on this, I will go wi=
th this.


Best regards<=
/o:p>


/MCruz<=
/span>


 

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan


Sent: martes, 18 de marzo de 2014 17:47


To: dime@i=
etf.org


Subject: Re: [Dime] [dime] #54: OC-Report-T=
ype as mandatory AVP


 

All,


 <=
/span>


Do we have consensus that the OC-Report-Typ=
e AVP is required?


 <=
/span>


If so then one change would be as indicated=
 in the syntax definition proposed by Lionel.  We would also remove wo=
rding on the default value.

 <=
/span>


Jouni,<=
/span>


 <=
/span>


How do we indicate a fixed position for an =
AVP?  


 <=
/span>


I presonally don't see this as critical but=
 we can add this requirement if there is consensus.


 <=
/span>


Regards,


 <=
/span>


Steve


 <=
/span>


On 2/28/14 10:27 AM, Jouni Korhonen wrote:<=
/span>


 

Hi,


 

How having the AVP could be less error pron=
e if it has a default 


value and the receiver knows exactly how to=
 proceed when the AVP is 


not present?<=
/o:p>


 

If a node does not include it when it shoul=
d, the implementation is 


broken. Wouldn't a broken node be able to p=
ut wrong report type into 


the AVP even if the AVP is mandatory?


 

Anyway, if it is my statement keeping issue=
 #54 still open, consider 


it resolved from my side. I am OK making th=
e OC-Report-Type AVP as 


required/mandatory AVP. Should we also cons=
ider it having a fixed 


position just after the OC-Sequence-Number =
AVP as well since it is 


going to in every OC-OLR?


 

- Jouni=



 

 <=
/span>


 <=
/span>


On Feb 21, 2014, at 11:47 AM, Maria Cruz Ba=
rtolome <maria.cruz=
.bartolome@ericsson.com> wrote:<=
/span>


 

 <=
/span>


Hello all,


 

I understand JJ point of view, but I still =
tend to prefer to make it mandatory, since I think this is less error-prone=
, since the only node that knows the requested Report-Type is the reporting=
, if for any reason a reporting is omitting it (since it is optional), it w=
ill be always interpreted as HOST, but this type may be wrong.


 

I think DEFAULT values should never be erro=
r-prone, but used in "general cases", as a simplification, like e=
.g. a default for the Validity-Duration. Default Validity-Duration will nev=
er be an "error", it could be not the best value (compared with a=
nother value perfectly tuned to reporting node overload situation) but neve=
r the use of a Default value should lead to an erroneous behavior.


 

Best regards<=
/o:p>


/MCruz<=
/span>


 

-----Original Message-----


From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell


Sent: viernes, 14 de febrero de 2014 23:13<=
/span>


To: Jouni Korhonen=



Cc: dime@i=
etf.org


Subject: Re: [Dime] [dime] #54: OC-Report-T=
ype as mandatory AVP


 

I actually prefer making it mandatory. The =
cost of adding it is trivial--even more so for a reporting node that only s=
upports the default. The value of having it is less opportunity for interop=
 errors.


 

On Feb 13, 2014, at 6:05 AM, Jouni Korhonen=
 <jouni.nospam@gmail.com> wrote:


 

 <=
/span>


Agree that it is a small optimization, whic=
h I put there because at 


the beginning there seemed to be a lot of w=
orry on every extra AVP 


;-)


 

I prefer having the AVP optional but with a=
 default value just like 


it is now. We have the same for the reducti=
on percentage and the 


validity time as well.


 

- Jouni=



 

On Feb 13, 2014, at 10:55 AM, "TROTTIN=
, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> wro=
te:


 

Hi Mcruz


 

The current description indicates that when=
 not present the OLR is of type Host, which was fine for me and keeps my pr=
eference. 


We may have  deployments where Realm O=
LR is not used, or where statistically the HOST type is the most frequent, =
so to have the grouped OLR-AVP containing a minimum of AVPs minimizes parsi=
ng. I agree it is a small optimization.=



 

Best regards<=
/o:p>


 

JJacques


 

 <=
/span>


 <=
/span>


 <=
/span>


-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de 


lionel.morand@orange.com Envoy=E9 : mercredi 12 f=E9vrier 2014 15:46 =
=C0 :


dime@ietf.=
org; maria.cruz.ba=
rtolome@ericsson.com Objet : Re: [Dime] <=
/o:p>


[dime] #54: OC-Report-Type as mandatory AVP=



 

Hi Maria Cruz,


 

I'm assuming that you mean "required&q=
uot; instead of "mandatory", right?=



 

So instead of:


 

OC-OLR ::=3D < AVP Header: TBD2 >


       &=
nbsp;   < OC-Sequence-Number >


       &=
nbsp;   [ OC-Report-Type ]


       &=
nbsp;   [ OC-Reduction-Percentage ]=



       &=
nbsp;   [ OC-Validity-Duration ]


       &=
nbsp; * [ AVP ]


 

You would prefer:<=
o:p>


 

OC-OLR ::=3D < AVP Header: TBD2 >


       &=
nbsp;   < OC-Sequence-Number >


       &=
nbsp;   { OC-Report-Type }


       &=
nbsp;   [ OC-Reduction-Percentage ]=



       &=
nbsp;   [ OC-Validity-Duration ]


       &=
nbsp; * [ AVP ]


 

And I'm fine with this proposal.


 

Cheers,=



 

Lionel<=
/span>


 

-----Message d'origine-----


De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue =



tracker Envoy=E9 : mercredi 12 f=E9vrier 20=
14 15:26 =C0 :


maria.cruz.bartolome@ericsson.com Cc : dime@ietf.org Objet : [Dime] <=
/o:p>


[dime] #54: OC-Report-Type as mandatory AVP=



 

#54: OC-Report-Type as mandatory AVP=



 

Now in chapter 4.6:


 

 The default value of the OC-Report-Ty=
pe AVP is 0 (i.e. the host  


report).


 

This AVP is always required, right? Then, I=
 think it is more precise that  we define this AVP as mandatory.


 

--


-------------------------------------------=
----+---------------------

-------------------------------------------=
----+---


-------------------------------------------=
----+---


Reporter:  maria.cruz.bartolome@ericsson.com  |&nbs=
p;     Owner:  MCruz=



  Type:  defect   =
             &n=
bsp;            =
;|  Bartolom=E9


Priority:  major   &nbs=
p;            &=
nbsp;           &nbs=
p; |     Status:  new


Component:  draft-docdt-dime-ovli =
;             |=
  Milestone:


Severity:  Active WG Document &nb=
sp;            =
   |    Version:  1.0


       &=
nbsp;           &nbs=
p;             =
           | &n=
bsp; Keywords:


-------------------------------------------=
----+---------------------

-------------------------------------------=
----+---


-------------------------------------------=
----+---


 

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/=
ticket/54>


dime <http://tools.ietf.org/wg/dime/>


 

___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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


 

___________________________________________=
__________________________


___________________________________________=
_________


 

Ce message et ses pieces jointes peuvent co=
ntenir 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 alte=
re, deforme ou falsifie. Merci.<=
/pre>

 

This message and its attachments may contai=
n 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, p=
lease notify the sender and delete this message and its attachments.=



As emails may be altered, Orange is not lia=
ble for messages that have been modified, changed or falsified.


Thank you.


 

___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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


___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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


 

___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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


 

___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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


 

___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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


 

___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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


 

 <=
/span>




 <=
/span>


___________________________________________=
____


DiME mailing list<=
o:p>


DiME@ietf.=
org


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




 <=
/span>


 <=
/span>


 <=
/span>




 =





 =







___________________________________________=
___________________________________________________________________________=
___


 <=
/span>


Ce message et ses pieces jointes peuvent co=
ntenir des informations confidentielles ou privilegiees et ne doivent donc<=
/span>


pas etre diffuses, exploites ou copies sans=
 autorisation. Si vous avez recu ce message par erreur, veuillez le signale=
r


a l'expediteur et le detruire ainsi que les=
 pieces jointes. Les messages electroniques etant susceptibles d'alteration=
,


Orange decline toute responsabilite si ce m=
essage a ete altere, deforme ou falsifie. Merci.


 <=
/span>


This message and its attachments may contai=
n confidential or privileged information that may be protected by law;


they should not be distributed, used or cop=
ied without authorisation.


If you have received this email in error, p=
lease notify the sender and delete this message and its attachments.=



As emails may be altered, Orange is not lia=
ble for messages that have been modified, changed or falsified.


Thank you.


______________________________________________=
___________________________________________________________________________=



 


Ce message et ses pieces jointes peuvent conte=
nir des informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans au=
torisation. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pi=
eces jointes. Les messages electroniques etant susceptibles d'alteration,


Orange decline toute responsabilite si ce mess=
age a ete altere, deforme ou falsifie. Merci.=



 


This message and its attachments may contain c=
onfidential or privileged information that may be protected by law;<=
span lang=3D"FR">


they should not be distributed, used or copied=
 without authorisation.


If you have received this email in error, plea=
se 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.=





 =



____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_5BCBA1FC2B7F0B4C9D935572D9000668151D8B92DEMUMBX014nsnin_--


From nobody Thu Mar 27 07:15: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 F40A31A0720 for ; Thu, 27 Mar 2014 07:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 fl-G-UO9QrXv for ; Thu, 27 Mar 2014 07:15:40 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E261A071A for ; Thu, 27 Mar 2014 07:15:40 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s2REFaCJ094243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Mar 2014 09:15:38 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Ben Campbell 
In-Reply-To: <5332F680.9030102@usdonovans.com>
Date: Thu, 27 Mar 2014 09:15:36 -0500
X-Mao-Original-Outgoing-Id: 417622536.350549-bab3eda9534291dea97f85e9be5cd517
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> <072.6892b07263eb158352dabe97ef8b9ed4@trac.tools.ietf.org> <5332F680.9030102@usdonovans.com>
To: Steve Donovan 
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/JXR9GcYTQDlCib5DdGwQ-bPUzJw
Cc: dime@ietf.org, draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #44 (draft-docdt-dime-ovli): Incorrect sequence number behavior
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: Thu, 27 Mar 2014 14:15:42 -0000

WFM

On Mar 26, 2014, at 10:47 AM, Steve Donovan  =
wrote:

> All,
>=20
> When looking to make the change documented below, I realized that this =
wording had already been changed as a result of a previous agreed to =
change.  I haven't searched down which one, but the new wording in the =
current -02 snapshot is as following.  I believe that this is consistent =
with the proposed wording below and, as such, have not further updated =
the paragraph.
>=20
> If the value of the OC-Sequence-Number AVP contained in the received
>    OC-OLR AVP is equal to or less than the value stored in an existing
>    overload condition state, the received OC-OLR AVP SHOULD be =
silently
>    discarded.  If the value of the OC-Sequence-Number AVP contained in
>    the received OC-OLR AVP is greater than the value stored in an
>    existing overload condition state or there is no previously =
recorded
>    sequence number, the reacting node MUST update the overload =
condition
>    state associated with the realm or the specific node is the realm.
>=20
> Regards,
>=20
> Steve
> On 3/24/14 3:17 PM, dime issue tracker wrote:
>> #44: Incorrect sequence number behavior
>>=20
>> Changes (by=20
>> srdonovan@usdonovans.com
>> ):
>>=20
>>  * status:  new =3D> closed
>>  * resolution:   =3D> fixed
>>=20
>>=20
>> Comment:
>>=20
>>  Change the last sentence of section 4.3, paragraph 3 to =93The =
reacting node
>>  SHOULD discard an OC-OLR AVP with a sequence number that is less =
than or
>>  equal to the previously received sequence number.=94
>>=20
>>=20
>=20


From nobody Thu Mar 27 07:35:49 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 827DF1A068A for ; Thu, 27 Mar 2014 07:35:47 -0700 (PDT)
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 djm2LuD0lXcu for ; Thu, 27 Mar 2014 07:35:37 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id CF0441A06C1 for ; Thu, 27 Mar 2014 07:35:36 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2REZWog029900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 27 Mar 2014 09:35:34 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2REZRmS022198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 27 Mar 2014 15:35:28 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 27 Mar 2014 15:35:25 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "dime@ietf.org" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPQsn+hW8mxnR4ZUW/UfMU7zBoKJrvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeD//Jsx8ADZeeeA///qNtD//8n+gP//j8UA//7p8eD//cwccA==
Date: Thu, 27 Mar 2014 14:35:24 +0000
Message-ID: 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com> <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EF92@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D8B92@DEMUMBX014.nsn-intra.net> 
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20267B3A9FR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/MUO7rrf-93EBYrn3JcHg-O4gHEY
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 14:35:47 -0000

--_000_E194C2E18676714DACA9C3A2516265D20267B3A9FR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi

I refer to my yesterday previous mail.
People have expressed

-          A preference. On my side,  I have a preference for the existing =
text with  non mandatory  AVP. But I can accept the mandatory AVP as I alre=
ady said

-          Or a strong concern in favor of one solution, this is the case o=
f Susan. I asked if there were voice who have a strong concern  in favor of=
 the mandatory AVP .  There were was no answer up to now  and I am not awar=
e of voice with a strong concern  in favor of the mandatory .



Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : jeudi 27 mars 2014 12:53
=C0 : ext Shishufeng (Susan); lionel.morand@orange.com; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

I can accept both (though I have a slight preference in favour of Susan).
Actually I think this is a so minor minor minor issue that it  could serve =
as a very good opportunity for people to show their willingness to give in,=
 in order to make progress.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Shishufeng (Susa=
n)
Sent: Thursday, March 27, 2014 12:38 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Please see below.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 6:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Please see below.

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,


-          I'm not talking the specific optional AVPs defined in this draft=
, but others e.g. defined in 3GPP specifications. We have a lot optional AV=
Ps with default values.
[LM] in 3GPP there are introduced in existing applications and usually in c=
ommands. There is no other options to include them are purely optional.
Susan: Not exactly, we have lots of optional AVPs from the first release.


-           my understanding, some cases an AVP is needed, some cases it is=
 not needed, that's the key point to justify its optionality.
[LM] I agree that we don't have the same understanding here.


-          Apart from the benefit of less AVPs and less error cases with th=
is AVP as optional, another key point is that the server(host) will never c=
are about the AVP at all. It will never need to remember to put such an AVP=
 into the message. Only agent needs to add such an AVP in case putting into=
 realm report, this would make things much simpler from my point of view.
[LM] that is wrong to say "never". A server can have realm-based informatio=
n that can be provided to reacting nodes. It is only depending of the serve=
r implementation and environment. For instance, if a realm is entirely dedi=
cated to a type of server, a farm based implementation would provide such f=
unctionality, as discussed.
Susan: In this case the server behaves more like an agent, not a pure serve=
r, i.e. the server provides agent functionality. In IETF, server and agent =
has clear difference.

Further, the discussion on Realm is still ongoing and whether it can work w=
ell is still under investigation.
[LM] I think that the ongoing discussion is too tight to specific use cases=
, important ones for 3GPP I admit. However the whole goal of this work is t=
o have something that it will work in any case. If there are some requireme=
nts for realm-based info, I don't see a specific reason to restrict the use=
 of report type. And don't forget that new report types can be created in t=
he future. So it is not restricted to Host vs realm.
Susan: May I ask what's wrong with this not always needed AVP as optional?

The benefit to have it as optional is clear, and this would not bring any h=
arm. I hope this can be reconsidered.
[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 5:31 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore=
.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



--_000_E194C2E18676714DACA9C3A2516265D20267B3A9FR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











 <=
/p>

Hi


 <=
/p>

I refer to my yesterday p=
revious mail.


People have expressed



-  &n=
bsp;      
A preference. On =
my side,  I have a preference for the existing text with  non man=
datory  AVP. But I can accept the mandatory AVP as I already said=




-  &n=
bsp;      
Or a strong conce=
rn in favor of one solution, this is the case of Susan. I asked if there we=
re voice who have a strong concern  in favor of the mandatory
 AVP .  There were was no answer up =
to now
 and I am not aware of voice with a =
strong concern  in favor of the mandatory
.


=
 


 <=
/p>

Best regards



 <=
/p>

JJacques



 <=
/p>





De =
: DiME [mailto:dime-bounces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : jeudi 27 mars 2014 12:53

=C0 : ext Shishufeng (Susan); lionel.morand@orange.com; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


[LM] let see if the=
re are other voice that could not accept the proposed approach.<=
/b>


Susan: Ok, but to be fair=
, maybe we can also ask who could not accept this AVP as optional. As I kno=
w, Steve could live with it as optional.



 <=
/p>

I can accept both (though=
 I have a slight preference in favour of Susan).


Actually I think this is =
a so minor minor minor issue that it  could serve as a very good oppor=
tunity for people to show their willingness to give in, in order
 to make progress.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Shishufeng (Susan)

Sent: Thursday, March 27, 2014 12:38 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hello Lionel,<=
/span>


 <=
/p>

Please see below.


 <=
/p>

Best Regards,<=
/span>


Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 6:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


Please see be=
low.


 


Lionel


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lionel,<=
/span>


 <=
/p>


-  &n=
bsp;      
I’m not tal=
king the specific optional AVPs defined in this draft, but others e.g. defi=
ned in 3GPP specifications. We have a lot optional AVPs with
 default values. 


[LM] in 3GPP there =
are introduced in existing applications and usually in commands. There is n=
o other options to include them are purely optional.<=
/b>


Susan: Not exactly, we ha=
ve lots of optional AVPs from the first release.


 <=
/p>


-  &n=
bsp;      
 my understa=
nding, some cases an AVP is needed, some cases it is not needed, that’=
;s the key point to justify its optionality.


[LM] I agree that w=
e don't have the same understanding here.


 <=
/p>


-  &n=
bsp;      
Apart from the be=
nefit of less AVPs and less error cases with this AVP as optional, another =
key point is that the server(host) will never care about
 the AVP at all. It will never need to remember to put such an AVP into the=
 message. Only agent needs to add such an AVP in case putting into realm re=
port, this would make things much simpler from my point of view.



[LM] that is wrong =
to say "never". A server can have realm-based information that ca=
n be provided to reacting nodes. It is only depending of the server
 implementation and environment. For instance, if a realm is entirely dedic=
ated to a type of server, a farm based implementation would provide such fu=
nctionality, as discussed.



Susan: In this case the s=
erver behaves more like an agent, not a pure server, i.e. the server provid=
es agent functionality. In IETF, server and agent has clear
 difference.


 <=
/p>

Further, the discussion o=
n Realm is still ongoing and whether it can work well is still under invest=
igation.


[LM] I think that t=
he ongoing discussion is too tight to specific use cases, important ones fo=
r 3GPP I admit. However the whole goal of this work is to
 have something that it will work in any case. If there are some requiremen=
ts for realm-based info, I don't see a specific reason to restrict the use =
of report type. And don't forget that new report types can be created in th=
e future. So it is not restricted
 to Host vs realm.


Susan: May I ask whatR=
17;s wrong with this not always needed AVP as optional?



 <=
/p>

The benefit to have it as=
 optional is clear, and this would not bring any harm. I hope this can be r=
econsidered.


[LM] let see if the=
re are other voice that could not accept the proposed approach.<=
/b>


Susan: Ok, but to be fair=
, maybe we can also ask who could not accept this AVP as optional. As I kno=
w, Steve could live with it as optional.



 <=
/p>

Best Regards,<=
/span>


Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 5:31 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


In this specific case, th=
e info carried by the AVP is not optional. You need this info in the algori=
thm as it will modify the behavior of the reacting node.<=
/p>

The current solution is t=
o define a default value when not received.


 <=
/p>

I believe that at the pro=
tocol level, having this AVP in every request is cleaner than relying on de=
fault value when not present. The initial goal for such
 default value was to limit the number of AVPs transmitted over the interfa=
ces. And I think that it is not so relevant according to the output of the =
other discussions and such optimization is not deemed required anymore.



 <=
/p>

Moreover, the default val=
ue today would be likely "Host" but this is only based on current=
 working assumptions for some 3GPP interfaces. When used in some networks,
 Realm is perfectly valid as default value if the system is designed for th=
at. I think that AT&T and Verizon have clearly expressed their requirem=
ents for that.


 <=
/p>

This reasoning leads to c=
hange the existing for Grouped AVP from:


 


O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          [ OC=
-Report-Type ]


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



To:


 <=
/p>

O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          { OC=
-Report-Type }


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



 <=
/p>

I would like to clarify t=
hat this discussion is totally independent of the M-bit setting of the AVP.=



 <=
/p>

And about why not put the=
 other AVPs as required in the Grouped AVP, it is because it is abvious tha=
t the other ones are linked to the reduction algo defined
 in this document. For other algos, you could find other AVPs (relying on t=
he extensibility of this Grouped AVP) instead.


 <=
/p>

Let me know if the clarif=
ication is useful.


 <=
/p>

 <=
/p>

Regards,


 <=
/p>

Lionel<=
/p>

 <=
/p>





De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,


 


If you cares, please clar=
ify how this decision was made based on the newly ongoing technical discuss=
ion. I really don’t understand a useless AVP in most cases
 has to be mandatory.


 


May I ask why not define =
every optional AVP as mandatory if the only point you made decision was tha=
t it will not block anything?

 


Best Regards,


Susan


 






From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi,


 


Because it was not possib=
le to make everyone happy, I made a decision. I think that this decision is=
 valid and will not block anything.


To be fair, I think that =
the majority could accept both while few have a strong preference for optio=
nal or mandatory.  And I picked one.


Can we please discuss abo=
ut something else or is it the most critical point to solve? I think that e=
veryone is waiting for a version 02 before the end of this
 week.


 


Regards,


 


Lionel


 


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Steve,


 


Ok, let’s come back=
 with technical discussion then.=



 



-     &=
nbsp;   
First a not alway=
s needed AVP cannot justify why it shall be mandatory.




-     &=
nbsp;   
Secondly, in my v=
iew, having a not always needed AVP as mandatory cannot be less error prone=
. On the contrary, it would introduce more error cases.
 RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP 5005, D=
IAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the possible e=
rror cases. All the handling with this AVP consumes the resource of both re=
porting nodes and reacting nodes.
 I don't see any benefit to have it.


=
 


Best Regards,


Susan


 


 






From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


I disagree that the m=
ajority of individuals (companies don't apply here) have a preference. =
; We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:






Hello Lionel,


 


Thanks for your reply.


 


It is clear that majority=
 companies involved in the discussion prefer to not have this AVP as mandat=
ory. And Steve is ok with it as it is, and thus everyone
 is ok with it as optional. I’m wondering why you choose another way =
forward, and don’t take opinion from majority companies into account,=
 which is strange for me.



 


We talked much about it, =
and in some major cases, this AVP is useless. If needed, anyway an optional=
 AVP has to be present, I don’t see any problem with it.
 We did a lot like this in 3GPP spec. I don’t understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.


 


Best Regards,


Susan


 


 






From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,


 


I do care about comments =
from other but we need to move on.


 


My decision is based on t=
he following: from a technical point of view, there is no issue if we defin=
e this AVP as required. From a protocol aspect, it is cleaner
 as a report ALWAYS applies to a given type. Default value was considered a=
s sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggered this issu=
e) and myself.


 


Now, about the process, a=
 100% is not required to move forward. As it is not possible to get consens=
us on this issue, I use my prerogative to pick one solution,
 the one that seems to be the best solution at this stage, to be able to cl=
ose the discussion at this stage and produce the draft that we need.=



 


After, it is always possi=
ble to challenge again the content of the draft if there is still concern.<=
/span>


 


Benoit, the Area Director=
, is copied. It is not a putsch. Just administrative way agreed within IETF=
 to be able to move forward a WG draft, which is the ultimate
 goal of everyone I think.


 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lionel,


 


Further clarification:


 


I don’t agree with =
this, not ok to everyone as you said.


 


Best Regards,


Susan


 






From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lionel,


 


I don’t understand =
it.


 


Please clarify if you car=
e about other people’s comments.<=
/span>


 


Best Regards,


Susan


 






From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,


 


Please stop this thread for now.<=
o:p>


 


As mandatory/required is ok for everyone (even if useless =
in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9crit =
:


 






Hello Steve,


 


Thanks for clarifying the=
 IETF procedure. I’m not familiar with it, while I know the draft is =
mainly for 3GPP use, that’s why we 3GPP delegates are deeply involved
 in this specific discussion. If most of 3GPP people think it is not so nee=
ded I couldn’t understand why it shall be mandatory.


 


From technical point of v=
iew, in the case realm based report type is not needed, nothing wrong witho=
ut this AVP, and even better and cleaner.


 


And you ever said you hav=
e preference but ok with either way forward, i.e., make it mandatory or opt=
ional. Then let’s move on with the draft as it is on this
 point, if you agree. 


 


Best Regards,


Susan


 






From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:






Hi Steve,


 


As I know, majority compa=
nies expressed preference to keep the AVP as optional and keep the texts as=
 they are. You have preference to have it explicitly but
 ok with either way. That’s how I assumed we reached consensus.


 


Best Regards,


Susan


 






From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:






H=
ello Jouni,


&=
nbsp;


I=
 assume we had a lot of discussion on this and reached consensus to keep it=
 as it is in the draft. 


&=
nbsp;


B=
est Regards,


S=
usan


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: Jouni Korhonen [mailto:jouni=
.nospam@gmail.com] 


S=
ent: Saturday, March 22, 2014 10:38 AM<=
/span>


T=
o: Steve Donovan


C=
c: dime@ietf.org


S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


&=
nbsp;


&=
nbsp;


L=
ets have it explicit then. Use '<' and '>' to make the position fixed=
.


&=
nbsp;


-=
 Jouni


&=
nbsp;


O=
n Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


&=
nbsp;




I=
'm ok with either direction but generally lean toward being explicit.


&=
nbsp;


D=
o we have other opinions?  =



&=
nbsp;


S=
teve


O=
n 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




H=
ello,


I=
 think the agreement tendency is the contrary: OC-Report-Type is not requir=
ed, while default value is Host. i.e. it will remain as it is now in the dr=
aft.


T=
his may be of some advantage for some applications that may only use Host, =
as long as they may never generate Realm reports.<=
o:p>


I=
f there is consensus on this, I will go with this.=



B=
est regards


/=
MCruz


 




















--_000_E194C2E18676714DACA9C3A2516265D20267B3A9FR712WXCHMBA12z_--


From nobody Thu Mar 27 07:43: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 C820E1A06C1 for ; Thu, 27 Mar 2014 07:43:52 -0700 (PDT)
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 PGsMMxwbOT29 for ; Thu, 27 Mar 2014 07:43:50 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id D913F1A06B2 for ; Thu, 27 Mar 2014 07:43:49 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3D96A18C5E8; Thu, 27 Mar 2014 15:43:47 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1BB5E238059; Thu, 27 Mar 2014 15:43:47 +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; Thu, 27 Mar 2014 15:43:46 +0100
From: 
To: Ben Campbell , Steve Donovan 
Thread-Topic: [Dime] [dime] #44 (draft-docdt-dime-ovli): Incorrect sequence number behavior
Thread-Index: AQHPSccM2lp5E3z4602fR2jbhSI6rJr1AlYQ
Date: Thu, 27 Mar 2014 14:43:45 +0000
Message-ID: <13008_1395931427_53343923_13008_5391_1_6B7134B31289DC4FAF731D844122B36E5214FE@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <057.7c5fb5d661b97d2b4cb140cc4965cf36@trac.tools.ietf.org> <072.6892b07263eb158352dabe97ef8b9ed4@trac.tools.ietf.org> <5332F680.9030102@usdonovans.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.4]
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.27.135115
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/Ux2O20rKoeAnSUWLOXlxN5m4WT0
Cc: "dime@ietf.org" , "draft-docdt-dime-ovli@tools.ietf.org" 
Subject: Re: [Dime] [dime] #44 (draft-docdt-dime-ovli): Incorrect sequence number behavior
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: Thu, 27 Mar 2014 14:43:53 -0000

ok

-----Message d'origine-----
De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell
Envoy=E9=A0: jeudi 27 mars 2014 15:16
=C0=A0: Steve Donovan
Cc=A0: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Objet=A0: Re: [Dime] [dime] #44 (draft-docdt-dime-ovli): Incorrect sequence=
 number behavior

WFM

On Mar 26, 2014, at 10:47 AM, Steve Donovan  wrot=
e:

> All,
>=20
> When looking to make the change documented below, I realized that this wo=
rding had already been changed as a result of a previous agreed to change. =
 I haven't searched down which one, but the new wording in the current -02 =
snapshot is as following.  I believe that this is consistent with the propo=
sed wording below and, as such, have not further updated the paragraph.
>=20
> If the value of the OC-Sequence-Number AVP contained in the received
>    OC-OLR AVP is equal to or less than the value stored in an existing
>    overload condition state, the received OC-OLR AVP SHOULD be silently
>    discarded.  If the value of the OC-Sequence-Number AVP contained in
>    the received OC-OLR AVP is greater than the value stored in an
>    existing overload condition state or there is no previously recorded
>    sequence number, the reacting node MUST update the overload condition
>    state associated with the realm or the specific node is the realm.
>=20
> Regards,
>=20
> Steve
> On 3/24/14 3:17 PM, dime issue tracker wrote:
>> #44: Incorrect sequence number behavior
>>=20
>> Changes (by=20
>> srdonovan@usdonovans.com
>> ):
>>=20
>>  * status:  new =3D> closed
>>  * resolution:   =3D> fixed
>>=20
>>=20
>> Comment:
>>=20
>>  Change the last sentence of section 4.3, paragraph 3 to "The reacting n=
ode
>>  SHOULD discard an OC-OLR AVP with a sequence number that is less than or
>>  equal to the previously received sequence number."
>>=20
>>=20
>=20

_______________________________________________
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 Thu Mar 27 08:13: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 AE5281A0707 for ; Thu, 27 Mar 2014 07:27:10 -0700 (PDT)
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 3PC_pRwlSkdT for ; Thu, 27 Mar 2014 07:26:56 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 535EC1A0744 for ; Thu, 27 Mar 2014 07:26:53 -0700 (PDT)
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 s2REQCDk001262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 27 Mar 2014 09:26:13 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2REQ9sT027304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 27 Mar 2014 15:26:10 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 27 Mar 2014 15:26:10 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" 
To: "Wiehe, Ulrich (NSN - DE/Munich)" , "ext Shishufeng (Susan)" , "lionel.morand@orange.com" , Steve Donovan , "Jouni Korhonen" 
Thread-Topic: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
Thread-Index: AQHPQsn+hW8mxnR4ZUW/UfMU7zBoKJrvnpVggAAIHgCAAbwsIP//2cWAgAGGpGD//6iMAIAAiQOg//99GVAAAQlQAAARdy8Q///D9QD//3OVcIAApYqA//5hYeD//Jsx8ADZeeeA///qNtD//8n+gP//j8UA//7p8eA=
Date: Thu, 27 Mar 2014 14:26:09 +0000
Message-ID: 
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com> <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EF92@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D8B92@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D8B92@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.239.27.41]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D20267B38EFR712WXCHMBA12z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/vyTFRA-elOWNznyG5_aok_jEfa8
X-Mailman-Approved-At: Thu, 27 Mar 2014 08:13:07 -0700
Cc: "dime@ietf.org" 
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP
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: Thu, 27 Mar 2014 14:27:10 -0000

--_000_E194C2E18676714DACA9C3A2516265D20267B38EFR712WXCHMBA12z_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I refer to my yesterday previous mail.
People have expressed

-          A preference. On my side,  I have a preference for the existing =
text with  non mandatory  AVP. But I can accept the mandatory AVP as I alre=
ady said

-          Or a strong concern in favor of one solution, this is the case o=
f Susan. I asked if there were voice who have a strong concern  in favor of=
 the mandatory AVP .  There were was no answer and I am not aware of voice =
with a strong concern  in favor of the mandatory .



Best regards

JJacques

De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN -=
 DE/Munich)
Envoy=E9 : jeudi 27 mars 2014 12:53
=C0 : ext Shishufeng (Susan); lionel.morand@orange.com; Steve Donovan; Joun=
i Korhonen
Cc : dime@ietf.org
Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

I can accept both (though I have a slight preference in favour of Susan).
Actually I think this is a so minor minor minor issue that it  could serve =
as a very good opportunity for people to show their willingness to give in,=
 in order to make progress.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Shishufeng (Susa=
n)
Sent: Thursday, March 27, 2014 12:38 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Please see below.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 6:32 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

Please see below.

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 11:04
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,


-          I'm not talking the specific optional AVPs defined in this draft=
, but others e.g. defined in 3GPP specifications. We have a lot optional AV=
Ps with default values.
[LM] in 3GPP there are introduced in existing applications and usually in c=
ommands. There is no other options to include them are purely optional.
Susan: Not exactly, we have lots of optional AVPs from the first release.


-           my understanding, some cases an AVP is needed, some cases it is=
 not needed, that's the key point to justify its optionality.
[LM] I agree that we don't have the same understanding here.


-          Apart from the benefit of less AVPs and less error cases with th=
is AVP as optional, another key point is that the server(host) will never c=
are about the AVP at all. It will never need to remember to put such an AVP=
 into the message. Only agent needs to add such an AVP in case putting into=
 realm report, this would make things much simpler from my point of view.
[LM] that is wrong to say "never". A server can have realm-based informatio=
n that can be provided to reacting nodes. It is only depending of the serve=
r implementation and environment. For instance, if a realm is entirely dedi=
cated to a type of server, a farm based implementation would provide such f=
unctionality, as discussed.
Susan: In this case the server behaves more like an agent, not a pure serve=
r, i.e. the server provides agent functionality. In IETF, server and agent =
has clear difference.

Further, the discussion on Realm is still ongoing and whether it can work w=
ell is still under investigation.
[LM] I think that the ongoing discussion is too tight to specific use cases=
, important ones for 3GPP I admit. However the whole goal of this work is t=
o have something that it will work in any case. If there are some requireme=
nts for realm-based info, I don't see a specific reason to restrict the use=
 of report type. And don't forget that new report types can be created in t=
he future. So it is not restricted to Host vs realm.
Susan: May I ask what's wrong with this not always needed AVP as optional?

The benefit to have it as optional is clear, and this would not bring any h=
arm. I hope this can be reconsidered.
[LM] let see if there are other voice that could not accept the proposed ap=
proach.
Susan: Ok, but to be fair, maybe we can also ask who could not accept this =
AVP as optional. As I know, Steve could live with it as optional.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Thursday, March 27, 2014 5:31 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

In this specific case, the info carried by the AVP is not optional. You nee=
d this info in the algorithm as it will modify the behavior of the reacting=
 node.
The current solution is to define a default value when not received.

I believe that at the protocol level, having this AVP in every request is c=
leaner than relying on default value when not present. The initial goal for=
 such default value was to limit the number of AVPs transmitted over the in=
terfaces. And I think that it is not so relevant according to the output of=
 the other discussions and such optimization is not deemed required anymore=
.

Moreover, the default value today would be likely "Host" but this is only b=
ased on current working assumptions for some 3GPP interfaces. When used in =
some networks, Realm is perfectly valid as default value if the system is d=
esigned for that. I think that AT&T and Verizon have clearly expressed thei=
r requirements for that.

This reasoning leads to change the existing for Grouped AVP from:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]
To:


OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]

I would like to clarify that this discussion is totally independent of the =
M-bit setting of the AVP.

And about why not put the other AVPs as required in the Grouped AVP, it is =
because it is abvious that the other ones are linked to the reduction algo =
defined in this document. For other algos, you could find other AVPs (relyi=
ng on the extensibility of this Grouped AVP) instead.

Let me know if the clarification is useful.


Regards,

Lionel

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : jeudi 27 mars 2014 07:38
=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Lionel,

If you cares, please clarify how this decision was made based on the newly =
ongoing technical discussion. I really don't understand a useless AVP in mo=
st cases has to be mandatory.

May I ask why not define every optional AVP as mandatory if the only point =
you made decision was that it will not block anything?

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 9:50 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi,

Because it was not possible to make everyone happy, I made a decision. I th=
ink that this decision is valid and will not block anything.
To be fair, I think that the majority could accept both while few have a st=
rong preference for optional or mandatory.  And I picked one.
Can we please discuss about something else or is it the most critical point=
 to solve? I think that everyone is waiting for a version 02 before the end=
 of this week.

Regards,

Lionel


De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 13:53
=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen
Cc : dime@ietf.org; Benoit Claise
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Steve,

Ok, let's come back with technical discussion then.


-          First a not always needed AVP cannot justify why it shall be man=
datory.

-          Secondly, in my view, having a not always needed AVP as mandator=
y cannot be less error prone. On the contrary, it would introduce more erro=
r cases. RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP=
 5005, DIAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the po=
ssible error cases. All the handling with this AVP consumes the resource of=
 both reporting nodes and reacting nodes. I don't see any benefit to have i=
t.


Best Regards,
Susan


From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Wednesday, March 26, 2014 8:21 PM
To: Shishufeng (Susan); lionel.morand@orange.com; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

I disagree that the majority of individuals (companies don't apply here) ha=
ve a preference.  We have not established the view of a majority.

If we took a vote of individuals on this, I would vote for making it explic=
it.

I also support Lionel being able to make a decision.  We all need to be fle=
xible enough to accept that decision, especially when there is no technical=
 reason to disagree with the decision.

Steve
On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:
Hello Lionel,

Thanks for your reply.

It is clear that majority companies involved in the discussion prefer to no=
t have this AVP as mandatory. And Steve is ok with it as it is, and thus ev=
eryone is ok with it as optional. I'm wondering why you choose another way =
forward, and don't take opinion from majority companies into account, which=
 is strange for me.

We talked much about it, and in some major cases, this AVP is useless. If n=
eeded, anyway an optional AVP has to be present, I don't see any problem wi=
th it. We did a lot like this in 3GPP spec. I don't understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.

Best Regards,
Susan


From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 3:35 PM
To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen
Cc: dime@ietf.org; Benoit Claise
Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hi Susan,

I do care about comments from other but we need to move on.

My decision is based on the following: from a technical point of view, ther=
e is no issue if we define this AVP as required. From a protocol aspect, it=
 is cleaner as a report ALWAYS applies to a given type. Default value was c=
onsidered as sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggere=
d this issue) and myself.

Now, about the process, a 100% is not required to move forward. As it is no=
t possible to get consensus on this issue, I use my prerogative to pick one=
 solution, the one that seems to be the best solution at this stage, to be =
able to close the discussion at this stage and produce the draft that we ne=
ed.

After, it is always possible to challenge again the content of the draft if=
 there is still concern.

Benoit, the Area Director, is copied. It is not a putsch. Just administrati=
ve way agreed within IETF to be able to move forward a WG draft, which is t=
he ultimate goal of everyone I think.

Regards,

Lionel.

De : Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Envoy=E9 : mercredi 26 mars 2014 08:06
=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korho=
nen
Cc : dime@ietf.org
Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

Further clarification:

I don't agree with this, not ok to everyone as you said.

Best Regards,
Susan

From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]
Sent: Wednesday, March 26, 2014 2:56 PM
To: lionel.morand@orange.com; Steve Donova=
n; Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Hello Lionel,

I don't understand it.

Please clarify if you care about other people's comments.

Best Regards,
Susan

From: lionel.morand@orange.com [mailto:lio=
nel.morand@orange.com]
Sent: Wednesday, March 26, 2014 2:44 PM
To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


As chair and temporary doc shepherd,



Please stop this thread for now.



As mandatory/required is ok for everyone (even if useless in certain case),=
 let use it for now.



Lionel





"Shishufeng (Susan)" > a =E9crit :


Hello Steve,

Thanks for clarifying the IETF procedure. I'm not familiar with it, while I=
 know the draft is mainly for 3GPP use, that's why we 3GPP delegates are de=
eply involved in this specific discussion. If most of 3GPP people think it =
is not so needed I couldn't understand why it shall be mandatory.

>From technical point of view, in the case realm based report type is not ne=
eded, nothing wrong without this AVP, and even better and cleaner.

And you ever said you have preference but ok with either way forward, i.e.,=
 make it mandatory or optional. Then let's move on with the draft as it is =
on this point, if you agree.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Tuesday, March 25, 2014 8:39 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that, in =
the IETF, companies do not contribute, individuals contribute.

In addition, if we did take a "vote" on this one, I'm not sure which side w=
ould actually have a majority.

We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that this =
doesn't mean everyone agrees with the technical reasoning behind the decisi=
on.  There have been many cases where agreement is reached because it was m=
ore important to get something finished then to win a technical argument.

If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  Howev=
er, in the IETF, even this is not a voting process.  If things are close to=
 50-50 in opinions then the correct process is to continue to discuss the t=
echnical merits of each alternative until rough consensus is reached.

Regards,

Steve
On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:
Hi Steve,

As I know, majority companies expressed preference to keep the AVP as optio=
nal and keep the texts as they are. You have preference to have it explicit=
ly but ok with either way. That's how I assumed we reached consensus.

Best Regards,
Susan

From: Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Monday, March 24, 2014 8:26 PM
To: Shishufeng (Susan); Jouni Korhonen
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP

Susan,

We are in the middle of the discussion and have not yet reached consensus.

I agree with Jouni on making it explicit.  Either way, we should try to mak=
e a decision quickly.

Steve
On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:

Hello Jouni,



I assume we had a lot of discussion on this and reached consensus to keep i=
t as it is in the draft.



Best Regards,

Susan





-----Original Message-----

From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Saturday, March 22, 2014 10:38 AM

To: Steve Donovan

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP





Lets have it explicit then. Use '<' and '>' to make the position fixed.



- Jouni



On Mar 19, 2014, at 1:29 AM, Steve Donovan  wrote:



I'm ok with either direction but generally lean toward being explicit.



Do we have other opinions?



Steve

On 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:

Hello,

I think the agreement tendency is the contrary: OC-Report-Type is not requi=
red, while default value is Host. i.e. it will remain as it is now in the d=
raft.

This may be of some advantage for some applications that may only use Host,=
 as long as they may never generate Realm reports.

If there is consensus on this, I will go with this.

Best regards

/MCruz



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan

Sent: martes, 18 de marzo de 2014 17:47

To: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



All,



Do we have consensus that the OC-Report-Type AVP is required?



If so then one change would be as indicated in the syntax definition propos=
ed by Lionel.  We would also remove wording on the default value.



Jouni,



How do we indicate a fixed position for an AVP?



I presonally don't see this as critical but we can add this requirement if =
there is consensus.



Regards,



Steve



On 2/28/14 10:27 AM, Jouni Korhonen wrote:



Hi,



How having the AVP could be less error prone if it has a default

value and the receiver knows exactly how to proceed when the AVP is

not present?



If a node does not include it when it should, the implementation is

broken. Wouldn't a broken node be able to put wrong report type into

the AVP even if the AVP is mandatory?



Anyway, if it is my statement keeping issue #54 still open, consider

it resolved from my side. I am OK making the OC-Report-Type AVP as

required/mandatory AVP. Should we also consider it having a fixed

position just after the OC-Sequence-Number AVP as well since it is

going to in every OC-OLR?



- Jouni







On Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome  wrote:





Hello all,



I understand JJ point of view, but I still tend to prefer to make it mandat=
ory, since I think this is less error-prone, since the only node that knows=
 the requested Report-Type is the reporting, if for any reason a reporting =
is omitting it (since it is optional), it will be always interpreted as HOS=
T, but this type may be wrong.



I think DEFAULT values should never be error-prone, but used in "general ca=
ses", as a simplification, like e.g. a default for the Validity-Duration. D=
efault Validity-Duration will never be an "error", it could be not the best=
 value (compared with another value perfectly tuned to reporting node overl=
oad situation) but never the use of a Default value should lead to an erron=
eous behavior.



Best regards

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Ben Campbell

Sent: viernes, 14 de febrero de 2014 23:13

To: Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP



I actually prefer making it mandatory. The cost of adding it is trivial--ev=
en more so for a reporting node that only supports the default. The value o=
f having it is less opportunity for interop errors.



On Feb 13, 2014, at 6:05 AM, Jouni Korhonen  wrote:





Agree that it is a small optimization, which I put there because at

the beginning there seemed to be a lot of worry on every extra AVP

;-)



I prefer having the AVP optional but with a default value just like

it is now. We have the same for the reduction percentage and the

validity time as well.



- Jouni



On Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)"  wrote:



Hi Mcruz



The current description indicates that when not present the OLR is of type =
Host, which was fine for me and keeps my preference.

We may have  deployments where Realm OLR is not used, or where statisticall=
y the HOST type is the most frequent, so to have the grouped OLR-AVP contai=
ning a minimum of AVPs minimizes parsing. I agree it is a small optimizatio=
n.



Best regards



JJacques









-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de

lionel.morand@orange.com Envoy=E9 : mercre=
di 12 f=E9vrier 2014 15:46 =C0 :

dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : Re: [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



Hi Maria Cruz,



I'm assuming that you mean "required" instead of "mandatory", right?



So instead of:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           [ OC-Report-Type ]

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



You would prefer:



OC-OLR ::=3D < AVP Header: TBD2 >

           < OC-Sequence-Number >

           { OC-Report-Type }

           [ OC-Reduction-Percentage ]

           [ OC-Validity-Duration ]

         * [ AVP ]



And I'm fine with this proposal.



Cheers,



Lionel



-----Message d'origine-----

De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue

tracker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :

maria.cruz.bartolome@ericsson.com=
 Cc : dime@ietf.org Objet : [Dime]

[dime] #54: OC-Report-Type as mandatory AVP



#54: OC-Report-Type as mandatory AVP



Now in chapter 4.6:



 The default value of the OC-Report-Type AVP is 0 (i.e. the host

report).



This AVP is always required, right? Then, I think it is more precise that  =
we define this AVP as mandatory.



--

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---

Reporter:  maria.cruz.bartolome@ericsson.com  |      Owner:  MCruz

  Type:  defect                             |  Bartolom=E9

Priority:  major                              |     Status:  new

Component:  draft-docdt-dime-ovli              |  Milestone:

Severity:  Active WG Document                 |    Version:  1.0

                                            |   Keywords:

-----------------------------------------------+---------------------

-----------------------------------------------+---

-----------------------------------------------+---



Ticket URL: 

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. Le=
s messages electroniques etant susceptibles d'alteration, Orange decline to=
ute 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



_______________________________________________

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.

___________________________________________________________________________=
______________________________________________



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.


___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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.

___________________________________________________________________________=
______________________________________________



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_E194C2E18676714DACA9C3A2516265D20267B38EFR712WXCHMBA12z_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable











Hi


 <=
/p>

I refer to my yesterday p=
revious mail.


People have expressed



-  &n=
bsp;      
A preference. On =
my side,  I have a preference for the existing text with  non man=
datory  AVP. But I can accept the mandatory AVP as I already said=




-  &n=
bsp;      
Or a strong conce=
rn in favor of one solution, this is the case of Susan. I asked if there we=
re voice who have a strong concern  in favor of the mandatory
 AVP .  There were was no answer and I am not aware of voice with a st=
rong concern  in favor of the mandatory
.


=
 


 <=
/p>

Best regards



 <=
/p>

JJacques



 <=
/p>





De =
: DiME [mailto:dime-bou=
nces@ietf.org]
De la part de Wiehe, Ulrich (NSN - DE/Munich)

Envoy=E9 : jeudi 27 mars 2014 12:53

=C0 : ext Shishufeng (Susan); lionel.morand@orange.com; Steve D=
onovan; Jouni Korhonen

Cc : dime@ietf.org

Objet : Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


[LM] let see if the=
re are other voice that could not accept the proposed approach.<=
/b>


Susan: Ok, but to be fair=
, maybe we can also ask who could not accept this AVP as optional. As I kno=
w, Steve could live with it as optional.



 <=
/p>

I can accept both (though=
 I have a slight preference in favour of Susan).


Actually I think this is =
a so minor minor minor issue that it  could serve as a very good oppor=
tunity for people to show their willingness to give in, in order
 to make progress.


 <=
/p>

Ulrich<=
/p>

 <=
/p>





From: DiME [ma=
ilto:dime-bounces@ietf.org]
On Behalf Of ext Shishufeng (Susan)

Sent: Thursday, March 27, 2014 12:38 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hello Lionel,<=
/span>


 <=
/p>

Please see below.


 <=
/p>

Best Regards,<=
/span>


Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 6:32 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


Please see be=
low.


 


Lionel


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 11:04

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hello Lionel,<=
/span>


 <=
/p>


-  &n=
bsp;      
I’m not tal=
king the specific optional AVPs defined in this draft, but others e.g. defi=
ned in 3GPP specifications. We have a lot optional AVPs with
 default values. 


[LM] in 3GPP there =
are introduced in existing applications and usually in commands. There is n=
o other options to include them are purely optional.<=
/b>


Susan: Not exactly, we ha=
ve lots of optional AVPs from the first release.


 <=
/p>


-  &n=
bsp;      
 my understa=
nding, some cases an AVP is needed, some cases it is not needed, that’=
;s the key point to justify its optionality.


[LM] I agree that w=
e don't have the same understanding here.


 <=
/p>


-  &n=
bsp;      
Apart from the be=
nefit of less AVPs and less error cases with this AVP as optional, another =
key point is that the server(host) will never care about
 the AVP at all. It will never need to remember to put such an AVP into the=
 message. Only agent needs to add such an AVP in case putting into realm re=
port, this would make things much simpler from my point of view.



[LM] that is wrong =
to say "never". A server can have realm-based information that ca=
n be provided to reacting nodes. It is only depending of the server
 implementation and environment. For instance, if a realm is entirely dedic=
ated to a type of server, a farm based implementation would provide such fu=
nctionality, as discussed.



Susan: In this case the s=
erver behaves more like an agent, not a pure server, i.e. the server provid=
es agent functionality. In IETF, server and agent has clear
 difference.


 <=
/p>

Further, the discussion o=
n Realm is still ongoing and whether it can work well is still under invest=
igation.


[LM] I think that t=
he ongoing discussion is too tight to specific use cases, important ones fo=
r 3GPP I admit. However the whole goal of this work is to
 have something that it will work in any case. If there are some requiremen=
ts for realm-based info, I don't see a specific reason to restrict the use =
of report type. And don't forget that new report types can be created in th=
e future. So it is not restricted
 to Host vs realm.


Susan: May I ask whatR=
17;s wrong with this not always needed AVP as optional?



 <=
/p>

The benefit to have it as=
 optional is clear, and this would not bring any harm. I hope this can be r=
econsidered.


[LM] let see if the=
re are other voice that could not accept the proposed approach.<=
/b>


Susan: Ok, but to be fair=
, maybe we can also ask who could not accept this AVP as optional. As I kno=
w, Steve could live with it as optional.



 <=
/p>

Best Regards,<=
/span>


Susan

 <=
/p>





From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Thursday, March 27, 2014 5:31 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP=







 


Hi Susan,


 


In this specific case, th=
e info carried by the AVP is not optional. You need this info in the algori=
thm as it will modify the behavior of the reacting node.<=
/p>

The current solution is t=
o define a default value when not received.


 <=
/p>

I believe that at the pro=
tocol level, having this AVP in every request is cleaner than relying on de=
fault value when not present. The initial goal for such
 default value was to limit the number of AVPs transmitted over the interfa=
ces. And I think that it is not so relevant according to the output of the =
other discussions and such optimization is not deemed required anymore.



 <=
/p>

Moreover, the default val=
ue today would be likely "Host" but this is only based on current=
 working assumptions for some 3GPP interfaces. When used in some networks,
 Realm is perfectly valid as default value if the system is designed for th=
at. I think that AT&T and Verizon have clearly expressed their requirem=
ents for that.


 <=
/p>

This reasoning leads to c=
hange the existing for Grouped AVP from:


 


O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          [ OC=
-Report-Type ]


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



To:


 <=
/p>

O=
C-OLR ::=3D < AVP Header: TBD2 >


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          { OC=
-Report-Type }


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]=



 <=
/p>

I would like to clarify t=
hat this discussion is totally independent of the M-bit setting of the AVP.=



 <=
/p>

And about why not put the=
 other AVPs as required in the Grouped AVP, it is because it is abvious tha=
t the other ones are linked to the reduction algo defined
 in this document. For other algos, you could find other AVPs (relying on t=
he extensibility of this Grouped AVP) instead.


 <=
/p>

Let me know if the clarif=
ication is useful.


 <=
/p>

 <=
/p>

Regards,


 <=
/p>

Lionel<=
/p>

 <=
/p>





De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : jeudi 27 mars 2014 07:38

=C0 : MORAND Lionel IMT/OLN; Steve Donovan; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
o:p>






 


Hi Lionel,


 


If you cares, please clar=
ify how this decision was made based on the newly ongoing technical discuss=
ion. I really don’t understand a useless AVP in most cases
 has to be mandatory.


 


May I ask why not define =
every optional AVP as mandatory if the only point you made decision was tha=
t it will not block anything?

 


Best Regards,


Susan


 






From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 9:50 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi,


 


Because it was not possib=
le to make everyone happy, I made a decision. I think that this decision is=
 valid and will not block anything.


To be fair, I think that =
the majority could accept both while few have a strong preference for optio=
nal or mandatory.  And I picked one.


Can we please discuss abo=
ut something else or is it the most critical point to solve? I think that e=
veryone is waiting for a version 02 before the end of this
 week.


 


Regards,


 


Lionel


 


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 13:53

=C0 : Steve Donovan; MORAND Lionel IMT/OLN; Jouni Korhonen

Cc : dime@ietf.org; Benoit=
 Claise

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Steve,


 


Ok, let’s come back=
 with technical discussion then.=



 



-     &=
nbsp;   
First a not alway=
s needed AVP cannot justify why it shall be mandatory.




-     &=
nbsp;   
Secondly, in my v=
iew, having a not always needed AVP as mandatory cannot be less error prone=
. On the contrary, it would introduce more error cases.
 RFC 6733 defines a couple of error codes e.g. DIAMETER_MISSING_AVP 5005, D=
IAMETER_INVALID_AVP_VALUE 5004 and maybe others to deal with the possible e=
rror cases. All the handling with this AVP consumes the resource of both re=
porting nodes and reacting nodes.
 I don't see any benefit to have it.


=
 


Best Regards,


Susan


 


 






From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Wednesday, March 26, 2014 8:21 PM

To: Shishufeng (Susan); =
lionel.morand@orange.com; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


I disagree that the m=
ajority of individuals (companies don't apply here) have a preference. =
; We have not established the view of a majority.



If we took a vote of individuals on this, I would vote for making it explic=
it.  



I also support Lionel being able to make a decision.  We all need to b=
e flexible enough to accept that decision, especially when there is no tech=
nical reason to disagree with the decision.



Steve




On 3/26/14 3:03 AM, Shishufeng (Susan) wrote:






Hello Lionel,


 


Thanks for your reply.


 


It is clear that majority=
 companies involved in the discussion prefer to not have this AVP as mandat=
ory. And Steve is ok with it as it is, and thus everyone
 is ok with it as optional. I’m wondering why you choose another way =
forward, and don’t take opinion from majority companies into account,=
 which is strange for me.



 


We talked much about it, =
and in some major cases, this AVP is useless. If needed, anyway an optional=
 AVP has to be present, I don’t see any problem with it.
 We did a lot like this in 3GPP spec. I don’t understand how in this =
case it shall be mandatory if you also agree that it is not needed in some =
cases.


 


Best Regards,


Susan


 


 






From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 3:35 PM

To: Shishufeng (Susan); Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org; Benoit Clais=
e

Subject: RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hi Susan,


 


I do care about comments =
from other but we need to move on.


 


My decision is based on t=
he following: from a technical point of view, there is no issue if we defin=
e this AVP as required. From a protocol aspect, it is cleaner
 as a report ALWAYS applies to a given type. Default value was considered a=
s sub-optimal by Jouni, Ben, Steve, Maria Cruz (who has triggered this issu=
e) and myself.


 


Now, about the process, a=
 100% is not required to move forward. As it is not possible to get consens=
us on this issue, I use my prerogative to pick one solution,
 the one that seems to be the best solution at this stage, to be able to cl=
ose the discussion at this stage and produce the draft that we need.=



 


After, it is always possi=
ble to challenge again the content of the draft if there is still concern.<=
/span>


 


Benoit, the Area Director=
, is copied. It is not a putsch. Just administrative way agreed within IETF=
 to be able to move forward a WG draft, which is the ultimate
 goal of everyone I think.


 


Regards,


 


Lionel.


 






De =
: Shishufeng (Susan) [<=
a href=3D"mailto:susan.shishufeng@huawei.com">mailto:susan.shishufeng@huawe=
i.com]


Envoy=E9 : mercredi 26 mars 2014 08:06

=C0 : Shishufeng (Susan); MORAND Lionel IMT/OLN; Steve Donovan;=
 Jouni Korhonen

Cc : dime@ietf.org

Objet : RE: [Dime] [dime] #54: OC-Report-Type as mandatory AVP<=
/span>






 


Hello Lionel,


 


Further clarification:


 


I don’t agree with =
this, not ok to everyone as you said.


 


Best Regards,


Susan


 






From: Shishufeng (Susan) [mailto:susan.shishufeng@huawei.com]


Sent: Wednesday, March 26, 2014 2:56 PM

To: lionel.morand@orange=
.com; Steve Donovan; Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Hello Lionel,


 


I don’t understand =
it.


 


Please clarify if you car=
e about other people’s comments.<=
/span>


 


Best Regards,


Susan


 






From:
lionel.morand@orange.com [<=
a href=3D"mailto:lionel.morand@orange.com">mailto:lionel.morand@orange.com<=
/a>]


Sent: Wednesday, March 26, 2014 2:44 PM

To: Steve Donovan; Jouni Korhonen; Shishufeng (Susan)

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


As chair and temporary doc shepherd,


 


Please stop this thread for now.<=
o:p>


 


As mandatory/required is ok for everyone (even if useless =
in certain case), let use it for now.


 


Lionel 


 


 


"Shishufeng (Susan)" <susan.shishufeng@huawei.com> a =E9crit =
:


 






Hello Steve,


 


Thanks for clarifying the=
 IETF procedure. I’m not familiar with it, while I know the draft is =
mainly for 3GPP use, that’s why we 3GPP delegates are deeply involved
 in this specific discussion. If most of 3GPP people think it is not so nee=
ded I couldn’t understand why it shall be mandatory.


 


From technical point of v=
iew, in the case realm based report type is not needed, nothing wrong witho=
ut this AVP, and even better and cleaner.


 


And you ever said you hav=
e preference but ok with either way forward, i.e., make it mandatory or opt=
ional. Then let’s move on with the draft as it is on this
 point, if you agree. 


 


Best Regards,


Susan


 






From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Tuesday, March 25, 2014 8:39 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We have not been following a process of determining consensus based on a ma=
jority of companies expressing a preference.  It is also the case that=
, in the IETF, companies do not contribute, individuals contribute.



In addition, if we did take a "vote" on this one, I'm not sure wh=
ich side would actually have a majority.



We might need to change our process to speed things up, but right now we ha=
ve been striving for true consensus where everyone agrees.  Note that =
this doesn't mean everyone agrees with the technical reasoning behind the d=
ecision.  There have been many cases
 where agreement is reached because it was more important to get something =
finished then to win a technical argument.



If we can't start moving a little faster then we will likely need to change=
 to rough consensus, where the measure is that most everyone agrees.  =
However, in the IETF, even this is not a voting process.  If things ar=
e close to 50-50 in opinions then the correct
 process is to continue to discuss the technical merits of each alternative=
 until rough consensus is reached.



Regards,



Steve




On 3/25/14, 2:00 AM, Shishufeng (Susan) wrote:






Hi Steve,


 


As I know, majority compa=
nies expressed preference to keep the AVP as optional and keep the texts as=
 they are. You have preference to have it explicitly but
 ok with either way. That’s how I assumed we reached consensus.


 


Best Regards,


Susan


 






From: Steve Donovan [mailto:srdonovan@usdonovans.com]


Sent: Monday, March 24, 2014 8:26 PM

To: Shishufeng (Susan); Jouni Korhonen

Cc: dime@ietf.org

Subject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP






 


Susan,



We are in the middle of the discussion and have not yet reached consensus.<=
br>


I agree with Jouni on making it explicit.  Either way, we should try t=
o make a decision quickly.



Steve




On 3/23/14 10:59 PM, Shishufeng (Susan) wrote:






H=
ello Jouni,


&=
nbsp;


I=
 assume we had a lot of discussion on this and reached consensus to keep it=
 as it is in the draft. 


&=
nbsp;


B=
est Regards,


S=
usan


&=
nbsp;


&=
nbsp;


-=
----Original Message-----


F=
rom: Jouni Korhonen [mailto:jouni=
.nospam@gmail.com] 


S=
ent: Saturday, March 22, 2014 10:38 AM<=
/span>


T=
o: Steve Donovan


C=
c: dime@ietf.org


S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


&=
nbsp;


&=
nbsp;


L=
ets have it explicit then. Use '<' and '>' to make the position fixed=
.


&=
nbsp;


-=
 Jouni


&=
nbsp;


O=
n Mar 19, 2014, at 1:29 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:


&=
nbsp;




I=
'm ok with either direction but generally lean toward being explicit.


&=
nbsp;


D=
o we have other opinions?  =



&=
nbsp;


S=
teve


O=
n 3/18/14 12:16 PM, Maria Cruz Bartolome wrote:




H=
ello,


I=
 think the agreement tendency is the contrary: OC-Report-Type is not requir=
ed, while default value is Host. i.e. it will remain as it is now in the dr=
aft.


T=
his may be of some advantage for some applications that may only use Host, =
as long as they may never generate Realm reports.<=
o:p>


I=
f there is consensus on this, I will go with this.=



B=
est regards


/=
MCruz


 


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Steve Donovan


S=
ent: martes, 18 de marzo de 2014 17:47<=
/span>


T=
o: dime@ietf.org


S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


 


A=
ll,


&=
nbsp;


D=
o we have consensus that the OC-Report-Type AVP is required?


&=
nbsp;


I=
f so then one change would be as indicated in the syntax definition propose=
d by Lionel.  We would also remove wording on the default value.


&=
nbsp;


J=
ouni,


&=
nbsp;


H=
ow do we indicate a fixed position for an AVP?  


&=
nbsp;


I=
 presonally don't see this as critical but we can add this requirement if t=
here is consensus.


&=
nbsp;


R=
egards,


&=
nbsp;


S=
teve


&=
nbsp;


O=
n 2/28/14 10:27 AM, Jouni Korhonen wrote:


 


H=
i,


 


H=
ow having the AVP could be less error prone if it has a default 


v=
alue and the receiver knows exactly how to proceed when the AVP is <=
span lang=3D"FR">


n=
ot present?


 


I=
f a node does not include it when it should, the implementation is <=
span lang=3D"FR">


b=
roken. Wouldn't a broken node be able to put wrong report type into =



t=
he AVP even if the AVP is mandatory?


 


A=
nyway, if it is my statement keeping issue #54 still open, consider =



i=
t resolved from my side. I am OK making the OC-Report-Type AVP as 


r=
equired/mandatory AVP. Should we also consider it having a fixed 


p=
osition just after the OC-Sequence-Number AVP as well since it is 


g=
oing to in every OC-OLR?


 


-=
 Jouni


 


&=
nbsp;


&=
nbsp;


O=
n Feb 21, 2014, at 11:47 AM, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> w=
rote:


 


&=
nbsp;


H=
ello all,


 


I=
 understand JJ point of view, but I still tend to prefer to make it mandato=
ry, since I think this is less error-prone, since the only node that knows =
the requested Report-Type is the reporting, if for any reason a reporting i=
s omitting it (since it is optional), it will be always interpreted as HOST=
, but this type may be wrong.

 


I=
 think DEFAULT values should never be error-prone, but used in "genera=
l cases", as a simplification, like e.g. a default for the Validity-Du=
ration. Default Validity-Duration will never be an "error", it co=
uld be not the best value (compared with another value perfectly tuned to r=
eporting node overload situation) but never the use of a Default value shou=
ld lead to an erroneous behavior.


 


B=
est regards


/=
MCruz


 


-=
----Original Message-----


F=
rom: DiME [mailto:dime-bounces@iet=
f.org] On Behalf Of Ben Campbell


S=
ent: viernes, 14 de febrero de 2014 23:13


T=
o: Jouni Korhonen


C=
c: dime@ietf.org


S=
ubject: Re: [Dime] [dime] #54: OC-Report-Type as mandatory AVP


 


I=
 actually prefer making it mandatory. The cost of adding it is trivial--eve=
n more so for a reporting node that only supports the default. The value of=
 having it is less opportunity for interop errors.=



 


O=
n Feb 13, 2014, at 6:05 AM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


 


&=
nbsp;


A=
gree that it is a small optimization, which I put there because at <=
span lang=3D"FR">


t=
he beginning there seemed to be a lot of worry on every extra AVP 


;=
-)


 


I=
 prefer having the AVP optional but with a default value just like <=
span lang=3D"FR">


i=
t is now. We have the same for the reduction percentage and the 


v=
alidity time as well.


 


-=
 Jouni


 


O=
n Feb 13, 2014, at 10:55 AM, "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)&quo=
t; <jean-jacq=
ues.trottin@alcatel-lucent.com> wrote:=



 


H=
i Mcruz


 


T=
he current description indicates that when not present the OLR is of type H=
ost, which was fine for me and keeps my preference. 


W=
e may have  deployments where Realm OLR is not used, or where statisti=
cally the HOST type is the most frequent, so to have the grouped OLR-AVP co=
ntaining a minimum of AVPs minimizes parsing. I agree it is a small optimiz=
ation.


 


B=
est regards


 


J=
Jacques


 


&=
nbsp;


&=
nbsp;


&=
nbsp;


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces@ietf=
.org] De la part de 


<=
a href=3D"mailto:lionel.morand@orange.com">lionel.morand@orange.com Env=
oy=E9 : mercredi 12 f=E9vrier 2014 15:46 =C0 :


<=
a href=3D"mailto:dime@ietf.org">dime@ietf.org; maria.cruz.bartolome@ericsson.com Objet : =
Re: [Dime] 


[=
dime] #54: OC-Report-Type as mandatory AVP


 


H=
i Maria Cruz,


 


I=
'm assuming that you mean "required" instead of "mandatory&q=
uot;, right?


 


S=
o instead of:


 


O=
C-OLR ::=3D < AVP Header: TBD2 ><=
/span>


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          [ OC-Report-Typ=
e ]


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]


 


Y=
ou would prefer:


 


O=
C-OLR ::=3D < AVP Header: TBD2 ><=
/span>


&=
nbsp;          < OC-Sequenc=
e-Number >


&=
nbsp;          { OC-Report-Typ=
e }


&=
nbsp;          [ OC-Reduction-=
Percentage ]


&=
nbsp;          [ OC-Validity-D=
uration ]


&=
nbsp;        * [ AVP ]


 


A=
nd I'm fine with this proposal.<=
/pre>

 


C=
heers,


 


L=
ionel


 


-=
----Message d'origine-----


D=
e : DiME [mailto:dime-bounces@ietf=
.org] De la part de dime issue 


t=
racker Envoy=E9 : mercredi 12 f=E9vrier 2014 15:26 =C0 :


<=
a href=3D"mailto:maria.cruz.bartolome@ericsson.com">maria.cruz.bartolome@er=
icsson.com Cc : dime@ietf.org Obje=
t : [Dime] 


[=
dime] #54: OC-Report-Type as mandatory AVP


 


#=
54: OC-Report-Type as mandatory AVP


 


N=
ow in chapter 4.6:


 


&=
nbsp;The default value of the OC-Report-Type AVP is 0 (i.e. the host  =



r=
eport).


 


T=
his AVP is always required, right? Then, I think it is more precise that&nb=
sp; we define this AVP as mandatory.


 


-=
-


-=
----------------------------------------------+---------------------


-=
----------------------------------------------+---


-=
----------------------------------------------+---


R=
eporter:  maria.c=
ruz.bartolome@ericsson.com  |      Owner:=
  MCruz


&=
nbsp; Type:  defect         &n=
bsp;            =
;       |  Bartolom=E9


P=
riority:  major         &=
nbsp;           &nbs=
p;        |     Stat=
us:  new


C=
omponent:  draft-docdt-dime-ovli      &n=
bsp;       |  Milestone:


S=
everity:  Active WG Document       =
          |    =
Version:  1.0


&=
nbsp;           &nbs=
p;            &=
nbsp;            &nb=
sp;     |   Keywords:


-=
----------------------------------------------+---------------------


-=
----------------------------------------------+---


-=
----------------------------------------------+---


 


T=
icket URL: &l=
t;http://trac.tools.ietf.org/wg/dime/trac/ticket/54>


d=
ime <http://tools.ietf.org/wg=
/dime/>


 


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
o:p>


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


 


_=
____________________________________________________________________=



_=
___________________________________________________


 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou c=
opies 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 tou=
te responsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 


T=
his message and its attachments may contain confidential or privileged info=
rmation that may be protected by law; they 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.


 


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
o:p>


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
o:p>


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


 


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
o:p>


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


 


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
o:p>


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


 


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
o:p>


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime


 


_=
______________________________________________


D=
iME mailing list


<=
a href=3D"mailto:DiME@ietf.org">DiME@ietf.org<=
o:p>


<=
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<=
o:p>


<=
a href=3D"https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/=
mailman/listinfo/dime




&=
nbsp;


&=
nbsp;


&=
nbsp;




 




 






_=
___________________________________________________________________________=
_____________________________________________=



&=
nbsp;


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as 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 ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. 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.


________________________________________________________________=
_________________________________________________________


 


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.

 


This message and its attachments may contain confidential or pri=
vileged information that may be protected by law;<=
o:p>


they should not be distributed, used or copied without authorisa=
tion.


If you have received this email in error, please notify the send=
er 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.




 


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.






--_000_E194C2E18676714DACA9C3A2516265D20267B38EFR712WXCHMBA12z_--


From nobody Thu Mar 27 08:14:07 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 9F1D51A0747 for ; Thu, 27 Mar 2014 08:14:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 GHnWG4VgrMEz for ; Thu, 27 Mar 2014 08:14:03 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2471A0728 for ; Thu, 27 Mar 2014 08:14:01 -0700 (PDT)
Received: from localhost ([127.0.0.1]:55001 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WTC0F-0003A0-FS; Thu, 27 Mar 2014 16:13:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Thu, 27 Mar 2014 15:13:59 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/31#comment:1
Message-ID: <081.3f8870d1f23459476500727372a3cbec@trac.tools.ietf.org>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org>
X-Trac-Ticket-ID: 31
In-Reply-To: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: srdonovan@usdonovans.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/aAz17pxAEPEdDQevpFCOV9QHAjU
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #31 (draft-docdt-dime-ovli): Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
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: Thu, 27 Mar 2014 15:14:04 -0000

#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a
throttling

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Add the following to section 5.5.1.2

     Overload Control States for reporting nodes containing a validity
 duration of 0 sec. should

     not expire before any previously sent (stale) OLR has timed out at any
 reacting node.

 Add the following to section 5.5.1.3

     Reacting nodes do not delete an OCS when receiving an answer message
 that does not

     contain an OC-OLR AVP (i.e. absence of OLR means “no changeâ€).

-- 
--------------------------------------+---------------------------
 Reporter:  lionel.morand@orange.com  |       Owner:  Ulrich Wiehe
     Type:  defect                    |      Status:  closed
 Priority:  major                     |   Milestone:
Component:  draft-docdt-dime-ovli     |     Version:
 Severity:  Active WG Document        |  Resolution:  fixed
 Keywords:                            |
--------------------------------------+---------------------------

Ticket URL: 
dime 


From nobody Thu Mar 27 08:24:49 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 B40CD1A0743 for ; Thu, 27 Mar 2014 08:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 NkygntwpBVNs for ; Thu, 27 Mar 2014 08:24:41 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 027151A073B for ; Thu, 27 Mar 2014 08:24:25 -0700 (PDT)
Received: from localhost ([127.0.0.1]:56073 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1WTCAE-0000qL-OO; Thu, 27 Mar 2014 16:24:18 +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: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.com
X-Trac-Project: dime
Date: Thu, 27 Mar 2014 15:24:18 -0000
X-URL: http://tools.ietf.org/wg/dime/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/dime/trac/ticket/40#comment:1
Message-ID: <072.bc51df6a4b5d65348830adf08c477008@trac.tools.ietf.org>
References: <057.01735c3128fb78d15e8c46bffd9dff62@trac.tools.ietf.org>
X-Trac-Ticket-ID: 40
In-Reply-To: <057.01735c3128fb78d15e8c46bffd9dff62@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-docdt-dime-ovli@tools.ietf.org, srdonovan@usdonovans.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
Resent-To: ben@nostrum.com, jouni.nospam@gmail.com, srdonovan@usdonovans.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-gAbr61NulpBMmqwRyHDJm5-j2A
Cc: dime@ietf.org
Subject: Re: [Dime] [dime] #40 (draft-docdt-dime-ovli): Need defintions for Overload Report and Abatement Algorithm
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: Thu, 27 Mar 2014 15:24:45 -0000

#40: Need defintions for Overload Report and Abatement Algorithm

Changes (by srdonovan@usdonovans.com):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Added the following:

 Abatement Algorithm:
          An algorithm requested by reporting nodes and used by reacting
 nodes
          to reduce the amount of traffic sent to the reporting node during
 an
          occurrence of overload control.
 Overload Report:
          A set of AVPs sent by a reporting node indicating the start or
 continuation of
          an occurrence of overload control.
 Overload Control State:
          State describing an occurrence of overload control maintained by
 reporting and
          reacting nodes.

-- 
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  draft-docdt-dime-
  ben@nostrum.com        |  ovli@tools.ietf.org
     Type:  defect       |      Status:  closed
 Priority:  minor        |   Milestone:
Component:  draft-       |     Version:  1.0
  docdt-dime-ovli        |  Resolution:  fixed
 Severity:  Active WG    |
  Document               |
 Keywords:               |
-------------------------+-------------------------------------------------

Ticket URL: 
dime 


From nobody Thu Mar 27 09:14:18 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 E09461A032A for ; Thu, 27 Mar 2014 09:14:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.58
X-Spam-Level: *
X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 FlM4oko2BNeb for ; Thu, 27 Mar 2014 09:14:13 -0700 (PDT)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [23.235.209.16]) by ietfa.amsl.com (Postfix) with ESMTP id 96A5B1A0147 for ; Thu, 27 Mar 2014 09:14:13 -0700 (PDT)
Received: from cpe-76-187-100-94.tx.res.rr.com ([76.187.100.94]:50591 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1WTCwQ-0005W1-Dv for dime@ietf.org; Thu, 27 Mar 2014 09:14:07 -0700
Message-ID: <53344E4E.5020305@usdonovans.com>
Date: Thu, 27 Mar 2014 11:14:06 -0500
From: Steve Donovan 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: "dime@ietf.org" 
Content-Type: multipart/alternative; boundary="------------010505080200090904050000"
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/Y4_xTzBDnYyamVrtmvHNqAvvml4
Subject: [Dime] Status of -02 draft
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: Thu, 27 Mar 2014 16:14:15 -0000

This is a multi-part message in MIME format.
--------------010505080200090904050000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

All,

Odd things seem to be happening with the issue tracking tool.  I closed
three issues, saw email for two of the three but none of them are
showing as closed with the tool.

I'll try to sort that out later.

I'm almost ready to submit the -02 draft.

I made updates and closed (or attempted to close) issues 31, 40 and 43.

I believe we already have updates required to close issue 49 but will
leave that for review after -02 is submitted.

I updated Report-Type to be required based on Lionel's decision.  This
can clearly be changed in -03 if there is consensus to do so.

I also did some editorial clean up.

The Realm/RRR issue remains open and, as such, so do issues 23, 55, 57
and 58. 

Issue 35, dealing with per client reports, remains open.  The plan
coming out of the London meeting was for this to be dealt with as a
separate extension.

The following are also left for after -02 is published.

#25 - End point definition
#26, 27, 60, 61 - Agent behavior definition  (depends on #26)
#61 - Clean up of overview

I have inserted Editor's notes in places where I think there are still
open issues.  There's a good chance I've missed some.

I plan to submit the draft later today. 

Thanks to everyone for the hard work leading to this version of the
draft.  We aren't done yet, but there was significant improvement from
the -01 draft.

Regards,

Steve


--------------010505080200090904050000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    All,

      

      Odd things seem to be happening with the issue tracking tool.  I
      closed three issues, saw email for two of the three but none of
      them are showing as closed with the tool.

      

      I'll try to sort that out later.

      

      I'm almost ready to submit the -02 draft.

      

      I made updates and closed (or attempted to close) issues 31, 40
      and 43.

      

      I believe we already have updates required to close issue 49 but
      will leave that for review after -02 is submitted.

      

      I updated Report-Type to be required based on Lionel's decision. 
      This can clearly be changed in -03 if there is consensus to do so.

      

      I also did some editorial clean up.

      

      The Realm/RRR issue remains open and, as such, so do issues 23,
      55, 57 and 58.  

      

      Issue 35, dealing with per client reports, remains open.  The plan
      coming out of the London meeting was for this to be dealt with as
      a separate extension. 

      

    The following are
      also left for after -02 is published.

      

      #25 - End point definition

      #26, 27, 60, 61 - Agent behavior definition  (depends on #26)

      #61 - Clean up of overview

      

      I have inserted Editor's notes in places where I think there are
      still open issues.  There's a good chance I've missed some.

      

      I plan to submit the draft later today.  

      

      Thanks to everyone for the hard work leading to this version of
      the draft.  We aren't done yet, but there was significant
      improvement from the -01 draft.

      

      Regards,

      

      Steve

    

  


--------------010505080200090904050000--


From nobody Thu Mar 27 09:48: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 EE63F1A0147 for ; Thu, 27 Mar 2014 09:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 OcwUEPwnHwoB for ; Thu, 27 Mar 2014 09:48:08 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1EFEC1A00DD for ; Thu, 27 Mar 2014 09:48:07 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id ec20so2859831lab.11 for ; Thu, 27 Mar 2014 09:48:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=ALFO3n1X1gDmEB4SdjAiJSxo7AqMyv6u4WeiDOdfx48=; b=YPWjCzm3WPkb7yoj545JRjb885D8J5cxrtOuIKYLIvvLyYUd+F/cAuc9gJ3uRVM+vM ARknYBgxGHaPE7o3nN8UAuwbXwywt/H4+Tth0kamZzDIKw5zsgrskaXGs3K5Mqa0l1ga LqcyrAn5W8rE2jSDxGcyNcmW6ntWh071cZsu+YPVtPZI3AWvALe7KH7aHthr2wILm+ss 64rXxvLQJT9lv6whoC5X5AqHIqDrFdPBloG2Jcfatkr5JH8PKtaREMXx7RHhhv58sErh jxIp4iVuCVtLRD+UXkj8AIiNIRDAttXJk7GmDwH6S7uqiohLP6dNsrYjvTh68KO4kwK4 SRPQ==
X-Received: by 10.152.170.137 with SMTP id am9mr1558893lac.15.1395938885556; Thu, 27 Mar 2014 09:48:05 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:1c5a:9262:3462:4843? ([2001:1bc8:101:f101:1c5a:9262:3462:4843]) by mx.google.com with ESMTPSA id q6sm2445112lal.3.2014.03.27.09.48.04 for  (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 09:48:04 -0700 (PDT)
Message-ID: <53345643.6090405@gmail.com>
Date: Thu, 27 Mar 2014 18:48:03 +0200
From: Jouni Korhonen 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dime@ietf.org
References: <53344E4E.5020305@usdonovans.com>
In-Reply-To: <53344E4E.5020305@usdonovans.com>
Content-Type: multipart/alternative; boundary="------------070606010805060609090200"
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/CxFPRszbina5ah8CRG-G3kjT1ws
Subject: Re: [Dime] Status of -02 draft
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: Thu, 27 Mar 2014 16:48:11 -0000

This is a multi-part message in MIME format.
--------------070606010805060609090200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


I heard similar things from other WGs as well.. so there might be 
something goofy going on.

- Jouni

3/27/2014 6:14 PM, Steve Donovan kirjoitti:
> All,
>
> Odd things seem to be happening with the issue tracking tool.  I 
> closed three issues, saw email for two of the three but none of them 
> are showing as closed with the tool.
>
> I'll try to sort that out later.
>
> I'm almost ready to submit the -02 draft.
>
> I made updates and closed (or attempted to close) issues 31, 40 and 43.
>
> I believe we already have updates required to close issue 49 but will 
> leave that for review after -02 is submitted.
>
> I updated Report-Type to be required based on Lionel's decision.  This 
> can clearly be changed in -03 if there is consensus to do so.
>
> I also did some editorial clean up.
>
> The Realm/RRR issue remains open and, as such, so do issues 23, 55, 57 
> and 58.
>
> Issue 35, dealing with per client reports, remains open.  The plan 
> coming out of the London meeting was for this to be dealt with as a 
> separate extension.
>
> The following are also left for after -02 is published.
>
> #25 - End point definition
> #26, 27, 60, 61 - Agent behavior definition  (depends on #26)
> #61 - Clean up of overview
>
> I have inserted Editor's notes in places where I think there are still 
> open issues.  There's a good chance I've missed some.
>
> I plan to submit the draft later today.
>
> Thanks to everyone for the hard work leading to this version of the 
> draft.  We aren't done yet, but there was significant improvement from 
> the -01 draft.
>
> Regards,
>
> Steve
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------070606010805060609090200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    

    I heard similar things from other WGs as well.. so there might be
    something goofy going on.

    

    - Jouni

    

    
3/27/2014 6:14 PM, Steve Donovan
      kirjoitti:

    

    

      
      All,

        

        Odd things seem to be happening with the issue tracking tool.  I
        closed three issues, saw email for two of the three but none of
        them are showing as closed with the tool.

        

        I'll try to sort that out later.

        

        I'm almost ready to submit the -02 draft.

        

        I made updates and closed (or attempted to close) issues 31, 40
        and 43.

        

        I believe we already have updates required to close issue 49 but
        will leave that for review after -02 is submitted.

        

        I updated Report-Type to be required based on Lionel's
        decision.  This can clearly be changed in -03 if there is
        consensus to do so.

        

        I also did some editorial clean up.

        

        The Realm/RRR issue remains open and, as such, so do issues 23,
        55, 57 and 58.  

        

        Issue 35, dealing with per client reports, remains open.  The
        plan coming out of the London meeting was for this to be dealt
        with as a separate extension. 

        

      The following
        are also left for after -02 is published.

        

        #25 - End point definition

        #26, 27, 60, 61 - Agent behavior definition  (depends on #26)

        #61 - Clean up of overview

        

        I have inserted Editor's notes in places where I think there are
        still open issues.  There's a good chance I've missed some.

        

        I plan to submit the draft later today.  

        

        Thanks to everyone for the hard work leading to this version of
        the draft.  We aren't done yet, but there was significant
        improvement from the -01 draft.

        

        Regards,

        

        Steve

      

      

      

      

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


    

    

  


--------------070606010805060609090200--


From nobody Thu Mar 27 10:41:28 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 92E0D1A06CC; Thu, 27 Mar 2014 10:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QsBbCEr_1-qB; Thu, 27 Mar 2014 10:41:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4271A0182; Thu, 27 Mar 2014 10:41:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 5.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140327174113.9655.53009.idtracker@ietfa.amsl.com>
Date: Thu, 27 Mar 2014 10:41:13 -0700
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/yHfFpFDGSkrvO6jEFlAav61h4dc
Cc: dime@ietf.org
Subject: [Dime] I-D Action: draft-ietf-dime-ovli-02.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Diameter Maintanence and Extentions Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Mar 2014 17:41:20 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Diameter Maintenance and Extensions Working Group of the IETF.

        Title           : Diameter Overload Indication Conveyance
        Authors         : Jouni Korhonen
                          Steve Donovan
                          Ben Campbell
                          Lionel Morand
	Filename        : draft-ietf-dime-ovli-02.txt
	Pages           : 41
	Date            : 2014-03-27

Abstract:
   This specification documents a Diameter Overload Control (DOC) base
   solution and the dissemination of the overload report information.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-ovli/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dime-ovli-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-dime-ovli-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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


From nobody Thu Mar 27 20:25:40 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 603CD1A07C5 for ; Thu, 27 Mar 2014 20:25:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xGNVMTAXds0x for ; Thu, 27 Mar 2014 20:25:37 -0700 (PDT)
Received: from c62.cesmail.net (c62.cesmail.net [216.154.195.54]) by ietfa.amsl.com (Postfix) with ESMTP id C899E1A0437 for ; Thu, 27 Mar 2014 20:25:36 -0700 (PDT)
Received: from unknown (HELO epsilon2) ([192.168.1.60]) by c62.cesmail.net with ESMTP; 27 Mar 2014 23:25:34 -0400
Received: from c-24-147-29-104.hsd1.ma.comcast.net (c-24-147-29-104.hsd1.ma.comcast.net [24.147.29.104]) by webmail.spamcop.net (Horde MIME library) with HTTP; Thu, 27 Mar 2014 23:25:34 -0400
Message-ID: <20140327232534.aobls4f4tcgscs0s-qnivqz@webmail.spamcop.net>
Date: Thu, 27 Mar 2014 23:25:34 -0400
From: David Mitton 
To: dime@ietf.org
References: <075.72da31b401c033905a4fb81d09a8b4aa@trac.tools.ietf.org> <53287893.5020203@usdonovans.com> <087A34937E64E74E848732CFF8354B920979DDA2@ESESSMB101.ericsson.se> <53288284.5040606@usdonovans.com>  <26C84DFD55BC3040A45BF70926E55F2587C3D80D@SZXEMA512-MBX.china.huawei.com> <53302446.9080700@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3DE93@SZXEMA512-MBX.china.huawei.com> <533178CD.9030707@usdonovans.com>, <26C84DFD55BC3040A45BF70926E55F2587C3E4C3@SZXEMA512-MBX.china.huawei.com> <11673_1395816227_53327723_11673_1919_1_4wjyrmeak04xst2onmes7ybh.1395816218573@email.android.com> <26C84DFD55BC3040A45BF70926E55F2587C3E57B@SZXEMA512-MBX.china.huawei.com> <26C84DFD55BC3040A45BF70926E55F2587C3E5AD@SZXEMA512-MBX.china.huawei.com> <1369_1395819319_53328337_1369_10404_1_6B7134B31289DC4FAF731D844122B36E51C25A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3E671@SZXEMA512-MBX.china.huawei.com> <5332C60E.2060805@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F2587C3E932@SZXEMA512-MBX.china.huawei.com> <14209_1395841826_5332DB22_14209_9620_1_6B7134B31289DC4FAF731D844122B36E51E2FD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3ED23@SZXEMA512-MBX.china.huawei.com> <22839_1395912677_5333EFE4_22839_3586_1_6B7134B31289DC4FAF731D844122B36E520AC9@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EEEF@SZXEMA512-MBX.china.huawei.com> <11312_1395916348_5333FE3C_11312_7917_5_6B7134B31289DC4FAF731D844122B36E520C95@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F2587C3EF92@SZXEMA512-MBX.china.huawei.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D8B92@DEMUMBX014.nsn-intra.net> 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/ERZt4a8kFtglBPquWfkzH7aPDZY
Subject: [Dime] Large messages on list?
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: Fri, 28 Mar 2014 03:25:38 -0000

This is the second day with over a dozen messages over 100KB.
I thought this was going to be avoided.

Someone keeps generating HTML recaps the whole thread, which is  
redundant, and some how mostly white space.  Can we stop this?

Dave.