IETF Logo Mail Archive

Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Tue, 18 February 2014 10:11 UTC

Return-Path: <maria.cruz.bartolome@ericsson.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794D31A0627 for <dime@ietfa.amsl.com>; Tue, 18 Feb 2014 02:11:35 -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 PQ2EsKaEl0GX for <dime@ietfa.amsl.com>; Tue, 18 Feb 2014 02:11:29 -0800 (PST)
Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6186A1A061F for <dime@ietf.org>; Tue, 18 Feb 2014 02:11:24 -0800 (PST)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-dd-530331c8d481
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id B4.2E.04853.8C133035; Tue, 18 Feb 2014 11:11:20 +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; Tue, 18 Feb 2014 11:11:20 +0100
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
Thread-Index: AQHPIYbAlWmMf1mPE0uklIAv2DU+a5qmwd9e///0FYCAACHDUIACsQCAgAA/36CAADI28IAEcC8AgAAIJACAAAnhgIABbLDg///ya4CAAEgwoIAFPwgvgAQ/M4CAABvrAIABIJ2g
Date: Tue, 18 Feb 2014 10:11:20 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209783450@ESESSMB101.ericsson.se>
References: <066.b54c2f5aeb31c9b3f88c96008120290d@trac.tools.ietf.org> <E194C2E18676714DACA9C3A2516265D202663C4A@FR712WXCHMBA11.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209772EF4@ESESSMB101.ericsson.se> <19874_1392116210_52FA01F2_19874_3990_1_6B7134B31289DC4FAF731D844122B36E499C4E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B9209773085@ESESSMB101.ericsson.se> <52FA3CC6.905020 5@usdonovans.com> <17910_1392132298_52FA40CA_17910_2863_1_6B7134B31289DC4FAF731D844122B36E49A28D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <11546_1392132645_52FA4225_11546_3173_1_0aa80fb0-8382-459e-aebf-2ee5d5f70edc@PEXCVZYH02.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D2026644D6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <D2D4DD91-8F3D-4C24-9E3A-E2AE3918D468@gmail.com> <52FCBBF7.7000700@usdonovans.com> <D4BE67F7-6D7B-4DB2-8DF0-D430A8FC6582@nostrum.com> <5302351F.6050902@usdonovans.com> <E194C2E18676714DACA9C3A2516265D2026697DE@FR712WXCHMBA12.zeu.alcatel-lucent.com>
In-Reply-To: <E194C2E18676714DACA9C3A2516265D2026697DE@FR712WXCHMBA12.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209783450ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje4JQ+Zgg44mK4u5vSvYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0XD6BVPB8cSKm/smszQwbgrtYuTkkBAwkZi5YzcjhC0mceHe erYuRg4OIYETjBI/mLoYuYDMxYwSk1d9YgapYROwk7gENAekRkRAWeL0LweQsLCAvcTXG2fA SkQEHCTWPD/JAtIrIjCNUWLtwlZWkASLgKrE2YeXwHbxCvhKnJ5ynw1iQR+HxOazzewgCU6B WInd21cwgdiMQAd9P7UGzGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKYStKXJ2+HKo+X+LM lh8sEMsEJU7OfMIygVFkFpJRs5CUzUJSBhHXk7gxdQobhK0tsWzha2YIW1dixr9DLMjiCxjZ VzFKFqcWF+emGxno5abnluilFmUmFxfn5+kVp25iBMbSwS2/jXYwntxjf4hRmoNFSZz3OmtN kJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG9BuVTq6Sx20KFrnkCcT/9dLI5PwVsa2V1+hh 7DSbp5tPnOD6xn4kPFh52bODKec0nb5Zqv7x3C/Bc0x1g49PmPKXCWtdo+4sOXQ2o2pNkVCC f6BUKZNtsmZ2r/x6IZVdskFaf1fG3T08tWzmr0/ibR0qk68EyZ7mquy/7XcwiGm+2EQFW10l luKMREMt5qLiRACNr7yDcwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/-HO8gOdkQtLjZvXeQBLwcbL9t0I
Subject: Re: [Dime] [dime] #34: 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 <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Feb 2014 10:11:35 -0000

Hello all,

Overload of the realm is one of the use cases that is required by 3GPP applications.
And I think this should be part of the basic mechanism, or?

Best regards
/MCruz

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: lunes, 17 de febrero de 2014 18:53
To: dime@ietf.org
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Hi

I share the view to analyze the overload of the realm as a whole in a separate extension  and see if this lead to another report type.

Best regards

JJacques


De : DiME [mailto:dime-bounces@ietf.org] De la part de Steve Donovan
Envoyé : lundi 17 février 2014 17:13
À : Ben Campbell
Cc : dime@ietf.org<mailto:dime@ietf.org> list
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

I do think it would be a new report type, as it would require different behavior from reacting nodes.

I'm ok with this being in a separate extension if the group thinks this is the correct approach.  We are creating a good number of relatively small extensions.  It might lead to the need to pull them all together in a future version of the DOIC draft/RFC.

Steve
On 2/14/14 4:21 PM, Ben Campbell wrote:

(Apologies for coming late to this thread)



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



Ok, Ok, no reason to gang up on me. :-)

What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.





At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests.



I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.





I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?



Steve

v2.23.0 | Report a Bug | By Email